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
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.
- 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.
- 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.
You can check my (admittedly, first pass, back of the napkin) work here: https://gist.github.com/lvh/9f551c92e3b3347424a0c8dc61c73c2b
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.
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.
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?
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.
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.