How do I configure the GitLab URL username?
Why is the username in the Git clone URL always git#url?
Even if we create own user it still says git.
I have created my ssh key and added to the GitLab, but still it says git#url.
It does say git because it is the account under which GitLab server has been installed.
It is defined in the gitlab.yml config file.
# Uncomment and customize if you can't use the default user to run GitLab
(default: 'git')
# user: git
You will always contact GitLab ssh with that user 'git': that SSH session will use your public SSH key, and that will allow the GitLab server to authenticate you.
Since it is an SSH URL, you need to open a (non-interactive) ssh (secure shell) session always with the account git, which will have your public SSH key registered.
Related
I am setting up my ssh config for 2 different accounts in gitlab.
Host gitlab.com-roulette
HostName gitlab.com
User norayr.ghukasian
IdentityFile /home/norayr_ghukasyan/.ssh/id_ed25519_roulette
Host gitlab.com-devlix
HostName gitlab.com
User norayr.ghukasyan
IdentityFile /home/norayr_ghukasyan/.ssh/id_ed25519_devlix
I am getting a Permission denied error.
The strange thing for me is that the first one is working fine, therefore I think there is some tiny issue in my config that I am not aware of. I guess when the user or the server tries to connect, ssh automatically matches the first config with matched HostName.
How do I set up it properly to work for both of the accounts?
P.S. The Users are different - norayr.ghukasian and norayr.ghukasyan.
Following Use difference accounts on a single GitLab instance you would setup your configuration like so:
Host norayr.ghukasian.gitlab.com
Hostname gitlab.com
PreferredAuthentications publickey
User git
IdentityFile /home/norayr_ghukasyan/.ssh/id_ed25519_roulette
Host norayr.ghukasyan.gitlab.com
Hostname gitlab.com
PreferredAuthentications publickey
User git
IdentityFile /home/norayr_ghukasyan/.ssh/id_ed25519_devlix
Then to clone a repo as norayr.ghukasian user:
git clone git#norayr.ghukasian.gitlab.com:gitlab-org/gitlab.git
Using the username as the alias is not absolutely necessary. You can use a different alias if you wish and set it in the Host section of your ssh config.
Key takeaways:
The only thing that you need to tell GitLab who you are is the IdentityFile.
You can direct git/ssh to use a specific identity file by the alias you use for the host configured in the ssh config.
I want to integrate Cpanel with GitLab instance which its repositories are private and I can't use SSH because I don't have any access to the configuration of this instance and the Cpanel server (except the ssh keys section in Cpanel itself).
In Cpanel, the git section doesn't accept HTTP URLs for private git repositories and it suggests using SSH URLs instead but I can not.
I tried to use HTTP URL with username and password in URL but it prevents me to do this. like this:
https://USER:PASS#gitlab-instance.com/username/repository.git
anyone can help me to access the private git repository with SSH?
You should:
Add an ssh key
https://docs.gitlab.com/ee/gitlab-basics/create-your-ssh-keys.html
Access the repo via ssh
git#gitlab-instance.com:username/repository.git
Problem faced:
I cannot git push to my repo, error message:
remote: Permission to fishercoder1534/Leetcode.git denied to MY_OLD_GITHUB_ACCOUNT
fatal: unable to access 'https://github.com/fishercoder1534/Leetcode.git/':
The requested URL returned error: 403`
Research I have done:
looking at this post, I have all these correctly pointing to my new github account:
git config --global user.name "NewAccountFirstname NewAccountLastname"
git config --global user.email "my_new_github_account_email#gmail.com"
I have deleted my old ssh keys, generated new ssh keys, placed them under ~/.ssh/, also add them into my new Github account.
I have created a ~/.ssh/config file with the following contents as suggested by the above post:
Host github.com
User git
IdentityFile ~/.ssh/id_rsa # wherever your "new" key lives
IdentitiesOnly yes
I have run $ssh -vT git#github.com which all shows my new Github account info. Hi fishercoder1534! You've successfully authenticated, but GitHub does not provide shell access.
I have run $ssh -i ~/.ssh/id_rsa -vT git#github.com, it's also showing my new Github info, with Hi fishercoder1534! You've successfully authenticated, but GitHub does not provide shell access.
What's next option to try/help?
An https url (https://github.com/fishercoder1534/Leetcode.git) means that every settings you have done for ssh doesn't matter.
And user.name/user.email have nothing to do with a Git repo server authentication.
Check if you have cached your https github.com credentials in a credential manager with git credential.helper:
git config credential.helper
That would explain why your old account keeps being used.
For osxkeychain, you can update your account
Or, of course, you can switch to an ssh url:
git remote set-url origin git#github.com:fishercoder1534/Leetcode.git
I have configured Jenkins on a Linux machine and my git repo is on an another Linux server. But when I try to give the URL of the repo to Jenkins I get the following error.
Failed to connect to repository : Command "git -c core.askpass=true ls-remote -h ssh://user#ip/~/export1 HEAD" returned status code 128:
stdout:
stderr: Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
What could be the cause for this?
I have seen that both the systems' rsa key is present in each other's .ssh/known_hosts folder.
I am able to pull or clone code from the repo to a folder in Jenkins system as well. So why is Jenkins not able to take it?
I have also tried the URL user#ip:/fullpath/to/repo
You need to make sure Jenkins is running as the right user (the one who has the keys in ~/.ssh/id_rsa(.pub)
That user might not be the same as the one used in the ssh url: user#ip means you are connecting to ip using an account which has your public key in ~user/.ssh/authorized_key.
So the Jenkins process must be run by an account which has the private and public key, whose public key is in ~user/.ssh/authorized_key on the git server side.
And that account should have done (only once) an ssh-keyscan -H ip >> ~account/.ssh/known_hosts before any ssh attempt, in order to record the git server ip as a known host.
Does it being a bare repo make any difference or change in the URL?
No. The .git at the end of the bare repo folder is optional when used as an url.
Further to #VonC's reply, you can also use the Credentials plugin to define a set of credentials on your Jenkins master that your Jenkins job uses to access your Git repo. This allows you to run Jenkins itself as a different user from there one that has access to the Git repo.
The main problem was the security of the systems. I hadnt checked the authentication mechanisms on my server. The password authentication to the git server was causing the problem because the jenkins machine tries to directly fire a ls-remote to the path. When you do the same thing on the terminal you will be prompted for a password and then itl accept. When I set the password authentication and UsePAM to no and enabled the RSA authentication, pubkey authentication and authorised key setting to yes in the sshd_config file, and restarted, it was able to access the repo and I dint get this error.
I have successfully created gitolite-admin.git repo on server (say) 10.107.105.13. I can clone this repo on my local machine (say) 10.14.42.7 by issuing git clone gitolite#10.107.105.13:gitolite-admin. I had to add some lines in .ssh/config file to make sure that correct private key is used.
Then I have added a user dilawar to conf/gitolite.conf file and a appropriate key dilawar.pub to keys folder. I have added and commited this commit to the gitolite-admin repo. I have also added one more entry in .ssh/conf file so that a correct private key is used. But when I try to do git clone dilawar#10.107.105.13:testing, gitolite asks for the password. I am under the impression that I do not have to create user dilawar on 10.107.105.13. I have checked by logging into server that repository testing.git exists as well public-key dilawar.pub has been added to .ssh/authorized_keys.
I have also tried ssh -vvvv dilawar#10.107.105.13 to check if the correct file is being offered. Here is my .ssh/conf file.
HostName 10.107.105.13
User gitolite
IdentityFile ~/.ssh/gitolite
Host 10.107.105.13
HostName 10.107.105.13
User dilawar
IdentityFile ~/.ssh/id_rsa
What I am doing wrong?
In your config file, I see:
User dilawar
That is wrong. ssh communication to a gitolite server are always done with the same account (here gitolite).
What changes is the private key used, which will help gitolite determine your identity.
What you ~/.ssh/config file should look like is:
Host admin
HostName 10.107.105.13
User gitolite
IdentityFile ~/.ssh/gitolite
Host dilawar
HostName 10.107.105.13
User gitolite
IdentityFile ~/.ssh/id_rsa
For cloning gitolite-admin, you would use:
git clone admin:gitolite-admin
For cloning a repo dilawar has access to:
git clone dilawar:aRepo
See more at "Gitolite: adding user not working, and DENIED by fallthru when cloning as root?".
See also "how gitolite uses ssh"
Adding your public key to the server's ~git/.ssh/authorized_keys file is how ssh uses pubkeys to authenticate users.
Let's say sita#work.station is trying to log in as git#server.
What you have to do is take the ~sita/.ssh/id_rsa.pub file for user sita on work-station and append its contents (remember it's only one line) to ~git/.ssh/authorized_keys for user git on server.
The authorized_keys file can have multiple public keys (from many different people) added to it so any of them can log in to git#server.
I have got it working by cloning the repository using the gitolite username.
git clone gitolite#server:repo
If keys are added successfully then further pull and push will go smoothly.
I am accepting VomC answer as a better answer.
VonC's answer is the key, but I ran into an edge case that's worth mentioning for future searchers.
Even if you do everything else right, as in VonC's answer, a somewhat standard setting for ControlPath can mess things up.
I had two users in ~/.ssh/config, as below:
Host gitolite
HostName <whatever>
User git
IdentityFile ~/.ssh/gitolite
Host username
HostName <whatever>
User git
IdentityFile ~/.ssh/username
In theory, this should have allowed me to run git clone git#username:reponame, but the server kept thinking that I was trying to clone the repo as the gitolite admin (who does not have permission to clone that repo), rather than as the gitolite user (who does have permission to clone the repo).
The problem was that in my all hosts section, I had the following:
Hosts *
# other stuff that doesn't matter
ControlPath ~/.ssh/ssh-%r#%h:%p
If you don't see it right away (I didn't!), the problem is that the expansions for %r#%h%p (= username#hostname:port) are identical for the gitolite and username entries. They're both git#hostname:port! Once I realized that, it was an easy fix. Simply add distinguishing elements into a more specific ControlPath entry for those two users. E.g.,
Host gitolite
HostName <whatever>
User git
IdentityFile ~/.ssh/gitolite
ControlPath ~/.ssh/gitolite-admin-%r#%h:%p
Host username
HostName <whatever>
User git
IdentityFile ~/.ssh/username
ControlPath ~/.ssh/gitolite-username-%r#%h:%p
I had to edit /etc/ssh/sshd_config and add git (the user) to the line which begins with AllowUsers.
Then I had to add git to a sysadmin group that was also allow on sshd_config's line that begins with AllowGroups.
Don't forget to restart the ssh daemon with sudo service ssh restart.
Note : I didn't have to ssh-copy-id or add the public key to /home/git/.ssh/authorized_keys as suggested before (gitolite's developer recommends against this btw.)
I had the same problem, with a different solution because of my config. I setup my gitolite user as “git” so I needed to do git clone git#server:repo.git