I have two separate accounts on gitlab.com (different companies). Two distinct ssh key pairs are uploaded to each. In terminal I see this behavior:
$ ssh -i ~/.ssh/A git@gitlab.com
client_global_hostkeys_private_confirm: server gave bad signature for RSA key 0
PTY allocation request failed on channel 0
Welcome to GitLab, @USERNAME1!
Connection to gitlab.com closed.
$ ssh -i ~/.ssh/B git@gitlab.com
client_global_hostkeys_private_confirm: server gave bad signature for RSA key 0
PTY allocation request failed on channel 0
Welcome to GitLab, @USERNAME1!
Connection to gitlab.com closed.
Important part is that they both show USERNAME1 even though different keypairs are being used.
I have double checked that key pairs ~/.ssh/{A,B} are not the same and they correspond to public keys uploaded to accounts USERNAME{1,2}.
Initially I noticed this when I was unable to clone a repository with permission errors. One username does not have permissions for project under other account.
It also means that I am able to clone a repository under one account using ssh key configured in different account! That should not happen:
# cat ~/.ssh/config
# ...
# host testtt
# hostname gitlab.com
# identityfile ~/.ssh/username1-key
# ...
$ git clone git@testt:group-of-user2/private-project.git
Cloning into 'private-project'...
client_global_hostkeys_private_confirm: server gave bad signature for RSA key 0
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
$ ls
private-project
Other potentially useful info:
Initially when I observed this both ssh A and ssh B greeted USERNAME2 instead of 1
Discarding both key pairs for new ones (ssh-keygen -t rsa -b 4096) did not help
Couple days before everything worked without problems
That bad signature for RSA is unexpected but I am able to clone from given username
It must either be something trivial on my side or some issue in gitlab infrastructure. The former seems more likely. Any ideas please?
So it turns out ssh-agent is serving whichever key for given domain. This is by actual domain not alias name from ssh config file. Using only explicitly assigned identity files has to be explicitly enabled by setting IdentitiesOnly=yes for give alias in ssh config file.
It looks like this is actually pretty common issue. I hope at least it will help somebody here on forum later.
Reading this would have helped me with a completely different problem about a month ago.
And if you hadn’t found the answer yourself before I saw this, I could have told you exactly what you figured out. The -i option to ssh basically doesn’t mean “use this key”, but “make this key an option”, when another option works might follow.
Another way is you can create a .ssh/config and in here you can use something like this:
HOST rpi4
HOSTNAME rpi4.mydomain.com
USER ian
IDENTITYFILE ~/.ssh/id_ed25519
both my id_rsa and id_ed25519 keys are on the Raspberry PI. by default it would always use RSA, no matter whether the ED25519 was before the RSA in the authorized_keys in the Raspberry PI, doesn’t matter which order. Therefore, just creating those entries above in the .ssh/config file means I can just write ssh rpi4, and it will connect and use the ED25519 key directly. The HOSTNAME field can also be just the IP address instead of an FQDN, and it will still work.
@james64 strange, I just replicated it here using similar config to you, and worked for me. I’m using Linux Mint latest, so not sure if there is something unique in my particular SSH setup, as the files are pretty much the defaults for /etc/ssh/ssh_config. Either that unless it’s more version-specific:
ian@elise:~$ ssh -V
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f 31 Mar 2020
I mostly connect to Debian 10 or Ubuntu 18.04/20.04 servers, as not running anything else.
