This question already has an answer here:

I had a long discussion with my co-workers whether key-based SSH authentication (particularly for OpenSSH) is more secure than authentication using passwords. My co-workers always connect to servers with passwords, while I prefer to log into a system without having to enter a password every time.

They fear that it is not secure to connect without a password. What should I tell them? For me, passwords are bad because they could be brute-forced or captured with a keylogger.

I use the ssh-copy-id tool to copy my public key to the server. I then simply connect with ssh servername. In fact, I only have to enter the password for my private key once every time my system boots. If my workstation runs for 3 days, I never have to enter the password again, which they say is insecure. Is that true? I know that keys are better, but I don't know how to explain that to them.

marked as duplicate by Gilles, Xander, Jedi, tim, Tobi Nary Sep 11 '17 at 6:39

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

migrated from serverfault.com Dec 19 '11 at 22:19

This question came from our site for system and network administrators.

  • 2
    Possibly of interest: gnome-keyring ssh agent timeout -- make the keyring "forget" your password when the screensaver kicks on. You can also do ssh-add -t3600 to make ssh-agent drop your key after an hour. – bstpierre Dec 20 '11 at 3:03
  • 10
    Sorry, gotta play devil's advocate: If you can't explain it, you don't know it. Are you sure you're not just regurgitating what you've heard? Maybe you should allow yourself to be enlightened to the wonders of keyless logins. There are pros and cons to both approaches. – Phil Dec 20 '11 at 4:15
  • 9
    You're missing one point - even though you use keys, your account also has a password. And password login is enabled for your co-workers. The password can be brute forced, regardless of if you're using it or not. – chris Dec 20 '11 at 8:57
  • 1
    This question should be of interest (almost a duplicate): security.stackexchange.com/q/3887/2435 – Bruno Dec 22 '11 at 13:09
  • If someone were to try dumping the keys from the agent, they wouldn't need to wait for the user to be away from the keyboard to do it. – mkin Jan 18 '16 at 21:39

Key based login is considered much more secure than password based logins when looking from the perspective of a brute-force attempt to gain access from a third party system: The chances to crack a key are effectively zero, while bad passwords are all too common.

From the perspective of a compromised client system (your workstation), there won't be a difference because if the attackers can get your private key and/or hijack a session, they could likely also install some kind of key logger, rendering the perceived advantage of passwords useless.

  • 2
    Although if the system is configured to allow both passwords and keys (as the OPs apparently is), wouldn't the attacker be able to brute-force his password too? – Zlatko Dec 20 '11 at 10:58
  • 18
    Yes. That is why I would disable password-based logins entirely. – Sven Dec 20 '11 at 11:09

It's as secure as your computer. The key is sitting, unencrypted, in RAM; an attacker with physical access to your machine, or remote root access, could obtain it.

Think of it in the same terms as if your coworkers used a password safe program and left it up on the screen with the database available without password entry; if you lock your workstation when you walk away and keep it secure from hostile remote activity, then it's reasonably secure, but a frozen RAM attack could still theoretically obtain the key.

But someone in those positions could easily install a keylogger, too, as you pointed out. As long as you're careful about your workstation's security, I wouldn't call it any less secure than passwords; but the real benefits to key-based logins are really for protection against, for instance, brute force password attacks against the server (as keys are nearly impossible to brute force).

Actually your co-workers are correct. Think about this.. Your work stations gets cracked, it's been up for a couple of days and now the hackers pwn your entire network because you dont use a ssh passphrase.

That being said, shared passwords are never good and a major weakness of the system. I'm going to assume that you are talking about root access.

The point I'm making is they both have drawbacks and where the security needs to be places.

For all the servers that I admin I use a passphrase SSH key. That gives me the best of both worlds. A password only I know, and not using a shared password for other users.

