
Secure Secure Shell - padraic7a
https://stribika.github.io/2015/01/04/secure-secure-shell.html
======
tptacek
It's possible that NSA can recover keys from 1024-bit RSA/DH/DSA handshakes,
but it's extraordinarily unlikely that they can do so scalably; that would be
an ability that currently qualifies as space-alien technology.

RC4 is terribly broken and should be disabled. But the practical attack on RC4
requires many repetitions of the same plaintext --- "many" in the millions.
This is a real threat to HTTPS/TLS, but not as much to RC4. Even hypothetical
improvements to Fluhrer/McGrew would still require lots of repetitions.
Disable RC4, but if you're playing along at home, this probably isn't it.

No serious cryptographer seems to believe that the NIST curves are backdoored.
Avoid them if you can; they suck for other reasons.

MD5 is survivable in the HMAC construction.

~~~
pbsd
It is conceivable, with the right tradeoffs, that computing individual
discrete logs over a few popular 1024-bit moduli could be made cheap. However,
none of the available evidence suggests this practice.

There is a lot of inconsistent thinking behind the advice given in the
article:

\- Hard-to-implement NIST curves suck, whereas GCM and Poly1305 are
recommended.

\- NIST apparently sucks, but NSA-designed SHA-2 is recommended.

\- MACs need 256-bit tags, so UMAC and not-NSA-designed RIPEMD160 is
apparently not fine, but GCM/Poly1305's 128-bit tags are recommended. On this
note, 256-bit tags are pointless when the rest of the crypto infrastructure is
sitting on 128-bit security.

\- 3DES is not recommended because DES is 'broken', not realizing that this
break is due to small key length of the original DES; 3DES is deemed to be
quite secure (but _slow_ ).

\- 64-bit block size is enforced, but for no good reason: SSH's 32-bit
sequence number, along with counter mode, renders block size worries moot.

~~~
higherpurpose
I think the reason why many still think SHA2 is safe is mainly because of
Bitcoin. There's a lot of money at stake and many crypto experts working with
Bitcoin. If there was a hole, it's possible someone would've found it. AES was
also designed by NSA and is considered safe.

That said, I think it's better to avoid them anyway just to give another hit
to NIST/NSA. Plus, ChaCha20 and BLAKE2 have much better performance in
software than AES and SHA2/SHA3 anyway, so I would like to see those adopted
as _default_ options instead.

~~~
pbsd
> AES was also designed by NSA

No, it was designed by Joan Daemen and Vincent Rijmen, two Belgian academics.

