Secure Secure Shell

It&#x27;s possible that NSA can recover keys from 1024-bit RSA&#x2F;DH&#x2F;DSA handshakes, but it&#x27;s extraordinarily unlikely that they can do so scalably; that would be an ability that currently qualifies as space-alien technology.<p>RC4 is terribly broken and should be disabled. But the practical attack on RC4 requires many repetitions of the same plaintext --- &quot;many&quot; in the millions. This is a real threat to HTTPS&#x2F;TLS, but not as much to RC4. Even hypothetical improvements to Fluhrer&#x2F;McGrew would still require lots of repetitions. Disable RC4, but if you&#x27;re playing along at home, this probably isn&#x27;t it.<p>No serious cryptographer seems to believe that the NIST curves are backdoored. Avoid them if you can; they suck for other reasons.<p>MD5 is survivable in the HMAC construction.

Looking at which key exchange protocols, HMACs etc. various other SSH implementations out there support, it seems that many of them would be barred from accessing a server hardened like that :&#x2F;. In fact, it almost seems like the intersection of mutually supported protocols is empty resp. only contains known-to-be-unsafe ones... :(.<p>Which makes me wonder: Is there anywhere a comprehensive comparison with tables that show which SSH clients (and servers) support which algorithms for key exchange, HMAC, etc.? That would help determining whom one is going to shut out by disabling which protocol, and thus help in making an informed decision on that.<p>Of course, to be really useful, such a table would also need to take into account which version of each listed software added support for which protocol -- as it is, the OpenSSH shipped in e.g. Mac OS X 10.8 (5.9p1) does not support curve25519-sha256@libssh.org which the OP recommends...<p>Sources: <a href="http://www.libssh2.org/" rel="nofollow">http:&#x2F;&#x2F;www.libssh2.org&#x2F;</a> <a href="http://api.libssh.org/stable/" rel="nofollow">http:&#x2F;&#x2F;api.libssh.org&#x2F;stable&#x2F;</a> <a href="https://support.ssh.com/manuals/server-admin/44/Ciphers_and_MACs.html" rel="nofollow">https:&#x2F;&#x2F;support.ssh.com&#x2F;manuals&#x2F;server-admin&#x2F;44&#x2F;Ciphers_and_...</a> <a href="http://www.lysator.liu.se/~nisse/lsh/lsh.html" rel="nofollow">http:&#x2F;&#x2F;www.lysator.liu.se&#x2F;~nisse&#x2F;lsh&#x2F;lsh.html</a>

&quot;Don&#x27;t install what you don&#x27;t need&quot;, but run Tor to connect to your servers via SSH. Huh?<p>Hardening SSH makes a lot of sense and this article provoked a lot of thought. But there&#x27;s too much political rant and leaps of faith for my taste. I&#x27;d like to hear some hardening guidance with more fact, less vitriol.

I&#x27;m a little surprised that SSH authentication methods can&#x27;t be easily disabled using the sshd_config file. Almost all the other security algorithms can be easily tweaked. I thought this article had just made a mistake, but I read over the man page and it appears there is indeed no way to modify this using the config file.<p>This isn&#x27;t a protocol weakness. Reading over the SSH RFCs, the server is allowed to specify which algorithms it supports, so this could easily be a OpenSSH configuration option.

I&#x27;m a bit concerned at some of the leaps of logic made in this article.<p>We&#x27;re told to discount 1024 bit exchanges because of &quot;unknown attacks&quot;. If they&#x27;re unknown, why are we determining that 2048 bits is safe? How do we know the attacks aren&#x27;t specifically against some other aspect?<p>The guide talks about creating a newer stronger host key, but doesn&#x27;t provide any information about preventing initial MITM there: ensuring you get the right host key on first connection is a major issue, and somebody trying to &quot;make NSA analysts sad&quot; ought to be explaining methods for ensuring that happens securely via host key CAs or similar tools.<p>Likewise, the suggestion for &quot;Preventing key theft&quot; is &quot;ven with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.&quot;. No insight is provided on how to actually accomplish that.<p>This is certainly a way to turn off weaker ciphers and exchanges, but passing it off as a way to &quot;make NSA analysts sad&quot; is hyperbolic and runs the risk of people believing the hype.

