I started to work for a new client and they have a GitLab subdomain to keep all their repositories. I applied my ssh key and gpg2 keys to their GitLab account. However, when I try to clone via ssh, I time out. But if I were to clone via HTTPS, everything works fine.
What step am I missing to get the ssh portion working?
Cloning via https does work.
https://gitlab.company_sub_domain.com/company/repository.git
Cloning via ssh does not work.
git#gitlab.company_sub_domain.com:company/repository.git
config file:
In case this may be of any help:
Try completing your ssh config file with
Host companysub
Hostname gitlab.company_sub_domain.com
User git
IdentityFile ~/.ssh/id_ed25519
(put the "Preferredauthentication publickey" part in Host *)
That way, your URL would become companysub, as in:
git clone companysub:company/repository.git
First, try an ssh -Tv companysub, to check if the key is recognized and working.
Related
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
I'm trying to push my project on git to my remote Linux server from my local Windows PC.
I have no issues connecting to my server through SSH when I use PuTTY. But PuTTY is only for the remote server, and doesn't let me look in my own local pc - so I can't access my git repository to push from.
Instead I've been trying with Git Bash, where I go to the repository(master) of my git project, and then attempt "git push production master". Receiving "Permission denied (publickey)" in response in Git Bash.
I have loaded by private key from my user/.ssh folder on local pc, using PuTTYgen, copy/pasted the public key it shows into my Github account's SSH-keys.
This is the same key that I use for connecting with PuTTY(which works).
If I use "git remote -v" in Git Bash, I receive what is the correct url for the server:
"
production ssh://notacop#mafiauniversedata.com/var/repo/site.git (fetch)
production ssh://notacop#mafiauniversedata.com/var/repo/site.git (push)
"
"notacop" is the admin user I made instead of root, which is also the one that I use in PuTTY.
If I attempt "ssh notacop#mafiauniversedata.com" in Git Bash I also receive the "Permission denied (publickey)" response. So seemingly the issue is related to the publickey that Git Bash uses, as it can't connect at all.
My user/.ssh folder contains:
digitalocean_private_key (is the one PuTTY uses/the one generated by PuTTYgen) + digitalocean_public_key
github_rsa + github_rsa.pub
id_rsa + id_rsa.pub
known_hosts
I feel like I've set things up in accordance with the general guidelines, and it does work in PuTTY, so the issue must be related to Git Bash and how Git Bash establishes ssh connection.
But I'm fairly clueless about how to fix the issue, and haven't been able to find a solution from searching. My guess is that it's something fairly simple, but I've been stuck on this for a couple weeks now, not getting anywhere because of it.
Any answers that can lead me in the right direction will be highly appreciated!
If anything about my question is unclear, or you need more information to answer, please let me know.
I don't know why Git Bash's own ssh doesn't seem to work for you,
but I have a better recommendation: make Git Bash use PuTTY, by setting the GIT_SSH environment variable to the path of plink.exe (that's not a typo, it's not putty.exe, but another executable that comes with the zip of PuTTY tools).
The main advantage and reason to do this is so that Git Bash can benefit from pagent.exe, the key manager of PuTTY.
So that you can enter your passphrase once,
when adding your private key to Pagent,
and then you don't need to re-enter it every time you perform remote operations in Git Bash.
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 a git repository setup on a remote server XXX.XXX.XXX.XXX and want to clone the same in my windows environment. It's actually a webapp present under /var/www/html/Testsite. The git repo is created inside the Testsite folder.
I was hoping the command:
git clone http://XXX.XX.XX.XX/Testsite/mysite.git would work fine but it does not. Please let me know how I can get the URL to configure and clone it into my environment.
However, with the local folder, I am easily able to clone the repository which works totally fine.
Thanks a lot.
You can't, without configuring your Apache in order to server git request.
The fact that your mysite.git is within Testsite doesn't make it accessible to git.
As shown in this config, you can define in a separate VirtualHost (so in a separate port, since you are already using port 80/443 on Testing) a config in order to call the git script able to interpret a git clone request:
ScriptAlias /hgit/ /path/to/git/libexec/git-core/git-http-backend/
SetEnv GIT_HTTP_BACKEND "/path/to/git/libexec/git-core/git-http-backend"
<Location /hgit>
...
</Location>
As for ssh, the right url would be:
git clone ssh://account#XX.XX.XX.XX/var/www/html/Testsite/mysite.git
And it would work only if you generate a public and private (non-passhrase protected at first), and publish the public key in the ~account/.ssh/authorized_keys.
Or the sshd (ssh daemon) on the server won't recognize you (hence the password request), and won't know where "Testing/" is.
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