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

11–20 of 92 posts

Re: The OpenSSH Bug That Wasn't

#11

Post by TheDong »

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.

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 only ones you remember.

Any password a human creates and remembers is a problem. The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).

Re: The OpenSSH Bug That Wasn't

#12

Post by jms703 »

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.

That's fine. Who knows what happens when you enter your password on the machine or if you have agent forwarding enabled.

Re: The OpenSSH Bug That Wasn't

#13

Post by ChristianBundy »

TheDong wrote: post #11
jandrese wrote: post #7

Earlier quoted context omitted.

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

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?

Re: The OpenSSH Bug That Wasn't

#15

Post by FellowMarketer »

TheDong wrote: post #11
jandrese wrote: post #7

Earlier quoted context omitted.

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

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 have portable with me.

By contrast, if I just type in a single password to the system, it can only even potentially the system to which that password corresponds.

Your system drastically increases the failure modes of the whole system, from a single password to a known edge server, which can be locked down on the server side, to a potential compromise of every password.

> The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).

This is extremely bad advice: the best mitigation is to require two factors, not a single factor. Your strategy is inherently two single factor systems, not a two factor system. This is what gives its ability for cascades of compromise.

The correct way to do this would be to have the keys corresponding to each server represent an XOR of your password for that server with a base key stored on a physical device, combining the two pieces of information to generate the final key. This reduces the effects from the compromise of your thumb drive from "full compromise of all systems" to "reduced to password based authentication".

Please be more careful in your recommendations in the future.

Re: The OpenSSH Bug That Wasn't

#16

Post by hyperion2010 »

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.

Re: The OpenSSH Bug That Wasn't

#17

Post by ak217 »

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.

Re: The OpenSSH Bug That Wasn't

#18

Post by ajross »

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

Re: The OpenSSH Bug That Wasn't

#19

Post by tytso »

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.

Nope, because my ssh key is on my phone and my tablet, with an ssh client, and I pretty much always have my phone with me.

I do have a USB thumb drive with a bootable standalone system which I could use on a random mmachine --- but even if that solves the problem of exposing my password or ssh keys to a system which has malware on it, I pretty much assume that random machines, especially those at airport lounges or internet cafes, probably have keyboard bugs installed, so I wouldn't really trust my bootable thumb drive on those machines anyway.

I might use the thumb drive on a friend's machine which I really trusted, but most of the time I'd much rather use a trusted machine that I own, such as either my tablet or my laptop, or in the extreme cases, my phone.

Re: The OpenSSH Bug That Wasn't

#20

Post by UnoriginalGuy »

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.

Create a normal user, DON'T add them to the sudo group (or any other special group), and then generate keys for them. Store those keys in some online "cloud" storage (DropBox, Google Drive, OneDrive, et al).

Then if you need to get in, download the key, type in the password, login as that user, and the su up to root by entering the password only you know.

As an additional layer of security you could encrypt the key using AES-256 (e.g. 7Zip archive, Microsoft Office's Word .docx (NOT .doc) format (just drag drop the file into Word, "Encrypt with password") now AES-256 encrypted, others).

Now you have four layers of protection:

- su password.

- Key password.

- AES-256 encryption password.

- "Cloud" storage credentials.

Post reply on HN