(and yes I have seen where a passphraseless ssh key has been used to compromise and entire network.

  • Why was I down voted? – Squidly Dec 19 '11 at 21:43
  • I didn't down vote you Squidly. Someone else must have. – Daniel Dec 19 '11 at 21:52
  • 1
    Upvoted to compensate - all of the answers on here make essentially the same points, so I'm not sure why you got the minus. By the way: welcome! Thanks for contributing your expertise, and don't stress about the random downvote once in a while - the upvotes far outweigh them. – Shane Madden Dec 19 '11 at 22:01
  • 1
    It Depends on what system you are using. I personally don't have anything like gnome-keyring installed. Also I agree I HATE password lists. I cant remember 1/8th of the passwords I have out there. @ Shane Thank you :) – Squidly Dec 19 '11 at 22:04
  • 1
    What happens when your workstation gets cracked and they keylog your password? How does using a password provide more security over using a key? – rox0r Jun 4 '12 at 18:42

You are only as secure as your weakest link. If your remote servers allow both password and key-based authentication, you are less secure compared to only allowing one.

Your extra vulnerabilities for a key-based system over Password Authentication (PA) are:

  1. An attacker gains a copy of your passphrase-protected private key by say having physical access to an unencrypted disk on any system (e.g., boot into single user mode), then runs a GPU-based offline brute force attack on your key and then gets access to all your systems if your passphrase is suitably weak (e.g., 4 diceware words).

  2. You use something like ssh-agent that keeps your passphrase or private key in memory for later usage and an attacker is able to get it off your system somehow (e.g., another root user was logged in while you had the password in memory).

  3. Your key was much less secure than you thought it was. E.g., the OpenSSH key weakness; where the only randomness came from the process id so only 65536 keys were generated. While these sorts of problems hopefully get noticed and patched quickly, as an end-user its impossible to tell that there isn't some major flaw in the random number generator used to make your keys.

Your extra-security from using key-based authentication:

  1. Brute force attacks are infeasible over the life of the universe, without stealing your private key (and if it was passphrase protected; then breaking the passphrase).
  2. MITM attacks won't work (a malicious remote host can't figure out your private key/passphrase); though ssh already alerts to MITM attacks to alert admins by using host keys and known_hosts files.

In practice both are equally as secure. Anyone who can steal ssh private-keys from RAM, can install a keylogger get your passwords/passphrases/private keys.

Personally, I like your solution as a passphrase is more convenient (stored in RAM; on one-user machine that locks after 5 minutes); though I still only put my passphrase-protected private key on local machines where I am the only user.

  • 1
    "In practice both are equally as secure" - MAJOR objection: the probabilities of workstation cracks and server brute-force attempts are several orders of magnitude apart. I don't see ninjas trying to crack into my workstation (of course not, they're ninjas ;o) ) ; OTOH, I see a lot of denyhosts reports from my servers. – Piskvor Dec 20 '11 at 19:29
  • 2
    @Piskvor - I agree a reasonable password on the weaker side (say four word diceware or 8 random lowercase letters) ~2^36 is much smaller space than typical private key space ~2^1000. However, if fail2ban limits bad attempts to ~100/hr per IP address, your password would survive for ~4 billion years from one IP address (or would require ~40 million IP addresses to attack for a 100 years without you noticing). Therefore, they are in practice roughly equally safe as your risk in practice is not being brute-forced, but another route (physical access to your machine; installing malware; etc.). – dr jimbob Dec 20 '11 at 20:09
  • Fair point; however, "reasonable password" may be an overgenerous assumption in most cases. "Well why can't you just set it to password123?" is practically the battle cry of my cow-orkers (and after some grumbling, they go forth and set it to PassWord123 themselves (or something very slightly different which pasess the lame-password filter)). – Piskvor Dec 20 '11 at 20:18
  • 1
    @Piskvor - If you force the idiots who use "PassWord123" to use ssh keys; they'll find a way to be insecure. E.g., why do I need a passphrase on my ssh key -- that's inconvenient (or have a trivial phrase like "this is fun") and then leave the key on multi root-user systems or back up their ssh key in public locations (gmail/dropbox/etc.). At least at the moment, I haven't run into these idiots needing root privileges on my systems. – dr jimbob Dec 20 '11 at 22:27
  • 1
    Another point for using private key, if you connect to a compromised server, it's quite trivial for the attacker to obtain the plain text of your pass phrase because SSH sends your password inside the encrypted tunnel. A private key however, is never sent to the server. If you reuse the same password on multiple machines, the attacker would be able to reuse that password they stole on another machine. – Lie Ryan Jan 19 '16 at 14:56

