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

71–80 of 92 posts

Re: The OpenSSH Bug That Wasn't

#71

Post by [deleted] »

jandrese wrote: post #7
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…

Then you're screwed when you need to log on to your server from some random machine that doesn't have your key installed.

[deleted]

Re: The OpenSSH Bug That Wasn't

#72

Post by TheDong »

FellowMarketer wrote: post #15
TheDong wrote: post #11

Earlier quoted context omitted.

Good. If you can login from "some random machine" that means your password is terribly weak as well. Use a password manager, generate passwords with over 100 bits of entropy, and then you can't log into anything without it present. Now start carrying around your password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the o…

Your security recommendation is bad. > password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember You have to give the system both passwords to use the thumb drive, except that these passwords, rather than being compartmentalized as currently is the practice, can steal literally every key I need to…

I appreciate the detail in your criticism and largely agree with it excepting that I value usability.

I'll at least hold that my recommendation is significantly better than the "state of the art" for a person who talks about ssh password auth -- typical state of the art there is using the same short memorable password for every server.

You're, of course, right that it's even better to have a second factor for each entry.

However, I'm trying to give pragmatic advise.

I would argue that having to remember a unique password for every entry in your database puts too much burden on the user which will ultimately lead to them subverting it... e.g. by using the same password for every server or using very simple ones.

Re: The OpenSSH Bug That Wasn't

#73

Post by [deleted] »

tjohns wrote: post #53
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.

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…

[deleted]

Re: The OpenSSH Bug That Wasn't

#74

Post by jamiesonbecker »

wlesieutre wrote: post #46
larrys wrote: post #25

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

definitely always use a passphrase on the key. bonus, if you userify, than you only need to remember your userify console password to get into anywhere, since you can regen a key and replace on all your servers in seconds.

Re: The OpenSSH Bug That Wasn't

#75

Post by TheDong »

ChristianBundy wrote: post #13
TheDong wrote: post #11

Earlier quoted context omitted.

Good. If you can login from "some random machine" that means your password is terribly weak as well. Use a password manager, generate passwords with over 100 bits of entropy, and then you can't log into anything without it present. Now start carrying around your password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the o…

>generate passwords with over 100 bits of entropy Is this arbitrary, or is there a specific reason you recommend at least 100 bits of entropy?

It's an arbitrary number that's large enough to be safe for quite a long time.

Re: The OpenSSH Bug That Wasn't

#76

Post by cbsmith »

hackmiester wrote: post #68
cbsmith wrote: post #61

Earlier quoted context omitted.

I keep trying to explain to people that if anything this adds complexity to the security problem...

Can you explain this to me? We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.

From an accountability standpoint, if each person logs in to the root account directly with a distinct private/public key, you can still have full individual accountability.

I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.

Re: The OpenSSH Bug That Wasn't

#77

Post by hackmiester »

cbsmith wrote: post #76
hackmiester wrote: post #68

Earlier quoted context omitted.

Can you explain this to me? We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.

From an accountability standpoint, if each person logs in to the root account directly with a distinct private/public key, you can still have full individual accountability. I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.

I don't find 'sudo' to be complex at all. If in your situation I would have had the ability to log in as root, in my situation I will be in the 'wheel' group. It seems very straightforward to me.

Re: The OpenSSH Bug That Wasn't

#78

Post by moe »

hackmiester wrote: post #68
cbsmith wrote: post #61

Earlier quoted context omitted.

I keep trying to explain to people that if anything this adds complexity to the security problem...

Can you explain this to me? We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.

For accountability the openssh server already logs the key fingerprint.

The main security implications of sudo are a false sense of security and the risks related to having a password on your account and typing it in all the time (how often have you spilled it into a bash history?).

Sudo can't provide a dependable audit trail because it is trivially circumvented ('sudo bash'). It doesn't protect you from local-to-root exploits either.

It doesn't even protect you from yourself but rather makes your critical commands more complicated and error prone (shell globbing/escaping, pipes and redirects, etc.).

Re: The OpenSSH Bug That Wasn't

#79

Post by stsp »

cbsmith wrote: post #58
acqq wrote: post #50

Earlier quoted context omitted.

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

PAM support is part of OpenSSH portable releases. http://www.openssh.com/faq.html#3.15

Re: The OpenSSH Bug That Wasn't

#80

Post by e12e »

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.

With newer ssh, you could always switch to two-factor authentication, requiring password and a One Time Password via Google Authenticator or another OTP implementation.

That way a brute force attack would essentially need to gain access to the shared OTP secret in order to be successful (assuming ~few/normal user population. With a 6-digit otp, I suppose the value of otp drops if an attacker can try to log in as ~1 billion users in parallel -- but it's not really a scenario most of us have to worry about).

Another option is to use ssh certificates. As long as you are able to make yourself new user certificates, you can log in. One bonus with certificates is that they can be set to expire, unlike keys.

Post reply on HN