
Secure Secure Shell (2015) - ingve
https://stribika.github.io/2015/01/04/secure-secure-shell.html
======
red_admiral
There are some good points here, but it's a bit over the top.

For example: "NIST is considered harmful". Have you seen the latest NIST SP
800-63-3 on authentication? There was a public comment phase, the whole thing
is hosted on github and it has deprecated the whole "your password must
contain uppercase letters, lowercase letters, numbers, special characters (but
not single quotes as our database doesn't like that) and a haiku" nonsense -
the only remaining recommended password restrictions are minimum length and
check against a blacklist of common passwords.

Dual EC is considered harmful, and perhaps in a more general sense closed
standards and unexplained constants in crypto algorithms. Whether the label
NIST is on something or not makes very little difference (or are you going to
tell me next that AES is insecure because the US government approved it)?

And this is the kind of thing that makes my hair stand up: "The hash function
SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no
better attacks)." Yes, I know what you mean, but you've just given us a
lecture on why key length matters.

That said, there are some good recommendations here for setting SSH up
securely. Meanwhile I still have to deal with a server that shall remain
unnamed and that truncates passwords to the first 8 bytes ... _sigh_

~~~
heroprotagonist
I remember old versions of AIX which would do that. It was surprising given
the expense and almost exclusively corporate nature of it. They eventually
fixed it, but the way a lot of them were used, they could sit years waiting
for an update. I saw one (not ours, thankfully) with ~1200+ days uptime. I bet
there are still a few out there that haven't been upgraded sinced they fixed
it in 2007.

------
lvh
> ECDH curve choice: This eliminates 9-11 because NIST curves suck. They leak
> secrets through timing side channels and off-curve inputs. Also, NIST is
> considered harmful and cannot be trusted.

This is FUD. If you have an off-curve attack of any kind, or a timing attack
in OpenSSH's P-256 signing code, publish it or keep it to yourself.

I appreciate that the article linked to a source, but the source talks about
cache timing attacks in a different type of curve. Yes, X25519 is a better
curve. Yes Ed25519 is a better signature algorithm. Yes, it's harder to get
NIST curve implementations right. They also predate better curves by quite a
few years. Technology improves. NIST FUD is not a good reason to hardcode
ciphersuites in your ssh config. Go update your software and you'll be fine.

------
MrRadar
Mozilla's OpenSSH configuration guide is much more to-the-point:
[https://infosec.mozilla.org/guidelines/openssh](https://infosec.mozilla.org/guidelines/openssh)

~~~
tux1968
A minor point, but since Openssh 7.5, UsePrivilegeSeparation has been
deprecated. From the release notes: "... making privilege separation
mandatory. Privilege separation has been on by default for almost 15 years and
sandboxing has been on by default for almost the last five."

------
lvh
Good parts:

\- Upgrade your keys to the new format. Better: put them on a Yubikey, or use
short-lived keys via Teleport or BLESS.

\- Disable non-key/cert based auth (like passwords). You can do this on both
clients and servers if you like, but it doesn't really matter as long as you
do one of them.

Bad parts:

\- NIST is fine. SP 800-63B is a good example of how they're saving a
gazillion companies from shitty third party password requirements.

\- Don't hardcode ciphersuites. SSH is pretty OK at this. Just make sure you
have recent SSH cients/servers. Patch your boxes (or rotate images or
whatever). I dunno, don't run RHEL?

Try ssh -vvv sometime. You'll see what SSH tried to do. Odds are that if
you're up to date with your patches you're already getting chacha20poly1305
with ECDH.

Stuff like disabling roaming: sure, whatever, this is fine. I'm guessing this
advice is targeted at a different audience than startups (I also don't think
you should run SSH over Tor). But you can just go be on top of patching and
then you are also protected from bugs in things you can't just turn off.
Turning off a bunch of optional obscure features is a good technique if you
actually thing Mossad is after your SSH sessions. That's not the case for most
of you.

------
lvh
I estimated the cost of the pbkdf_bcrypt function that the new OpenSSH format
uses. It's about 20-30ms for a derivation with default (nrounds=16)
parameters. That's fine, but it's not absurd to suggest you want nrounds=100
or so, to bump it up to 150-200ms. That's a noticeable delay, but it also
makes recovering the password extremely costly, and you only pay the cost when
you actually unlock the key (so, if you use ssh-agent, not on every git push,
for example).

You can check my (admittedly, first pass, back of the napkin) work here:
[https://gist.github.com/lvh/9f551c92e3b3347424a0c8dc61c73c2b](https://gist.github.com/lvh/9f551c92e3b3347424a0c8dc61c73c2b)

------
ape4
Maybe its not so smart to hardcode protocols (with versions) in your local
config file. Could be correct now but in, say, 2 years when a new version is
out your hardcoded protocols aren't the best. Hardcoding "at least" version
N.NNN might be good - but I don't think you can do that in ssh_config

------
giovannibajo1
I (ab)use SSH persistent connections which means my git pushes are super fast
even if I live in Europe. Is there some security issue with them? I would say
no, but I’m not an expert

~~~
lvh
Assuming you set a reasonable ControlPath (the default is reasonable on all
platforms) this is fine, sure. Even if you don't, it's fine-ish. Not how
you're going to get popped.

------
rain1
How does the default config of todays openssh hold up? Are these guidelines
still important?

~~~
computerfriend
Some things have improved. But yes, they're still important.

~~~
lvh
Can you elaborate? A lot of the reasons in the article are weak at best; such
as the timing attack/off-curve attack FUD for NIST curves.

There are a handful of good things in here (I commented elsewhere with a
list), but nobody should be setting ciphersuites in their ssh config.

~~~
computerfriend
I'm not so sure. Yes, ideally that wouldn't be the case. But there are still
weak ciphersuits available by default. (SP 800-63B isn't really relevant to
whether NIST curves are safe or not.)

Another benefit is the SSH logs now fill up with cipher negotiation errors
instead of failed authentication attempts, which stops automated "attacks"
quicker and makes for cleaner logs if trying to parse for meaningful
authentication attempts.

------
bonyt
Past discussion (2015):
[https://news.ycombinator.com/item?id=8843994](https://news.ycombinator.com/item?id=8843994)

------
natch
"This is probably not the site you are looking for" as a site title? Is that a
joke? An ill-considered one, if it is.

If you are thinking of replying with your interpretation, please include
information on how you know what you think you know.

Edit: It was a serious question. If it was a joke, yeah I get it, but it could
also be a mid-edit draft of a site or a hack. Or maybe nobody else is seeing
what I'm seeing. It may seem dense, but I'm just trying not to make
assumptions. Anyone know the answer?

~~~
hluska
You're not wrong to be cautious and it's good to ask questions if you're
concerned. But, in this case, it's almost certainly a joke (though I'll agree
it is an odd one).

I think this because:

1.) I've tried this site with two browsers on different machines on different
networks. Neither browser puts that particular security warning in markup on a
compromised site.

2.) The site footer references the title. It isn't exactly an explanation, or
rather, it isn't one that I understand. It may be an in-joke between friends.

Even in the unlikely event that this is an attack, it's unlikely to be
dangerous to visitors.

I think this because it would be quite rare to find someone with the skill and
dedication to own the site and attack visitors, yet who would still advertise
his/her attack in progress.

~~~
natch
Yeah that's my take too... just seems a bit juvenile though for someone in the
security community. Thanks for the reply.

~~~
hluska
Thanks for drawing attention to this!

It can be hard to learn how to move your communication beyond your group of
friends and into the masses. This is made more acute by the fact that you can
never quite tell when you're about to blow up until you already have. That
might actually be a good topic for a blog article.

