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

21–30 of 92 posts

Re: The OpenSSH Bug That Wasn't

#21

Post by voidlogic »

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…

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

Re: The OpenSSH Bug That Wasn't

#22

Post by kryptiskt »

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.

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.

Re: The OpenSSH Bug That Wasn't

#24

Post by larrys »

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.

ssh keys on USB attached to your physical house and car keys with encryption (say an encrypted volume).

Don't note what machine or where the key has access to either. I know purists will take issue with this but it's a solution to a problem as you have detailed.

Obviously only works from "borrowed machine from friend work etc" unless you can get the key from a machine to "wife's phone".

Re: The OpenSSH Bug That Wasn't

#25

Post by larrys »

kryptiskt wrote: post #22
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.

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

Re: The OpenSSH Bug That Wasn't

#26

Post by larrys »

UnoriginalGuy wrote: post #20
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.

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

So in short store the keys in some place that you have easy access to by a password. Kind of a version of two factor "something you know and something you have" whereby the "something you have" is the cloud storage device with the key.

Re: The OpenSSH Bug That Wasn't

#27

Post by UnoriginalGuy »

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?

Not them, but this is arbitrary, and frankly a confusing way of even defining a password's strength. A password's strength is measured by both how it was created and also its absolute length.

In this case they're simply calling anything longer than 12.5 ASCII characters or 6.25 Unicode characters secure. While those are good solid lengths for passwords (in both cases due to the larger character set of Unicode), without knowing exactly how they were calculated it is completely arbitrary.

For example for a sentence-based password, 100 bits is insecure. But for a password generated using the secure random number generator, it is absolute unbreakable e.g.

"goodnight moon": Insecure but 120 bits (16 chars) of 'entropy'

"5%ML#_rjMe": Secure but "only" 80 bits (10 chars) of 'entropy'

Now you could argue, that the word 'entropy' would discount any sentence based passwords by definition, but that's not how I've seen people [mis]use it. They call any content of a password that password's 'entropy.'

I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters). The whole bits thing started when people are contrasting character based passwords with other types of passwords like certificate based (as a way of showing how much more secure certificate based authentication is). It makes absolutely no sense to use bits in a discussion about purely character based passwords, and people only do it because they witness others do it but have no concept of WHY.

Re: The OpenSSH Bug That Wasn't

#28

Post by baby »

They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln?

This is a serious vuln for FreeBSD. Period.

Re: The OpenSSH Bug That Wasn't

#29

Post by tedunangst »

UnoriginalGuy wrote: post #27
ChristianBundy wrote: post #13

Earlier quoted context omitted.

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

Not them, but this is arbitrary, and frankly a confusing way of even defining a password's strength. A password's strength is measured by both how it was created and also its absolute length. In this case they're simply calling anything longer than 12.5 ASCII characters or 6.25 Unicode characters secure. While those are good solid lengths for passwords (in both cases due to the larger character set of Unicode), witho…

The implication of "generate a password with X entropy" should be that you do, in fact, generate from X entropy. They didn't say "measure your favorite password's entropy".

Re: The OpenSSH Bug That Wasn't

#30

Post by glass- »

baby wrote: post #28

They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln? This is a serious vuln for FreeBSD. Period.

> They talk about FreeBSD in the original article and the guy tests that on other OS and say it's not a serious vuln?

Mr Hansteen is saying it is not a serious OpenSSH vuln, like the tech media is claiming it is.

> This is a serious vuln for FreeBSD. Period.

That's why the original disclosure and subsequent news articles clearly stated it was a FreeBSD and/or PAM vulnerability, and didn't run with headlines such as "OpenSSH keyboard-interactive authentication brute force vulnerability"[0] or "Bug in widely used OpenSSH opens servers to password cracking"[1].

[0] https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-i...

[1] http://arstechnica.com/security/2015/07/bug-in-widely-used-o...

Post reply on HN