One reason thing that I believe makes the key-based authentication have a slight security advantage is there is are times I have seen both end users, and even I have on occasion entered my password in a username field instead of in the password dialog box (depending on ssh client). Or hit the enter key too quickly and the ssh client quit, and my password went into my terminal history.

If you are not careful every time you enter your password, then there is a chance your password is added in the clear possibly to several log files, potentially the shell history, or even to some kind of trojan-horse. In the case of a password-less key, or a key you load with an SSH agent at the start of your session, you should never be re-typing your password, so you are unlikely to type your credentials in wrong place and reveal your password to someone or something you didn't intend.

Well in a way it's 6's. The first immediate security risk of a password based login would be an unauthorized user obtaining (by whatever means) the password to the server. Likewise, a key-based login has the security risk of some unauthorized user obtaining access to your computer. If you use a complex password on the server, you run the risk of the password-users having to write it down somewhere in order to remember it. With the key-users, you run the risk of them walking away from their desk with the computer unlocked.

A lot of it comes down to risk-to-usability ratio. Of course you could require passwords on the keys, only allow certain IP addresses on a per key basis, and any other number of lock-tight security measures, but then that makes your people unhappy.

But to answer your question: If we're talking about a Vanilla configuration of OpenSSH, password based and key based logins both have their own, different security weak spots.

  • 2
    Of course you could require passwords on the keys I'm assuming you mean pass phrases for your keys but how can you enforce that on a user? – Beaming Mel-Bin Dec 19 '11 at 21:51
  • Yes, I did mean passphrase. You can enforce by saying "Use a passphrase when you generate your key, or the key doesn't go up on the server." – Safado Dec 19 '11 at 21:55
  • 2
    Dont forget that someone can remove the passphrase after you put the key on the server. – Squidly Dec 19 '11 at 21:57
  • 5
    Ha. I meant how can you verify that they used a pass phrase on their key? I was under the impression that you couldn't. Making it a policy is cool and all but no way to enforce it AFAIK. – Beaming Mel-Bin Dec 19 '11 at 21:58
  • You're right. I did over look that. – Safado Dec 19 '11 at 22:05

I always turn off password login over ssh for root on my systems. That way, there is no way an attacker can get in trying to brute force the password.

You should still be wary of security on the client systems. You may want to make the ssh agent forget your key credentials when your lock screen comes on. This would help prevent attacks on your client machine from compromising your key.

Some decent answers here but all seem to miss the mark in my view.

Using a key-pair for authentication is replacing the "something you know" of a password-based system with a "something you have" of a key or token system. Back to this in a second.

Keys are far more complex. I think most SSH implementations default to 2048 RSA key. Compare that to an 8-character password. Even if hashed into 256 bits, passwords, because they lack the randomness of keys can be brute forced. Schneier has some great observations on this; even supposedly "good" passwords tend to be only a combination of crackable data (a word with a number and maybe some simple substitutions); we humans just are too predictable.

As to a key being only as secure as the password to login, this is not entirely correct. By wrapping a key with another password, you greatly enhance security because you are essentially using two-factor authentication; in order to access the something you have (the key) you must use something you know (a password). Yes, using your login password to wrap a key would undermine this.

So to the original poster, I'd say both you and your co-workers are wrong. You may be less so than they are, but the right answer is you should be using both a key and a password.

  • You miss the point. The discussion is not if you should encrypt your SSH key with a password (you clearly should!), but if using only password based login is more or less secure then key based login. From the view of an outside attacker that didn't obtain the key, it's irrelevant if the key is password protected or not. Note: Requiring both key and password (link) to login is yet another issue. – Sven Sep 19 '16 at 18:47
  • 1
    The question is a bit like asking do I use the normal door lock or the deadbolt. The correct answer is don – JoePete Sep 21 '16 at 21:09
  • Missed the 5-minute limit, but to ask should I use a password or a key reveals, in my view, a misunderstanding of authentication. These are apples and orange factors. To the scenario of an outside attack, bear in mind that with a key-based system, compromising the client's host grants access to a SSH server. Whereas with a password, access will have to be brute forced (mitigated with a lockout). Bear in mind too a sysadmin can't control what a user does with his or her private keys. So again, apples and oranges. – JoePete Sep 21 '16 at 21:41