Linux – get SSH key fingerprint in (old) hex format on new version of openssh

freebsdlinuxopensshssh

It seems that openssh has changed the way it displays key fingerprints.

I am trying to ssh from a client machine to a server:

client: ubuntu 14.04 running OpenSSH 6.6.1
server: FreeBSD running OpenSSH 7.2p2.

The client reports the md5 hash of the server's key as a sequence of 16 pairs of hex digits, like this:

a7:b1:3e:3d:84:24:a2:5a:91:5f:6f:e9:cf:dd:2b:6a

The server defaults to using the sha256 hash, but thanks to this answer I can force it to give the sha1 hash by running:

[root@host /etc/ssh]# ssh-keygen -l -E sha1 -f ssh_host_ecdsa_key.pub

I want the result to look like this:

a7:b1:3e:3d:84:24:a2:5a:91:5f:6f:e9:cf:dd:2b:6a

but instead I get this:

256 SHA1:KIh0ejR4O+RqrSq7JdGAASddRfI root@host.local (ECDSA)

It looks to me like a base64 encoded version of the fingerprint is now being displayed instead of hex digits.

How can I get the checksum of the server's key in the same format as that reported by the (older) client (colon separated hex digits, sha1 hash) so as to check that they are the same?

EDIT:
The old version of SSH gives the md5 checksum, not the sha1 checksum as I mistakenly thought. Using that checksum (as the now accepted answer should state) in the -E option gives the desired output.

Best Answer

The client reports the sha1 hash of the server's key as a sequence of 16 pairs of hex digits, like this:
    a7:b1:3e:3d:84:24:a2:5a:91:5f:6f:e9:cf:dd:2b:6a

This is MD5 hash.

As you can see running

ssh-keygen -l -E md5 -f ssh_host_ecdsa_key.pub

will get you the same fingerprint you need without such harakiri you are explaining in your answer.

Related Solutions

OpenSSH: Slow typing speed when in pseudo terminal

Unfortunately I can't comment yet.

What comes to my mind on the client:

Have you had a look at top to see the CPU load? Maybe the SSH process uses up CPU for encryption.

Have you had a look at ssh -v[vv] and inspected for some strangeness? Maybe server and client agree on a very secure cipher or MAC. Have a look for

debug2: ciphers ctos: arcfour
debug2: ciphers stoc: arcfour
[...]
debug1: kex: server->client cipher: arcfour MAC: hmac-sha2-256-etm@openssh.com compression: zlib@openssh.com
debug1: kex: client->server cipher: arcfour MAC: hmac-sha2-256-etm@openssh.com compression: zlib@openssh.com

(where arcfour is really one of the weakest, lowest-CPU algorithms. I am connecting via an SSH proxy). Also, look for rekeying messages.

Also, compression might be an issue. However, ssh does not seem to be too explicit about the compression level here.

debug2: compression ctos: zlib@openssh.com,zlib,none
debug2: compression stoc: zlib@openssh.com,zlib,none

You didn't say explicitly, how 'remote' your remote servers are. In the same network, in a different network on the same campus, via the internet?

If via the internet, maybe your corporate firewall is deep-inspecting SSH traffic on port 22. Maybe a port change could help, if you can control the SSH servers /etc/ssh/sshd_config file.

If via the internet, is SSH the 'only' tunnel you use, or are you using SSH via an additional VPN?

If on the same campus, also firewalling, routing, inspecting issues come to my mind. I once was blaming my internet provider for problems with my internet; it was damn slow. Went on for days. Until I found out that I enabled debugging on my Cisco router, which ate up resources there.

If local or remote, are you connecting directly or via an SSH proxy, gateway or jump host? In that case, like with the VPN, you have double encryption.

Linux – How to check if your ssh keys are in the ssh-rsa2 format

The key format has not changed. The only thing that changes is the signature format that's sent during each authentication handshake.

What makes everything confusing is that originally in SSHv2, the key type and the signature type used to be defined in combination. (For example, the same "ssh-rsa" identifier was defined to mean RSA keys and RSA/SHA-1 signatures.) So changing the signature process would have meant assigning a new key type identifier, and that would have meant generating a new key...

However, protocol extensions have been developed to avoid this, and modern SSH clients will automatically negotiate the signature types whenever RSA keys are involved. If you connect with ssh -v you will notice a few additional packets being exchanged:

debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,
                            rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,
                            ecdsa-sha2-nistp521>

So you can continue using "ssh-rsa" keys – you only need to upgrade the software on both ends to something reasonably recent, and it will automatically start producing "rsa-sha2-256" signatures from that key. (For example, you might need to install a new version of PuTTY and Pageant, and you might have troubles with older versions of gpg-agent.)

Signatures in ssh-keygen

the default option rsa for the -t argument explains that the chosen option is using the SHA1 signature, so one should choose rsa-sha2-256 for example.

This applies when issuing certificates, but is irrelevant when generating plain keys.

Each certificate is signed by the parent CA at the time it is issued. This long-term signature is stored in the certificate itself (and it's very important to realize that this is a different thing from the short-term signatures that are made during each connection and then thrown away). That's why many HTTPS (X.509) certificates had to be replaced – the issuing CA had stamped them with RSA/SHA-1 signatures.

OpenSSH has also created its own certificate format, which is what the manual page is referring to. These so-called "SSH certificates" are not just regular SSH keys – they're additionaly signed by e.g. your workplace CA. So if you have files whose names end with *-cert.pub, you might need to have those re-issued. (Use ssh-keygen -Lf <file> to check how they were signed).

But plain SSH keys do not hold any long-term signature inside – they're only used to make temporary signatures during each connection. So there is nothing that needs replacement in the key itself.

The `-l` option

I tried checking the type of the key with ssh-keygen -l -f key and it shows me that it is indeed SHA256 type

No, that is not what ssh-keygen shows at all. The -l option is showing you the key's "fingerprint" and it's telling you that it used SHA256 to compute this fingerprint – but it has nothing to do with the key's type, nor with how the key will actually be used. The fingerprint is just a hash that was computed right now in order to be shown to you.

(Remember that previously SSH software used to show MD5-based key fingerprints – even though there was no MD5 usage in the actual SSHv2 protocol.)

Other key types

Is this the type not recommended anymore and I should switch for example, to ECDSA?

From what I know (i.e. from what I gathered on Security.SE), RSA as a signature algorithm is still strong – problems mostly just occur when trying to use RSA as an encryption algorithm, and that's not an issue with SSHv2. (Well, the ever-increasing key size is not great either.)

ECDSA has its own problems – it is difficult to get its implementation right and certain kinds of programmer mistakes can be disastrous. If you had to switch, EdDSA (that is ssh-ed25519 or ssh-ed448) would be a better option.