Git clone over ssh

I just pulled gitlab/gitlab-ce:latest and issued the docker run command. Now, I am having the same problem as everybody else, apparently.

I have browsed through dozens of posts, old and new, most importantly, this one:

Which is a recent as 4 months ago.

Yet, I am in trouble.
Is there an actual resolution?
As far as I know, my keys are fine, the project exists, etc. etc. I even switched key type from rsa to ed25519, still…no cigar.

#This works
git clone http://myserver.net/group/firstone.git
# although it asks for user and password, 
# so, I provide MY username and password and it works

#But this does not:
git clone git@myserver.net:group/firstone.git

#I get the following reply
Cloning into 'firstone'...
git@myserver.net's password:

# if I add the following lines to my ~/.ssh/config:
Host myserver.net
    User git
    Hostname myserver.net
    Preferredauthentications publickey
    IdentityFile ~/.ssh/id_ed25519
    TCPKeepAlive yes

# then,the reply changes to:
Cloning into 'firstone'...
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.

Here is the command I used:

docker run --detach \
  --hostname myserver.net \
  --publish 443:443 --publish 80:80 --publish 2222:22 \
  --name gitlab \
  --restart always \
  --volume $GITLAB_HOME/config:/etc/gitlab:Z \
  --volume $GITLAB_HOME/logs:/var/log/gitlab:Z \
  --volume $GITLAB_HOME/data:/var/opt/gitlab:Z \
  --shm-size 256m \
  gitlab/gitlab-ce:latest

Thanks.

I have very little experience with docker, so I’m guessing a little as to what the last command actually does (I assume it’s a copy-paste error, that the post says ocker).

There’s a .net missing after myserver in the command you say doesn’t work. If that is not also just a copy-paste error, it will stop ssh from finding/using that section of your .ssh/config.

The password prompt from git suggests that you reach the docker container though, and if I’m right about what that final command does that’s what you want to. So my guess is that you haven’t uploaded your public key to that GitLab instance. What does ssh -vT git@myserver.net give you?

Hi, grove:

Sorry, they are all typos, in an attempt to remove identifiable information; also, the ocker command would not have worked ;-), so, yeah, another copy paste error. The docker command is right out of the installation instructions…

Here is what I get from the ssh -vT; thanks for asking, anything else you may wonder, please ask.

ssh -vT git@myserver.net
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /home/myuserid/.ssh/config
debug1: /home/myuserid/.ssh/config line 23: Applying options for myserver.net
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 59: Applying options for *
debug1: Connecting to myserver.net [xxx.xx.xxx.xx] port 22.
debug1: Connection established.
debug1: identity file /home/myuserid/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /home/myuserid/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to myserver.net:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group14-sha1
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: diffie-hellman-group14-sha1 need=32 dh_need=32
debug1: kex: diffie-hellman-group14-sha1 need=32 dh_need=32
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Xbb6xLycngZSHaNQagcVD0s9Xdjf1pjjbeS+d1vGuEI
debug1: Host 'myserver.net' is known and matches the ECDSA host key.
debug1: Found key in /home/myuserid/.ssh/known_hosts:105
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: /home/myuserid/.ssh/id_ed25519
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/myuserid/.ssh/id_rsa_2048
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: myuserid@somebox
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: myuserid@otherbox
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

As that output suggests you’re talking to something that speaks SSH, I’ll return to the guess I gave before:

you haven’t uploaded your public key to that GitLab instance

Hi, guys, a solution has been found :grinning:

The docker run command from the installation instructions, include the following line

--publish 443:443 --publish 80:80 --publish 22:22 \

which keeps the docker command from executing because port 22 is always used by ssh in just about any box.

So, I changed that line to say

--publish 443:443 --publish 80:80 --publish 2222:22 \

and now the docker command runs successfully; but, as mentioned, keeps me and the git command from being able to use ssh protocol.

Well, there is a solution, the Host entry for Gitlab server in ~/.ssh/config file needs a Port parameter, like this:

Host myserver.net
    User git
    Hostname myserver.net
    Port 2222
    Preferredauthentications publickey
    IdentityFile ~/.ssh/id_ed25519
    TCPKeepAlive yes
    AddKeysToAgent yes

and…violà, it works. I can now do:

git clone git@myserver.net:path/to/repo.git

I have a question…in post #5 a solution is outlined. @gsal wrote “the Host entry for Gitlab server in ~/.ssh/config file needs a Port parameter.”

My question is, where is ~? Are you working in the docker file system or are you on the host? I have no “git” account on my host, just the docker with the git running in it. I am having the same issue you were having, and would like to try your solution, just not sure where to edit the config file.

Thanks!

This ~ refers to the home directory of the particular user. So, let’s assume my username is “bob”, then by default on Linux his home directory is /home/bob. So you can either put /home/bob/.ssh/id_ed25519 like in the example above, or just put it in short as ~/.ssh/id_ed25519 which is the equivalent of /home/bob - assuming of course that bob is logged in. If you then copy that file to a user called trevor, then the ~ will refer to /home/trevor without having to edit the file again.

Thanks for answering, I actually know what ~ refers to in the general sense. My question relates to the value of ~ in the actual sense for the account “git”. I am accessing the system using ssh and the user being specified is “git” (ssh git@some-ip-address). On my machine there is no user account named git (id git returns no such user). I am running git in a docker, and the docker has a user named git. I am asking the original poster if he means the ~ directory of the git account in the docker or the ~ directory of some other account.

The solution was for the .ssh/config file which is the user who is connecting to the Gitlab instance. It does not relate to a user called git on your computer, but rather in your gitlab instance only in the sense that you are connecting to the server as the git user, but using the ssh key file under the user who is connecting, so in my example bob or trevor it needs to find the ssh key in bob’s home directory referenced as ~.

So maybe I explain this a bit better. I log into my computer as bob, and I want to connect to my gitlab server. If I write:

ssh gitlab

then it will attempt to connect as bob@gitlab. Without an ssh config file, I would need to do:

ssh git@gitlab

for that to work. Now, if you do not want to write git@gitlab all the time, then you add the:

User git

to the .ssh/config file as per his example. Then you can do:

ssh gitlab

and it will know from the configuration placed in .ssh/config that we want to connect as the git user, even though I am logged in as bob. There doesn’t need to be a git user on your machine, it’s a reference to the git user on the gitlab server. The ~ is referencing your home directory on your machine to find the ssh key.

Ah, got it. Thanks! I will give it a try on the client side account.

1 Like

Adding the Port entry on the client side SSH config file with the redirect port number solved it.