The OpenSSH Bug That Wasn't
bsdly.blogspot.com
bsdly.blogspot.com
> 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 platforms, the default settings for remote login already make brute-force login attempts annoying at best, and with fail2ban or something similar, it's a non-issue.
fail2ban/sshguard/etc are not infallible. Someone will find a way to break them.
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).
Is this arbitrary, or is there a specific reason you recommend at least 100 bits of entropy?
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.
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.
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%...
> 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.
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.
To use something that's more in the middle: you'd want to use a password manager per client (for sure) and probably divide low-security and high-security credentials.
It's just that the remote SSH servers at my job are fundamentally an expediency meant for emergency situations, and often can only be used once without being reset, eg, locking the account after a single session and requiring someone from inside the network to unlock it (after setting a new, one-time password).
In this sense, their security is primarily that I must compartmentalize each emergency server, and only use it during the appropriate emergency. However, during emergencies, the nature of the emergencies overrides the risk of compromise when accessing those commands, which typically are just specific scripts run from a locked down account.
Thus the security of the system depends on my ability to keep emergency credentials compartmentalized when using a different set, so that way only a single set of emergency commands are available to an attacker at a time -- and only when they're commands related to an already failed system.
Thus the security of the system is best preserved by strategies which highly compartmentalize the credentials, since they're meant to be used on potentially unsafe systems only during emergencies.
I guess I just remember 3-4 passwords like it's my job to -- because it is.
-% mkpass -h
Usage: mkpass [options]
-a, --attacker [RATE] Assume an attacker capable of RATE guesses/second (default: 1000000000)
-t, --time [DAYS] Resist an attack for up to this many days (default: 3652)
-b, --bits [BITS] Generate a password with this many bits of entropy (default automatic)
-l, --length [LENGTH] Make LENGTH word/char passwords (default automatic)
-n, --number [NUM] Make NUM passwords (default 1)
-w, --wordlist [FILE | name] Use file as wordlist (default comm3000 3esl)
-v, --verbose
-% mkpass -v
Complexity 22088^5, 72 bits of entropy. 1811 centuries at 1000000000 guesses/sec
messy photo groceries stoke horse
-% mkpass -vb 100
Complexity 22088^7, 101 bits of entropy. 88357157 million years at 1000000000 guesses/sec
ungainly shopping mall dissociation turf across stridden microphone
-% mkpass -vl3
Complexity 22088^3, 43 bits of entropy. 2 hours at 1000000000 guesses/sec
Weak passphrases: estimate 43 bits of entropy. 50+ recommended (length=5)
terrace lower-class paneling
-% mkpass -vw pin
Complexity 10^18, 59 bits of entropy. 34 years at 1000000000 guesses/sec
366565907478491511
-% mkpass -vw alnum
Complexity 62^10, 59 bits of entropy. 28 years at 1000000000 guesses/sec
cTDng2KioEI 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.
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.
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.
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. ;)
Yes actually. Because it has a copy of my password manager file, which has all the passwords to the various social sites I could use to alert friends that I need a ride home. ;)
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".
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.
They will have to do a session/key exchange hand shake each time, but that shouldn't be more painful than the extra work needed to crack a private key with tons of trials.
(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.)
Also note that it's not really an extra step, you put in a ProxyCommand in your .ssh/config file.
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 the only place that won't work is on a phone. Technically it has an independent NFC interface which could probably be made to work with some extra development, but I haven't looked into it.
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.
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 knocking2 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.
You should be auditing everything already, and adding in sudo now adds another attack vector. You also now have two different accounts that can be manipulated to compromise a system.
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".
Someone brute forcing said passphrase? Yeah no.
This doesn't add any security, it only makes your admin life miserable.
We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.
I'd think the complexity side of the sudo strategy is self-evident, so perhaps I'm not understanding the part that needs explaining.
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.).
What is the false sense of security created by sudo? You don't have to have a password on your account to use it. You can use NOPASSWD or you can use pam_ssh_agent_auth to verify ssh keys if you are very paranoid. (Users still should not log into the servers with passwords.)
sudo doesn't provide a dependable audit trail, but neither does anything else. If you are root, why not just fix the logs? To fix this, you must use snoopy to log commands to syslog, then syslog to a different computer. This makes both 'sudo' and root's ssh keys as accountable as one could ask for, I think. (As I could ask for, anyway.)
It protects you from yourself in the sense that you are meant to think about what you type if it begins with "sudo." If you are running as your own user, it's much harder for a stray 'rm' to bring down the system. You might clobber your own files, but then you just restore from your backup.
You seem to think sudo adds security even when you don't use a sudo password. That's precisely the false sense it creates.
snoopy
On vanilla Linux there is no dependable audit trail after someone becomes root, period.
that you are meant to think about what you type if it begins with "sudo."
Because you don't think when you type into a root shell?
The mythical "stray rm" is a strawman. I've never heard of one happening in the real world. If you're that careless then sudo won't save you either.
What I do see often is people spending minutes on trial & error because sudo turns even trivial commands into a minefield when a pipe/redirect, the shell environment, globbing or a loop gets involved.
Wait, you just said "neither does anything else", and then gave an example of how to create an audit trail. ;-)
In truth, you should use auditd or similar systems to really have a proper audit trail.
You're absolutely right that sudo doesn't make an audit trail more worse. It just doesn't make it any better either. It does, however, create a bunch more ways that someone can hack your system.
> It protects you from yourself in the sense that you are meant to think about what you type if it begins with "sudo."
How about you write a shell script on your own system, call it "sudo", and have it do "ssh root@admin.system $*"? You see what I mean? Maybe you are used to using sudo, but there is no reason the "oh noes, now I need to be careful mode" has to be a privilege escalation command on the host your are administrating. In fact, it shouldn't be. It really should be before you have logged in.
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.
It's effectively the same thing as generating the key from the pass phrase, except you are mixing in a nice giant product of two primes in to the mix.
For the deterministic key, you could "backdoor" ssh-keygen's RNG through something like LD_PRELOAD... at that point it's probably just piping a couple of pre-made shell utils together, which could be more portable and simple than rolling-your-own all the key export stuff.
Actually, this strikes me as potentially useful and secure in some niche cases where you don't trust your RNG and/or storage. Use diceware and write your long key down, derive anew for each use. Maybe it's silly, but I would consider something like that (at least the initial deriving part) if I were very paranoid or making a long-lived, deeply-deployed key.
Here's a deterministic Ed25519 SSH key generator that takes a 32-byte seed: https://github.com/mithrandi/ssh-key-generator
Let's say you have this deterministic SSH key generator. However, instead of your approach to using it, you took the resulting key and XOR'd it with a passphraseless private key, and then posted the XOR'd file up to the internet for all to see.
Now imagine what it would take for someone to crack it. They'd basically have to figure out what your deterministic key was. The publicly available file really wouldn't be of any help in that unless they already knew the underlying passphraseless key they were trying to hack.
Now explain to me how the "deterministic key + XOR" is in any way making it more difficult to crack it than just using "ssh -o -a [some reasonably high number]".
It's not. If anything, it is less. The deterministic key generator is essentially how most streaming ciphers designs work (well, aside from those derived from block ciphers), and generally offers weaker protections than block encryption.
So, rather than go through all that pain, just block encrypt your private key well and upload it to the cloud. ;-)
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.
"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.
I think the problem is that somehow everyone ended up with PAM and are now somewhat stuck with it. FreeBSD too.
Maybe a rearchitected replacement will land in systemd someday...
http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-curr...
This is a serious vuln for FreeBSD. Period.
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...
https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-cv...