6

I added an ED25519 public key to my account on gitlab.com. I then set up my .ssh/config to use the private key for Host gitlab.com:

Host gitlab.com gitlab.*.com
    User git
    IdentityFile ~/.ssh/gitlab_ed25519

When I do a git fetch, I am presented with the fingerprint of the key:

The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

I then attempted to verify this matches the public key on my machine:

$ ssh-keygen -lf ~/.ssh/gitlab_ed25519.pub
256 SHA256:Gc/kdTZNJJ0AkdRuZmXOnZw77mS2+osIHQd0pRwJxZA comment (ED25519)

These don't match. Does it matter that, even though I added an Ed25519 key on gitlab.com, that their SSH server is still reporting a fingerprint for an ECDSA key? Shouldn't it say that the fingerprint is from ED25519 instead? What am I doing wrong? Why do the fingerprints not match?

void.pointer
  • 24,859
  • 31
  • 132
  • 243

2 Answers2

8

When you run ssh-keygen -lf, you're showing the fingerprint for your key. The remote host, GitLab, also has one or more keys which differ from yours. Your key is used to identify you to the remote server and GitLab's keys are used to identify it (the server) to you, so necessarily they'll differ.

If you want to verify the fingerprints, you can go to https://gitlab.com/help/instance_configuration to find them for your GitLab and verify that they're correct.

The reason you're seeing an ECDSA key being offered is that OpenSSH prefers ECDSA over Ed25519 keys. This is less a comment on the security, as most folks agree that Ed25519 keys are just as secure (or more) as 256-bit ECDSA keys, and more for backwards compatibility. When OpenSSH added Ed25519 keys, if they had been prioritized over ECDSA keys, then a changed host key error would show up when logging in the next time.

If you want to prefer Ed25519 keys for gitlab.com, you can add the following directive to your entry in ~/.ssh/config:

HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256
bk2204
  • 64,793
  • 6
  • 84
  • 100
  • Thanks for the explanation. Maybe I'm misunderstanding the point of the fingerprint. I thought that it was a way of making sure Gitlab is using my public key, and not some other key. So Gitlab has their own key they send a fingerprint of? Why do I care about Gitlab's keys, I guess is the question? – void.pointer Sep 02 '19 at 17:28
  • 1
    As the poster mentioned, your key identifies you to GitLab. It's your unique identifier for your GitLab account. GitLab's host key identifies GitLab.com to you. It's how you can be certain you're actually talking to GitLab.com and not some man-in-the-middle attacker. The first time you connect your host will ask if you want to trust the GitLab.com host key. After the first time you won't be asked again. But, if at some point you connect to GitLab.com and the key it presents changes, your computer will throw an error about a possible man-in-the-middle attack. – Drew Blessing Sep 02 '19 at 18:18
1

Note: the link https://gitlab.com/help/instance_configuration is now more visible, directly from your settings:

See GitLab 15.3 (August 2022)

New links to SSH fingerprints

Your GitLab SSH fingerprints are now easier to find, thanks to new links on the SSH configuration page and in the documentation.

Thank you Andreas Deicha for your contribution!

https://about.gitlab.com/images/15_3/manage-ssh-fingerprint.png -- New links to SSH fingerprints

See Documentation and Issue.

That way, you can confirm that what your local ssh command is asking you about is indeed linked to gitlab.com own server.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250