&quot;Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls.&quot;<p>You can encrypt the server key and only decrypt it into a loopback mount when you want to start sshd or accept a connection (I don&#x27;t remember offhand if sshd reads it only once or at each connection), then unmount it. You get the same functionality as typing in your keystore password when you start apache or netscape or whatever web server (because you encrypt your https private keys too, right?). An untested poc:<p><pre><code> # making the image mkdir TMPFS mount -t tmpfs -o size=4m tmpfs TMPFS cd TMPFS dd if=&#x2F;dev&#x2F;zero of=servkeys.img bs=1m count=2 mkfs.ext2 -F -m 0 -t ext2 servkeys.img mkdir MOUNT mount -t ext2 -o loop servkeys.img MOUNT cp &#x2F;etc&#x2F;ssh&#x2F;sshd_config MOUNT&#x2F; ssh-keygen -t rsa -b 4096 -f MOUNT&#x2F;ssh_host_key umount MOUNT gpg -se servkeys.img mv servkeys.img.gpg .. cd .. umount TMPFS # running sshd mount -t tmpfs -o size=4m tmpfs TMPFS cd TMPFS gpg -d ..&#x2F;servkeys.img.gpg &gt; servkeys.img mkdir MOUNT mount -t ext2 -o loop servkeys.img MOUNT sshd -f MOUNT&#x2F;sshd_config -h MOUNT&#x2F;ssh_host_key umount MOUNT cd .. umount TMPFS</code></pre>

The article states that host key authentication methods cannot be disabled. Instead of creating broken symlinks, you can actually specify this server-side in sshd_config (at least on CentOS 7):<p><pre><code> HostKey &#x2F;etc&#x2F;ssh&#x2F;ssh_host_rsa_key </code></pre> You can also force this on the client-side in ~&#x2F;.ssh&#x2F;config:<p><pre><code> HostKeyAlgorithms ssh-rsa </code></pre> See man pages for defaults.

FWIW, I have submitted a somewhat similar configuration as a pull request for ioerror&#x27;s duraconf project at <a href="https://github.com/ioerror/duraconf/pull/52" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ioerror&#x2F;duraconf&#x2F;pull&#x2F;52</a>.<p>This project also hosts secure ciphersuite configurations for postfix, nginx, apache, GPG, etc.

In the Symmetric ciphers section, it ends with &quot;This leaves 5-9 and 15&quot; but why are 2-4 bad (aes128-cbc, aes192-cbc, aes256-cbc)? It seems the argument is that GCM is better than CBC, and CTR is okay. My general impression is that CBC is preferred (for example, Rails uses AES-256-CBC by default in its MessageEncryptor class).

Instead of storing keys on a pendrive, consider using smart cards or some other crypto devices for that purpose. There are some tradeoffs involved, so research before acting.

Unfortunately it seems that the latest version of PuTTY (0.63) does not support any of the advised MAC&#x27;s.

Hey All, OSX user here, i&#x27;m having trouble trying to replicate the config on my machine. Thusfar i&#x27;ve found, If you using a mac, things are slightly different, ie, &#x2F;etc&#x2F;ssh&#x2F;ssh_config Is actually &#x2F;etc&#x2F;ssh_config &#x2F;etc&#x2F;ssh&#x2F;sshd_config Is actually &#x2F;etc&#x2F;sshd_config &#x2F;etc&#x2F;ssh&#x2F;moduli Is actually &#x2F;private&#x2F;etc&#x2F;moduli<p>That&#x27;s as far as i can tell anyway. I&#x27;m not sure what to do when it comes to authentication however. I&#x27;m assuming that your supposed to be editing &#x2F;etc&#x2F;ssh_config&#x2F; however i don&#x27;t know if i&#x27;m supposed to remote the &#x27;#&#x27; from any lines i&#x27;m editing? I also dont appear to have any files that i can find called ssh_host_rsa_key nor is there a &#x27;HostKey&#x27; line in the ssh_config file.<p>Any help would be most appreciated!

For the MAC, the article suggests an exception to github.com. But it looks like an exception is required for the Kex protocol as well. I see this error:<p><pre><code> Unable to negotiate a key exchange method </code></pre> If I understand correctly the response from ssh -v -v, github.com only supports the following Kex protocols:<p>ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss<p>Edit: By trial and error, I find that this works for github.com:<p>KexAlgorithms diffie-hellman-group1-sha1

&gt; Some of the supported algorithms are not so great and should be disabled completely. If you leave them enabled but prefer secure algorithms, then a man in the middle might downgrade you to bad ones.<p>How does that work? The algo exchange is authenticated too.

This seems like a great idea. Unfortunately most of the recommendations seem to not be supported on my MacOS machine. Also, when I paired it down to the ones that are supported I wasn&#x27;t able to connect to github. :( Very annoying.

&quot;ssh-keygen -G &#x2F;tmp&#x2F;moduli -b 4096 ssh-keygen -T &#x2F;etc&#x2F;ssh&#x2F;moduli -f &#x2F;tmp&#x2F;moduli<p>This will take a while so continue while it’s running.&quot;<p>First line has taken 6 hours on an ec2 t1.micro.

One thing bothers me:<p>&gt; Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls.<p>That should be solvable with systemd and fuse - create an encrypting filesystem with a fixed key obtained from an USB pendrive, which is then ejected (so it would need a reboot to be enumerated again), and have the filesystem limit open() calls to the key file. It should not need more than one read call when openssh starts.

Would&#x27;nt NSA attempts at cracking encryption systems basically be free audits on those encryption systems. (providing the public some how figures out how it was broken.)

Every now and again I step back and think of the absurdity of us having to take all of these precautions to stay safe from the people employed to represent our interests

To say the least, the number of recommended options here which are not supported on the version of openssh which comes with OS X is disappointing.

Based on the Snowden documents and the fact[?] that the NSA can decrypt SSH at least some of the time the author advocates disabling some of the weak points of SSH. He also describes how to go about doing so.

It&#x27;s possible the NSA doesn&#x27;t give a shit about your shit too.

&gt; Use free software: As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows.<p>Maybe this person forgot about Heartbleed? Or that Debian bug that was around for years? Or Shellshock, dating back to 1989?<p>Stop pretending and assuming that just because software is open source that it is automatically reviewed.