Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The OpenSSH Bug That Wasn't

bsdly.blogspot.com

Post reply on HN
Print view View original

41–50 of 92 posts

Re: The OpenSSH Bug That Wasn't

#41

Post by tete »

ak217 wrote: post #17
hyperion2010 wrote: post #16

I have disabled PAM by default on all my boxes that run sshd for the last 9 years out of habit, I long ago forgot the reason why (probably because the gentoo sshd handbook entry said it was a good idea). Why UsePAM is set to yes in sshd_config by default on many distros is beyond me.

Key problem: aside from PAM, there is no way to use TOTP-based 2FA on your SSH server. And any modern security setup requires 2FA.

OpenBSD has bsd_auth and it works well with things like googleauth (HOTP, TOTP), s/key, etc.

I think the problem is that somehow everyone ended up with PAM and are now somewhat stuck with it. FreeBSD too.

Re: The OpenSSH Bug That Wasn't

#42

Post by lambda »

steckerbrett wrote: post #31
voidlogic wrote: post #21

Earlier quoted context omitted.

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

If your threat model has someone stealing your private key and breaking/obtaining the password to it, none of the other measures are going to mean anything as they have root on your box. With root they can bypass the access restrictions, knocking, whatever else. 2FA with an external device would probably make more sense than any of them and be significantly less irritating.

> they have root on your box

Or they have your discarded dead drive from your backup disk that you forgot to enable full disk encryption on. Or they rooted a machine that you were using "ssh -A" on to forward your agent, and have been able to temporarily hijack your SSH agent session. Or there's an information disclosure vulnerability in your web browser that allows them to read files from your hard drive, though without control of what files they can read, and by chance the attacker got lucky and one of the files was .ssh/id_rsa.

While the above description goes way further than I probably would, and yeah, 2FA would be more reasonable, there are good reasons to practice defense in depth, and try to design systems that have a chance of staying secure even if one of your assumptions fails like "private key is compromised".

Re: The OpenSSH Bug That Wasn't

#43

Post by scintill76 »

geerlingguy wrote: post #2

Key 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 convenient+secure access to a proper key, you're not going to have convenient+secure access to the key generator either. Maybe it could still be an excuse to learn a new language and how SSH keys work. I don't know if I could rationalize even tossing it up on Github with warnings though.

Re: The OpenSSH Bug That Wasn't

#44

Post by mcpherrinm »

cbsmith wrote: post #38
heywire wrote: post #10

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

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.

Re: The OpenSSH Bug That Wasn't

#45

Post by ak217 »

tete wrote: post #41
ak217 wrote: post #17

Earlier quoted context omitted.

Key problem: aside from PAM, there is no way to use TOTP-based 2FA on your SSH server. And any modern security setup requires 2FA.

OpenBSD has bsd_auth and it works well with things like googleauth (HOTP, TOTP), s/key, etc. I think the problem is that somehow everyone ended up with PAM and are now somewhat stuck with it. FreeBSD too.

Good to know, thanks! I hope this gets ported to Debian/Ubuntu... I wish it shipped with built-in 2FA capability.

Re: The OpenSSH Bug That Wasn't

#46

Post by wlesieutre »

larrys wrote: post #25
kryptiskt wrote: post #22

Earlier quoted context omitted.

Put a key on your phone or an USB stick. I make a key for every machine that I have, and that keys never leaves that machine. In addition I keep another key that I can use to get started again if my laptop gets stolen or breaks. If I lose the phone, there's a pretty good password on that key that should give me ample time to remove access rights for it.

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 from using a password protected key, chance of getting struck by lightning, etc. ;)

Re: The OpenSSH Bug That Wasn't

#47

Post by Aloha »

mzs wrote: post #32
feld wrote: post #6

Earlier quoted context omitted.

Unless they can provide a username that crashes fail2ban via blowing up the regex parsing... and then they get all the free tries they want. fail2ban/sshguard/etc are not infallible. Someone will find a way to break them.

I think fail2ban does not do IPv6 yet.

I also get 0 attempts via IPv6 interestingly enough. That said, I think fail2ban does support v6 now, but not all of the firewalls do (like ipfw on my ancient ppc mac)

Re: The OpenSSH Bug That Wasn't

#48

Post by mjard »

ajross wrote: post #18
hyperion2010 wrote: post #16

I have disabled PAM by default on all my boxes that run sshd for the last 9 years out of habit, I long ago forgot the reason why (probably because the gentoo sshd handbook entry said it was a good idea). Why UsePAM is set to yes in sshd_config by default on many distros is beyond me.

Because PAM is the default authentication framework on all those distros. Yes, it's a disaster of complexity and something pretty much no one understands. But it's what we have. Maybe a rearchitected replacement will land in systemd someday...

Or in pulseaudio as a master troll.

Re: The OpenSSH Bug That Wasn't

#49

Post by semi-extrinsic »

heywire wrote: post #10
geerlingguy wrote: post #2

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

Re: The OpenSSH Bug That Wasn't

#50

Post by acqq »

cbsmith wrote: post #34

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

Post reply on HN