> 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.
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.
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:
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.
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.
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.
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 from using a password protected key, chance of getting struck by lightning, etc. ;)
Unless you're concerned about needing emergency server access while your phone got stolen and hasn't been replaced yet.
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. ;)
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.
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).
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.
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.
I don't think so. A single server sitting behind an advanced firewall/IDS/IPS system and managed by competent IT staff is a much harder target than a multitude of servers I manage myself.
Also note that it's not really an extra step, you put in a ProxyCommand in your .ssh/config file.
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".
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.
No: An attacker can massively distribute the key cracking effort, and do it offline. That is so many orders of magnitude faster than asking an sshd if the password is correct, even with the flaw discussed here where it isn't rate limited. Without that flaw, you have to start a new TCP connection every three guesses, which is glacially slow compared to cracking the passphrase to decrypt the key.
In general, because you tend to have so much more entropy in a private key phrase (you only need one for multiple logins), and because the private key itself is a nastier nut to crack, the computational effort needed to crack a private key file is just nastier than the password crack. That's the whole point of the design.
Umm... if they are massively distributing the key cracking effort, spawning TCP connections isn't going to be a limiting factor... There is no requirement that the TCP connections be opened sequentially.
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.
I also get 0 attempts via IPv6 interestingly enough. That said, I think fail2ban does support v6 now, but not all of the firewalls do (like ipfw on my ancient ppc mac)
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
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.
I think you misunderstand my point. You have increased the complexity of securing the system. You now have each user's login shells, all of the joys of what those login shells touch, the sudo program and its configuration, all added to the attack surface.
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.).
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.
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 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.
> 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.
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.
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.
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".
If your threat model is someone stealing and cracking your private key, you really ought to be more worried that they are going to use their time machine to go back in time and kill your mother.
Both actions happen at the same time, someone phishes you, captures your input and they have the password for it as well. Now that they've got a shell on your box IP address restrictions are bypassed as well, as is port knocking. This is completely plausible, time machines are not. I read a (private) incident report very recently where half a company had their devices spear phished in order to gain access to a single internal server.
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.
> I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server.
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.
I've been toying with the idea of making a tool to derive SSH keys directly from memorable passphrases, with something like scrypt. Almost as convenient as a normal passphrase, almost as secure as a random key! ("Secure" because presumably no script kiddies are bruteforcing keys like they are bruteforcing passwords.)
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.
Yeah, I'm not seeing the point of doing that. You might as well create the key, encrypt it with the passphrase as per usual, and then post it online for all to see.
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.
Well, I don't know a lot of the math and crypto, but I would probably seed an RNG from the stretched key and then pull large primes out just as ssh-keygen would. You're right, though -- given my "requirements", it's not much more to assume a convenient place to store a normal, encrypted key. It can be public since I already based my security on the password strength and some obscurity. I wouldn't use either of these ideas for any serious production server.
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.
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. ;-)
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).
> 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 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.
My point was that you had missed a key component: compartmentalization.
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.
For my human-facing passphrases, I taught my password generator to scale automatically based on the size of the password space, the capabilities of an expected attacker (default: Snowdon's "assume 1 trillion/sec"), and the length of time for an attack (default: a decade). Keeps it clear how strong or weak what I'm using should be:
-% 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
cTDng2KioE
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.
> 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.
> 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.
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".
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.
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.
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".
Thankfully my use of PAM is for 2FA with SSH when I don't have my key. So they wouldn't have been successful in pulling off a bruteforce anyway. But it's annoying that their attempts weren't being limited as it can waste resources...
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...
I am curious as to what happens when this is done with an existent user? I feel like there would be different behaviors for timeouts when a non-existent username is used and when a wrong password is used for an existent username.
I should have elaborated better. I think that the feedback should in theory always be the same. However, the check for existent user and the check for correct password are different procedures in the program. The program masks this fact by always having one feedback prompt for actions that don't result in login. Perhaps the original bug report only allowed multiple retries for existent users but not for non-existent users, thus shattering the illusion that the feedback is always the same.
> 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].
> 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.