------
BlackFingolfin
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 :/. In fact, it almost seems like
the intersection of mutually supported protocols is empty resp. only contains
known-to-be-unsafe ones... :(.

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.

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...

Sources: [http://www.libssh2.org/](http://www.libssh2.org/)
[http://api.libssh.org/stable/](http://api.libssh.org/stable/)
[https://support.ssh.com/manuals/server-
admin/44/Ciphers_and_...](https://support.ssh.com/manuals/server-
admin/44/Ciphers_and_MACs.html)
[http://www.lysator.liu.se/~nisse/lsh/lsh.html](http://www.lysator.liu.se/~nisse/lsh/lsh.html)

~~~
jamiesonbecker
This is a good idea. I'm thinking about adding functionality to the next
version of Userify that will provide customization of ciphersuites (etc) on
the sshd_config side. It'd be even cooler if it used just this sort of table.

~~~
BlackFingolfin
For fun, I started work on this. It's still rather crude, and the code is
hackish, but anyway: Comparison page: [http://ssh-
comparison.quendi.de/comparison.html](http://ssh-
comparison.quendi.de/comparison.html)

Git repository: [https://github.com/fingolfin/ssh-
comparison](https://github.com/fingolfin/ssh-comparison)

Improvements are highly welcome; not just adding more clients, but also on
refactoring the code, improving the UI (I suck at HTML), adding features...
The TODO already lists some ideas.

~~~
jamiesonbecker
This is excellent, thanks BlackFinGolfin!

------
Spooky23
"Don't install what you don't need", but run Tor to connect to your servers
via SSH. Huh?

Hardening SSH makes a lot of sense and this article provoked a lot of thought.
But there's too much political rant and leaps of faith for my taste. I'd like
to hear some hardening guidance with more fact, less vitriol.

~~~
drzaiusapelord
I can't imagine running a tor client on a production server and question its
safety on my desktop (When I use it, I run up a disposable VM that gets
wiped). So run software that connects you to the most hostile network out
there and hope to god everything is secure on the client side of things?

This is the problem with trying to fight the NSA or some other over-inflated
bogeyman. If you focus on weird edge cases you lose sight of practical
security. I'd be more worried about opening myself to tor than some theorized
attack on ssh ciphers.

Unfortunately, it seems network security has become fairly political, and if
you don't make jabs at the NSA, while of course ignoring other state actors,
then you won't be put on HN and reddit, which always welcomes politicized
information at the cost of accuracy. I hope this hysteria is temporary and
cooler heads will prevail and the Alex Jones listening crowd will stop holding
the microphone.

~~~
resonantcore
> I'd be more worried about opening myself to tor than some theorized attack
> on ssh ciphers.

Most of the attacks launched on Tor aren't in the "remote takeover of the tor
server via memory corruption" category, they have (in recent history) mostly
been in the form of:

    
    
        * Attack firefox.exe in Tor Browser Bundle
        * Control a lot of nodes, do something networky to discover the user's actual IP/location
    

What is the threat you anticipate will result from "opening yourself to Tor"?

~~~
drzaiusapelord
Yes, these are the attacks we know of, and the first one only because the FBI
told us so. I suspect Tor is a lot more targeted and dangerous than people
assume and using it casually to administer servers is asinine.

------
jonawesomegreen
I'm a little surprised that SSH authentication methods can'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.

This isn'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.

~~~
ZoFreX
I found this extremely concerning too. It should be possible to modify these
options without resorting to hacks (that may break when OpenSSH is upgraded)
_if_ these modifications are indeed necessary. From some of the comments here
it's clear that this article is a mixture of good, bad, and silly advice - do
those other authentication methods actually need disabling?

------
akerl_
I'm a bit concerned at some of the leaps of logic made in this article.

We're told to discount 1024 bit exchanges because of "unknown attacks". If
they're unknown, why are we determining that 2048 bits is safe? How do we know
the attacks aren't specifically against some other aspect?

The guide talks about creating a newer stronger host key, but doesn'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
"make NSA analysts sad" ought to be explaining methods for ensuring that
happens securely via host key CAs or similar tools.

Likewise, the suggestion for "Preventing key theft" is "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.". No insight is provided on how to
actually accomplish that.

This is certainly a way to turn off weaker ciphers and exchanges, but passing
it off as a way to "make NSA analysts sad" is hyperbolic and runs the risk of
people believing the hype.

~~~
tptacek
We don't know exactly the design of a rig that would solve a 1024-bit discrete
log or factoring problem, but we have a decent idea of what it would probably
cost, and most VC firms could fund it.

Costs don't scale linearly. No math projection puts 2048 bit keys in reach.
The thing that breaks 2048 bit RSA may well put RSA completely out of action,
a reason to prefer alternatives to RSA over 4096-bit keys.

~~~
akerl_
Granted, but if that's the concern, that's what the article ought to be
explaining:

We are aware of the infrastructure to break 1024-bit discrete logs, and it's
feasible; current projections put 2048 bit key safely out of reach for the
time being, so we'll disable 1024 and leave 2048 enabled.

My concern there is with the talk of 'unknown attacks' and then providing
suggestions based on that statement.

------
peterwwillis
"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."

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'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:

    
    
      # making the image
      mkdir TMPFS
      mount -t tmpfs -o size=4m tmpfs TMPFS
      cd TMPFS
      dd if=/dev/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 /etc/ssh/sshd_config MOUNT/
      ssh-keygen -t rsa -b 4096 -f MOUNT/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 ../servkeys.img.gpg > servkeys.img
      mkdir MOUNT
      mount -t ext2 -o loop servkeys.img MOUNT
      sshd -f MOUNT/sshd_config -h MOUNT/ssh_host_key
      umount MOUNT
      cd ..
      umount TMPFS

~~~
jlgaddis
After a reboot, how do you access the server in order to perform the mount and
start sshd?

~~~
peterwwillis
Out of band. A vSphere console, VPN, KVM, LOM, modem... As a super-cheap
alternative, a bastion host vps can be the intermediary. After connecting to
the bastion host, you can then connect over the cloud provider's private
network to a stripped-down remote shell on the target, and enter the password
to bring up the public remote shell. Keeps the real keys safe, adds a layer in
front of the target, and is convenient enough to administer from a mobile
device.

------
jamielinux
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):

    
    
      HostKey /etc/ssh/ssh_host_rsa_key
    

You can also force this on the client-side in ~/.ssh/config:

    
    
      HostKeyAlgorithms ssh-rsa
    

See man pages for defaults.

------
ouaibe
FWIW, I have submitted a somewhat similar configuration as a pull request for
ioerror's duraconf project at
[https://github.com/ioerror/duraconf/pull/52](https://github.com/ioerror/duraconf/pull/52).

This project also hosts secure ciphersuite configurations for postfix, nginx,
apache, GPG, etc.

------
schizoidboy
In the Symmetric ciphers section, it ends with "This leaves 5-9 and 15" 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).

~~~
higherpurpose
Apparently implementing CBC correctly is too complex to do right:

[https://www.imperialviolet.org/2013/10/07/chacha20.html](https://www.imperialviolet.org/2013/10/07/chacha20.html)

~~~
tptacek
No, that's not what he's saying. He's saying that making the TLS CBC
constructions secure is hard. They were designed in the 1990s. Making a CBC
implementation secure today is much easier.

------
zokier
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.

------
dtech
Unfortunately it seems that the latest version of PuTTY (0.63) does not
support any of the advised MAC's.

~~~
vacri
Unfortunately PuTTY still isn't served over https, even after all these years.
If you're concerned about esoteric MITM attacks, this is worth remembering...

~~~
rb12345
Considering that PuTTY has GPG signatures, there is no need for downloading it
over HTTPS. Of course, this does leave the issue of how to obtain and confirm
the right GPG key for verifying the download.

------
osxuserhere
Hey All, OSX user here, i'm having trouble trying to replicate the config on
my machine. Thusfar i've found, If you using a mac, things are slightly
different, ie, /etc/ssh/ssh_config Is actually /etc/ssh_config
/etc/ssh/sshd_config Is actually /etc/sshd_config /etc/ssh/moduli Is actually
/private/etc/moduli

That's as far as i can tell anyway. I'm not sure what to do when it comes to
authentication however. I'm assuming that your supposed to be editing
/etc/ssh_config/ however i don't know if i'm supposed to remote the '#' from
any lines i'm editing? I also dont appear to have any files that i can find
called ssh_host_rsa_key nor is there a 'HostKey' line in the ssh_config file.

Any help would be most appreciated!

~~~
richardwhiuk
ftr /etc on Mac and /private/etc are the same. It looks like the contents of
/etc/ssh is in /etc on Mac OS X's SSH

------
hrjet
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:

    
    
       Unable to negotiate a key exchange method
    

If I understand correctly the response from ssh -v -v, github.com only
supports the following Kex protocols:

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

Edit: By trial and error, I find that this works for github.com:

KexAlgorithms diffie-hellman-group1-sha1

~~~
emilianoheyns
Doesn't the article suggest a KexAlgorithms exception rather than a MACs
exception? I get the same error, but adding the above KexAlgorithms doesn't
help

~~~
hrjet
The article seems to have been updated pretty heavily. We might have been
looking at different versions.

Here's the complete change log:
[https://github.com/stribika/stribika.github.io/commits/maste...](https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-
secure-shell.md)

------
tedunangst
> 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.

How does that work? The algo exchange is authenticated too.

~~~
lmm
How can it be? What algorithm could you possibly use to authenticate the part
where you negotiate which authentication algorithm to use?

~~~
tedunangst
Itself. :)

You could possibly force a weaker DH kex I think, but there's no way to force
e.g., rc4 with hmac-md5. Disabling group1 is a pretty big interop hit, though.

------
mightybyte
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't able to connect to github. :( Very annoying.

~~~
newman314
Agreed. And to add to it, even though Yosemite has OpenSSH 6.2p2, it has most
of the newer features disabled.

FWIW, this is what I have in my config file on Mac.

    
    
      Ciphers aes256-ctr,aes128-ctr
      MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1

~~~
alwillis
See
[https://news.ycombinator.com/item?id=8849392](https://news.ycombinator.com/item?id=8849392)
for how to safely upgrade Yosemite’s OpenSSH to 6.6p1.

------
dgulino
"ssh-keygen -G /tmp/moduli -b 4096 ssh-keygen -T /etc/ssh/moduli -f
/tmp/moduli

This will take a while so continue while it’s running."

First line has taken 6 hours on an ec2 t1.micro.

~~~
alwillis
The second line took a little over 3 hours on my 5 year old MacBook Pro.

------
mschuster91
One thing bothers me:

> 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.

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.

~~~
mhurron
That actually makes setting up SELinux seem like the simpler route.

~~~
mschuster91
iirc SELinux can only restrict the process groups that are able to read the
file, which doesn't help you in a remote code execution exploit inside
openssh.

The question is, is is possible to use the keys without having them in RAM any
more?

~~~
falcolas
> which doesn't help you in a remote code execution exploit inside openssh

To be fair, If it gets to the point where they are executing arbitrary code in
the openssh process, your key is already compromised.

SELinux would help with most other causes of key leaks, however.

> The question is, is is possible to use the keys without having them in RAM
> any more?

In my (albeit limited) experience, no. Even if only because context switching
would push the key out of the CPU registers and into RAM if it occurred at the
wrong time.

~~~
jamiesonbecker
> To be fair, If it gets to the point where they are executing arbitrary code
> in the openssh process, your key is already compromised.

This. Exactly.

------
bananaboydean
Would'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.)

~~~
orclev
Assuming they bothered to share the results of those attempts sure. The
problem of course is that the NSA is both attempting, and in some cases
succeeding in cracking encryption systems but keeping it all locked away
behind security clearances. In the past we've learned quite a bit about the
weaknesses of various crypto systems via post-mortems of NSA exploits, but it
always comes well after the fact that the encryption is weak and broken has
already become if not common knowledge than at least largely assumed. E.G.
it's probably a safe bet that 1024 bit encryption is either broken by the NSA
currently, or is likely to be broken soon, but it will probably be many years
(barring another Snowden like event) before the public knows anything about
exactly HOW the NSA has/will break it.

~~~
cnvogel
An extreme example for this kind of approach might be found in the history of
the Enigma cipher and the British/Allied successful attempts in decryping
German communications during the war. If it would have been obvious that
information about an impeding attack could only have been gathered from
intercepted and decrypted communications, the British would rather let boats
be sunken and people die than give away the fact that the code had been
broken.

Because if the fact would be known, the adversary will immediately cease to
use this method of encryption, rendering the advantage of breaking the cipher
void.

~~~
TOMDM
As a small aside, for anyone interested in this, The Imitation game was in my
opinion fantastic, though I assume anyone here would already have seen it, or
have plans to.

------
destructaball
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

------
monokrome
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.

~~~
alwillis
[https://news.ycombinator.com/item?id=8849392](https://news.ycombinator.com/item?id=8849392)

------
padraic7a
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.

~~~
MichaelGG
Are there any facts on the NSA being able to decrypt SSH? All I saw was some
Spiegel article where it showed the NSA had compromised some targets. But zero
details, so it _could_ have been as easy as a MITM and the user not verifying
the public key. Or it could be an unknown exploit in the actual code.

Everything I've heard so far points to the crypto being OK. That, so far, no
special NSA crypto-defeating capabilities have come out. (Hence the NSA doodle
with the smiley face on the links where Google removed TLS.)

Of course the NSA might have magic powers, but nothing in the last few years
suggests that possibility any more than we'd have thought before.

~~~
elsjaako
There was a powerpoint where they implied they could sometimes get around ssh
protections. Most people assume it's not actually the protocol that's broken,
but it seems like a good excuse to clean up ssh anyway.

------
exabrial
It's possible the NSA doesn't give a shit about your shit too.

~~~
Nanzikambe
From the slides leaked at 31c3 and by Der Spiegel that's not the case.

They want everything.

Even if you're not a target you're of interest -- either as a vector to a
target.(someone you know, regardless how many "hops") some thing you have
(information, or equipment/infrastructure as a proxy or platform for attack)

Think of this example: you've ssh access coincidentally to a VPS on the same
metal that coincidentally runs another VPS that belongs to a guy, who as a
favour runs a totally separate server that hosts a "bad dude"(tm). Everybody
in that chain and everybody connected to every one involved with the hardware
are direct targets, all of their work colleagues are for the same reason.

Now extend that up and down every technological stack and industry and you'll
see how capricious the notion is.

And if you're not a US citizen, you've no rights so who gives a shit? If you
happen to be a US citizen, you've still no rights because the people
targetting you will just be members of another Five Eyes organisation.

~~~
exabrial
Ok... First, if they're using my VPS to get to someone else's... um. Ok. So it
really doesn't affect me. Sorry about your neighbor. He should cover his ass
better and not keep top fkin secret info on a god damn VPS.

Oh, and even if this were like a possible scenario, why not just open random
accounts until they strike gold? Or infiltrate the datacenter with a mind
reading quad copter drone and plug a usb drive into your machine? I mean
honestly, there's a 1000x easier ways to do this. The NSA isn't after your
shit. Get over yourself and quit drinking the koolaid.

~~~
Nanzikambe
> Get over yourself and quit drinking the koolaid.

Given these are disclosures from their internal presentations, it's their
koolaid that we're discussing.

------
minikites
> 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.

Maybe this person forgot about Heartbleed? Or that Debian bug that was around
for years? Or Shellshock, dating back to 1989?

Stop pretending and assuming that just because software is open source that it
is automatically reviewed.

~~~
psycr
His claim is that it's necessary - not that it's sufficient.

