Hacker News new | comments | ask | show | jobs | submit login
Secure Secure Shell (2015) (stribika.github.io)
224 points by ingve 6 months ago | hide | past | web | favorite | 23 comments

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

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.

This is just a fact of life for bloggers passionate about this topic — you get this kind of baggage.

The Dual EC gambit struck me as very clumsy and ham fisted. The "number theory in your PRNG" argument is exactly wrong in an obvious way too, especially when you consider quantum computing. Did they really think nobody would notice an obviously keyable PRNG?

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

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.

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

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

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

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

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

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.

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

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

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.

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.

"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?

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.

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

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.

There seems to be an explanation in the footer? Before reading that, I had thought it was a clumsy reference to Kenobi's famous statement about droids. Upon reflection, it may be a warning about the fallibility of DNS?

Well not really an explanation just more of the same. But thanks for the sincere reply.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact