The fingerprint is just a hash that was computed right now in order to be shown to you. 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. No, that is not what ssh-keygen shows at all. I tried checking the type of the key with ssh-keygen -l -f key and it shows me that it is indeed SHA256 type So there is nothing that needs replacement in the key itself. (Use ssh-keygen -Lf to check how they were signed).īut plain SSH keys do not hold any long-term signature inside – they're only used to make temporary signatures during each connection. So if you have files whose names end with *-cert.pub, you might need to have those re-issued. These so-called "SSH certificates" are not just regular SSH keys – they're additionaly signed by e.g.
OpenSSH has also created its own certificate format, which is what the manual page is referring to. That's why many HTTPS (X.509) certificates had to be replaced – the issuing CA had stamped them with RSA/SHA-1 signatures. 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). This applies when issuing certificates, but is irrelevant when generating plain keys.Įach certificate is signed by the parent CA at the time it is issued. 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.
(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
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. If you connect with ssh -v you will notice a few additional packets being exchanged: debug1: SSH2_MSG_EXT_INFO receivedĭebug1: kex_input_ext_info: server-sig-algs= However, protocol extensions have been developed to avoid this, and modern SSH clients will automatically negotiate the signature types whenever RSA keys are involved. (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. What makes everything confusing is that originally in SSHv2, the key type and the signature type used to be defined in combination. The only thing that changes is the signature format that's sent during each authentication handshake.