Lol'd at the blog's title
The OpenSSH Bug That Wasn't
51–60 of 92 posts
Re: The OpenSSH Bug That Wasn't
#52Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most p…
To secure SSH, the more I care about a system the farther down this list I go. 1. Disable root 2. Use keys, disable passwords 3. Install fail2ban 4. Restrict incoming subnets 5. MathAuthTries = 1 6. Run on high random port 7. Use port knocking
1. Disable root
This doesn't add any security, it only makes your admin life miserable.
Re: The OpenSSH Bug That Wasn't
#53Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most p…
I've always wanted to disable password based auth, but I am worried that if I need to connect to my machine in a pinch from some random device (wife's phone, borrowed machine from friend, work, etc), that I won't be able to connect. How do people get around this? Keep in mind that I'm talking about home machines and hobby VM instances, I do not manage any production servers or anything.
Use a YubiKey Neo keychain dongle: https://www.yubico.com/products/yubikey-hardware/yubikey-neo...
Normally they're used for OTPs or Chrome's FIDO U2F auth scheme, but you can also put them in smartcard mode. If you do this, you can use it as an OpenPGP key, which is also compatible with SSH:
https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubike... https://www.yubico.com/2012/12/yubikey-neo-openpgp/
Just about the only place that won't work is on a phone. Technically it has an independent NFC interface which could probably be made to work with some extra development, but I haven't looked into it.
Re: The OpenSSH Bug That Wasn't
#54Earlier quoted context omitted.
My idea is a USB stick on car keys (my comment) is preferred simply because a phone is a more high value target than your car keys typically. You usually don't leave your car keys "laying around" they are in your pocket although that probably depends on a host of factors. Plus your phone can get snatched out of your hands on the street or taken if you leave it for a second. That's at least the way I view the risk pro…
You can put a passphrase on the key and not worry about someone else getting it by stealing your phone, just remove it from authorized keys when you're back at a computer. Unless you're concerned about needing emergency server access while your phone got stolen and hasn't been replaced yet. But at that point, we're probably also worried about the odds of getting run over by a bus and having amnesia that prevents you…
Unless you're concerned about needing emergency server access while your phone got stolen and hasn't been replaced yet.
Yes actually. Because it has a copy of my password manager file, which has all the passwords to the various social sites I could use to alert friends that I need a ride home. ;)
Re: The OpenSSH Bug That Wasn't
#55Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most p…
I've been toying with the idea of making a tool to derive SSH keys directly from memorable passphrases, with something like scrypt. Almost as convenient as a normal passphrase, almost as secure as a random key! ("Secure" because presumably no script kiddies are bruteforcing keys like they are bruteforcing passwords.) Besides the dubious security value, another reason I haven't bothered is that if you don't have conve…
Generating simple ones then encrypt & MAC them with password-derived key seems simpler. There's standard constructions for each step, too.
Re: The OpenSSH Bug That Wasn't
#56Earlier quoted context omitted.
I've always wanted to disable password based auth, but I am worried that if I need to connect to my machine in a pinch from some random device (wife's phone, borrowed machine from friend, work, etc), that I won't be able to connect. How do people get around this? Keep in mind that I'm talking about home machines and hobby VM instances, I do not manage any production servers or anything.
Use a stepstone. This is really only feasible if you can get a user account some place where they take network security seriously. (A stepstone is a well-protected server where you can log in with user/pass and use your keys to login to other machines from there.)
Doesn't that have all the problems of password auth, but with one extra step, with it's own failure modes, in between?
Re: The OpenSSH Bug That Wasn't
#57Earlier quoted context omitted.
Think of it this way. If you created a private key and uploaded it to a public website where everyone could get to it (say you posted it to HN ;-), how exactly is your system less secure than with password based auth? You still need a passphrase to decrypt the private key. If you bump up the number of trials, you can make decryption even slower. It's going to be harder for someone to crack that than a normal brute fo…
No: An attacker can massively distribute the key cracking effort, and do it offline. That is so many orders of magnitude faster than asking an sshd if the password is correct, even with the flaw discussed here where it isn't rate limited. Without that flaw, you have to start a new TCP connection every three guesses, which is glacially slow compared to cracking the passphrase to decrypt the key.
Umm... if they are massively distributing the key cracking effort, spawning TCP connections isn't going to be a limiting factor... There is no requirement that the TCP connections be opened sequentially.
They will have to do a session/key exchange hand shake each time, but that shouldn't be more painful than the extra work needed to crack a private key with tons of trials.
Re: The OpenSSH Bug That Wasn't
#58This really is a bug in how OpenSSH USE_PAM is implemented. Particularly if you presume that PAM is the devil, the last thing you want to do, from a security standpoint, is to let a client dictate how a server applies PAM. The policy _has_ to be entirely controlled by the server's config. Once you let the client decide, you're just asking for things to go wrong.
Yes, and this guy, quoted by the article author: "I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw in PAM." is then clearly wrong, it is an OpenSSH bug.
Well, it sort of isn't, because the OpenBSD team designed OpenSSH to not use PAM at all. PAM was patched in by some folks, and clearly they got it wrong, but I suspect the OpenSSH team doesn't see that as "part of OpenSSH".
Re: The OpenSSH Bug That Wasn't
#59Thankfully my use of PAM is for 2FA with SSH when I don't have my key. So they wouldn't have been successful in pulling off a bruteforce anyway. But it's annoying that their attempts weren't being limited as it can waste resources...
You wouldn't have a working config at hand for requiring TOTP (Google Authenticator) only for OpenSSH password logins on Debian, would you?
Re: The OpenSSH Bug That Wasn't
#60Earlier quoted context omitted.
Think of it this way. If you created a private key and uploaded it to a public website where everyone could get to it (say you posted it to HN ;-), how exactly is your system less secure than with password based auth? You still need a passphrase to decrypt the private key. If you bump up the number of trials, you can make decryption even slower. It's going to be harder for someone to crack that than a normal brute fo…
No: An attacker can massively distribute the key cracking effort, and do it offline. That is so many orders of magnitude faster than asking an sshd if the password is correct, even with the flaw discussed here where it isn't rate limited. Without that flaw, you have to start a new TCP connection every three guesses, which is glacially slow compared to cracking the passphrase to decrypt the key.
In general, because you tend to have so much more entropy in a private key phrase (you only need one for multiple logins), and because the private key itself is a nastier nut to crack, the computational effort needed to crack a private key file is just nastier than the password crack. That's the whole point of the design.