For SSHv2 key exchange:

Recommended: diffie-hellmann-group14-sha1 (2048 bit) for SSH key exchange

Allowed:  ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521

Avoid: diffie-hellman-group1-sha1 (768 bit),diffie-hellman-group2-sha1 (1024 bit)

dh group 1 should not be used based on this research paper “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice.”  In addition, dh group 2 and below are susceptible to the logjam attack.

All sessions must be rejected if remote client or server is only advertising non Common Criteria compliant algorithms and key sizes in the hello.  Disable export algorithms.

SSH authentication public key algorithms:

Use: ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-nistp384, x509v3-ecdsa-sha2-nistp521

Avoid: ssh-dsa

DSA can be broken when one nonce is known.  See https://projectbullrun.org/dual-ec/documents/dual-ec-20150731.pdf (p. 18)

“If a signature scheme based on the digital signature algorithm (DSA, designed
by NSA) is used for server authentication, the knowledge of just one signature
nonce enables the attacker to compute the server’s secret identity key and thus
to impersonate the server.”

SSH transport data integrity:

Use: hmac-sha1, hmac-sha2-256, hmac-sha2-512, AEAD_AES_128_GCM, AEAD_AES_256_GCM

Avoid: hmac-md5, hmac-sha1-96

SSH transport data encryption:

Use: aes123-ctr, aes256-ctr, AEAD_AES_128_GCM, AEAD_AES_256_GCM

Avoid: aes123-cbc, aes256-cbc

OpenSSH incorrectly implemented AES in cbc mode.  As a result, AES-CBC mode in OpenSSH has exploited by the University of London.  This is a nation state level attack, and is not considered to be an easy attack to implement.

OpenSSH has disabled AES in cbc mode in versions 7.x, 6.9, and 6.7.  See the OpenSSH release notes for more information: https://www.openssh.com/releasenotes.html.  CVE info: http://www.kb.cert.org/vuls/id/958563

Using the nistp elliptic curves may be unsafe per SafeCurves web site: http://safecurves.cr.yp.to – Lange and Bernstein.  The nistp curves are still considered to be computationally safe, but can be difficult to implement the NIST ECC correctly per Bernstein and Lange.

Note:  The nistp being unsafe by Bernstein above is in dispute with other cryptographers.

Additional Notes:

  • An interesting distinction between SSH and TLS is that when SSH uses ecdh for key exchange, it is automatically using ephimeral keys.  The “E” in ECDHE is unnecessary because ECDH without ephimeral keys is not supported in SSHv2.

From RFC 5656, section 3.1.2:

The Elliptic Curve Diffie-Hellman (ECDH) key exchange method generates a shared secret from an ephemeral local elliptic curve private key and ephemeral remote elliptic curve public key. This key exchange method provides explicit server authentication as defined in [RFC4253] using a signature on the exchange hash.

  • The sha-1 in the dh-group-14-sha1 is actually a sha-1 and not hamc-sha1, but it is considered to be safe to use in this case.

SSH RFCs:

4251 — SSH protocol architecture – high level doesn’t go into algorithms or key sizes

4252 – SSH authentication protocol – again high-level protocol description

4253 – SSH transport layer protocol – identify the two KEX algorithms DH group 1 and group 14 (section 6.5). This is where group 14 came from. RFC also identifies the encryption algorithms (section 6.3) and integrity algorithms (section 6.4)

4254 – SSH connection protocol – again high-level protocol description

5647 – This adds AES-GCM as an encryption algorithm. So if your product claims AES-GCM for SSH, make sure you claim this RFC.

5656 – This adds ECC algorithms. So if you claim any ECDH algorithms in .1.7,  make sure you claim this RFC.

6187 – This adds X.509 certificates for authentication. So if your product claims x509v3-* in .1.5, make sure you claim this RFC.

6668 – This adds SHA-2 as an integrity algorithm. So if your product claims hmac-sha2-256 or hmac-sha2-512, make sure you claim this RFC.

4251 — SSH protocol architecture – high level doesn’t go into algorithms or key sizes

4252 – SSH authentication protocol – again high-level protocol description

4253 – SSH transport layer protocol – identify the two KEX algorithms DH group 1 and group 14 (section 6.5). This is where group 14 came from. RFC also identifies the encryption algorithms (section 6.3) and integrity algorithms (section 6.4)

4254 – SSH connection protocol – again high-level protocol description

5647 – This adds AES-GCM as an encryption algorithm. So if your product claims AES-GCM for SSH, make sure you claim this RFC.

5656 – This adds ECC algorithms. So if you claim any ECDH algorithms in .1.7,  make sure you claim this RFC.

6187 – This adds X.509 certificates for authentication. So if your product claims x509v3-* in .1.5, make sure you claim this RFC.

6668 – This adds SHA-2 as an integrity algorithm. So if your product claims hmac-sha2-256 or hmac-sha2-512, make sure you claim this RFC.