Friday 4th March 2016: 8.01am. Link shared: https://stribika.github.io/2015/01/04/secure-secure-shell.html
This past year a lot of people have been locking down their SSH servers given that the Snowden files show the US is capable of reading many SSH sessions and has been building a database of private SSH keys (only a matter of time before it gets leaked), probably because most SSH servers use a default list of prime modulis. The linked article recommends a long list of things to tighten from the default including regenerating all your modulis by hand to new random ones.
However I've gone much further than I expected again as I've been rebuilding my cloud infrastructure which surprised me. I initially wanted to set a minimum compatibility level which works with putty and WinSCP from Windows which yielded this config:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key_ned
HostKey /etc/ssh/ssh_host_rsa_key_ned
PasswordAuthentication no
ChallengeResponseAuthentication no
AllowUsers <redacted>
Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-256
So, only SHA2 throughout and none of the earlier and now known broken hashes, 4096 bit only RSA for all RSA usage, and the fancy new elliptic curves are all turned on but all the NIST/NSA recommended elliptic curves are disabled. The very fashionable chacha-poly1305 cipher is preferred as is the ed25519 elliptic curve, but for standards conforming SSH clients we always have exactly one compatibility option: DHE-RSA4096-SHA256 for first contact, SHA256 HMAC for negotiation and AES128-CTR for the actual connection encryption.
All very conventional, sensible choices.
However, it turns out that WinSCP latest edition supports a far more modern config, as does putty if you compile it from source code. I've actually ended up on this perfectly minimum config stunningly enough:
KexAlgorithms curve25519-sha256@libssh.org
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key_ned
PasswordAuthentication no
ChallengeResponseAuthentication no
AllowUsers <redacted>
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com
In other words, only non-standard elliptic curve ed25519 for first contact, SHA512-ETM HMAC for negotiation and the non-standard chacha-poly1305 cipher for the connection.
None of the above are standard as is obvious from the @xxx postfix, and all are recent additions in some cases very recent additions to the OpenSSH server. You will note all of them do not use OpenSSL, and therefore the cause of the Heartbleed vulnerability a few years ago is removed - this is intentional by those who adding this support.
Ordinarily I would baulk at such a non standard and therefore incompatible config, however to be honest if all my Windows SSH clients and all my POSIX ones support it without issue, I am finding myself not caring, and the above config is enormously faster to run as RSA 4096 is very, very slow. The only real worry is the lack of deep experience with the new algorithms, however they were all designed and peer reviewed by world class cryptographers funded by the big tech multinationals as a means to solve the Snowden and Heartbleed problems, and have been adopted en mass by the big tech multinationals as a group for their internal crypto needs. So basically I am swapping US government designed crypto for US corporation collectively designed crypto under the assumption that it would be commercial suicide for corporations to deliberately weaken this stuff, unlike with the US government as we know since Snowden.
I guess we'll see how that cookie crumbles with time ...