Which host key algorithm is best to use for SSH?

Question

When you first connect to an SSH server that is not contained inside your known_hosts file your SSH client displays the fingerprint of the public key that the server gave. I found from this question here that as a client you are able to specify within ssh_config which one of the public key pairs from the hosts' /etc/ssh/ directory you would like.

From the ssh_config man page I found that the current defaults are as follows:

    [email protected],
    [email protected],
    [email protected],
    [email protected],
    [email protected],
    [email protected],
    ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,
    ecdsa-sha2-nistp521,ssh-ed25519,
    ssh-rsa,ssh-dss

Only recently my SSH server has been sending me a ECDSA fingerprint instead of an RSA, but I was wondering which algorithm should I choose if it even matters?

This article claims that ECDSA is the old elliptic-curve DSA implementation that is known to have severe vulnerabilites Should I be using RSA or the newest ed25519 algorithm?

Answer 1

Currently,

• RSA is still recommended as a gold standard (strong, widely compatible).
• ed25519 is good (independent of NIST, but not compatible with all old clients).

Server is usually providing more different host key types, so you are targeting for compatibility. The order of priority in the client config is from the stronger to more compatible ones.

Frankly, for you, as an end user, it should not matter. Some of the keys might have some security concerns, but none of them is considered completely broken with reasonable lengths, which could possibly cause man-in-the-middle attack or something similar.

The article mentions "severe vulnerabilities", but not saying anything specific. If it had such severe vulnerability, nobody would use it, support it, nor recommend it. Without any reference, it is pretty hard to comment on your concerns.

Answer 2

Since the algorithms are in a state of flux, I find that using an ssh-audit tool (available on Github) (here's a more recent fork) to be extremely useful.

Example output of a current but secured SSH settings is given below:

# general
(gen) banner: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
(gen) software: OpenSSH 6.7p1
(gen) compatibility: OpenSSH 6.5+, Dropbear SSH 2013.62+
(gen) compression: enabled ([email protected])

# key exchange algorithms
(kex) [email protected]          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256  -- [warn] using custom size modulus (possibly weak)
                                            `- [info] available since OpenSSH 4.4

# host-key algorithms
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5
(key) ssh-rsa                               -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28

# encryption algorithms (ciphers)
(enc) [email protected]         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9.
(enc) [email protected]                -- [info] available since OpenSSH 6.2
(enc) [email protected]                -- [info] available since OpenSSH 6.2
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) [email protected]         -- [info] available since OpenSSH 6.2
(mac) [email protected]         -- [info] available since OpenSSH 6.2
(mac) [email protected]              -- [info] available since OpenSSH 6.2
(mac) hmac-sha1                             -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28

# algorithm recommendations (for OpenSSH 6.7)
(rec) -hmac-sha1                            -- mac algorithm to remove

Settings used for /etc/ssh/sshd_config:

KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
# Following MACs does not work on Mac OSX 10.10 or older
MACs [email protected],[email protected],[email protected],hmac-sha1

Settings used for /etc/ssh/ssh_config:

HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,ssh-rsa
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
MACs [email protected],[email protected],[email protected],hmac-sha1
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

Answer 3

CHOOSING AN ALGORITHM AND KEY SIZE

SSH supports several public key algorithms for authentication keys. These include:

• rsa - an old algorithm based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm may be advisable. It is quite possible the RSA algorithm will become practically breakable in the foreseeable future. All SSH clients support this algorithm.

• dsa - an old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.

• ecdsa - a new Digital Signature Algorithm standarized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. We would recommend always using it with 521 bits, since the keys are still small and probably more secure than the smaller keys (even though they should be safe as well). Most SSH clients now support this algorithm.

• ed25519 - this is a new algorithm added in OpenSSH. Support for it in clients is not yet universal. Thus its use in general purpose applications may not yet be advisable.

see https://www.ssh.com/academy/ssh/keygen#choosing-an-algorithm-and-key-size