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

31–40 of 92 posts

Re: The OpenSSH Bug That Wasn't

#31

Post by steckerbrett »

voidlogic wrote: post #21
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

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.

Re: The OpenSSH Bug That Wasn't

#32

Post by mzs »

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

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.

Re: The OpenSSH Bug That Wasn't

#33

Post by FellowMarketer »

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…

> I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters).

You took an uncharitable interpretation of something another person said using standard jargon you apparently don't understand, and then went off on a rant doing exactly the thing you deride.

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

You've misunderstood the discussion around this: it's about the bits of entropy used in the generation of passwords, all of which are digital in nature (or as you put it, in "characters"), and not how many bits it takes to store the character in the password.

Talking about "bits of entropy" related to a password means a password generated by a process using that many bits of entropy, regardless of how long its output is. It's the way to talk about passwords independent of encoding, since it talks only about their information theoretical content (stemming from the manner they were generated).

Thus, talking about "a password with X bits of entropy" is standard industry jargon for "a password generated by a technique which consumes X bits of entropy", without disambiguation between binary keys, randomly chosen characters, or randomly chosen words. (They all have the same cryptographic strength, for a given number of bits of entropy.)

tl;dr: You were overly literal and seem to have misunderstood standard industry jargon, and then gone off on a nonsense rant.

Re: The OpenSSH Bug That Wasn't

#34

Post by cbsmith »

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.

Re: The OpenSSH Bug That Wasn't

#35

Post by emidln »

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.

That assumes that stealing your private key is the same thing as sending arbitrary packets from your machine, otherwise things like restricting subnets/ip addresses and port knocking could still be useful layers. How different exfil of a private key from being able to send arbitrary packets on the user's machine is...probably not that different under most circumstances I'd guess.

Re: The OpenSSH Bug That Wasn't

#36

Post by JoshTriplett »

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…

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

No, that's not accurate. Bits of entropy are based on how many options you have for the type of password you used. The password "goodnight moon" has far less than 120 bits of entropy. A word-based password search algorithm would find it quite easily. Those are easily both in the top few thousand words in the English language, so that password probably has less than 24 bits (2*lg(4096)) of entropy.

> 12.5 ASCII characters

That assumes 8-bit ASCII. In practice, a password doesn't include characters 127-255 or 0-31, only 32-126, and probably not many symbols. One character selected randomly from characters 32-126 has ~6.6 bits of entropy. One character selected randomly from just letters and numbers, no symbols, has ~6 bits of entropy. One character selected randomly from just lowercase letters has ~4.7 bits of entropy. And if you don't choose randomly, and instead use a memorable password, then you reduce that entropy.

https://en.wikipedia.org/wiki/Entropy_%28information_theory%...

Re: The OpenSSH Bug That Wasn't

#37

Post by voidlogic »

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.

I'd recommend encrypting your private keys if needed with a pass-phrase. I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server.

2 factor with a token is ideal, I suppose I should have added that to the list, but that is outside of feasibility for most users.

Still, for someone who doesn't have RSA tokens etc available, assuming your remote machine doesn't get owned and someone doesn't extract your pass-phrase with a wrench, that list makes for a very secure system.

Re: The OpenSSH Bug That Wasn't

#38

Post by cbsmith »

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.

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 force against a password.

Now, if you put that key behind a decently secure storage service that you use TFA to access, that's actually way more secure than just using a password.

Given that, the question ought to be whether you upload the private key to the cloud, or try to manage the private key yourself. Password based authentication shouldn't be one of the options you are considering.

Re: The OpenSSH Bug That Wasn't

#39

Post by cbsmith »

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…

While I'm a big believer in defense in depth, I think this adds a lot more complexity on the usability side without really improving the overall security. You'd be better off just protecting the private key with more trials and storing it with whichever cloud storage solution you have the most confidence in.
Post reply on HN