If people use a password to log in to a UNIX server, then it could be forced to expire the password, then they change it.

If people use an ssh key and have no passwords, no password expiry, then nothing forces them to change their SSH key regularly.

Question: Which solution is more secure? Why do the "howto"'s for hardening a server always advise to use an ssh key, not passwords?

UPDATE: not counting the brute-force weakness - regarding passwords, since they could be guessed if there is no Fail2ban-like solution.

  • 6
    fail2ban is no silver bullet. They write on their own website: "Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services."
    – user10008
    Oct 10, 2014 at 21:14
  • 1
    I suppose any of these could be mitigated by configuring 2-factor authentication, using libpam-google-authenticator. That might be a better strategy than just picking any one of those 2. Oct 10, 2014 at 22:14
  • I don't see the value of it, but (server side) it should not be hard to whip up a cron job that "expires" keys in the authorized_keys file; or (client side) whip up a cron job that "expires" keys (making the client change the passphrase).
    – emory
    Oct 10, 2014 at 23:52
  • 2
    One of the things I learnt to love about keys is that you can have different keys for different devices (or people, for that matter). This allows you to “revoke” (remove from authorized_keys) the keys for each device seperately (e.g. when you sell or lose it) and be done with it. Oct 12, 2014 at 10:38
  • Related: Good practice to use same ssh keypair on multiple machnies unix.SE 27661
    – n611x007
    Aug 4, 2015 at 11:57

3 Answers 3


Both keys and passwords have their pros and cons. The reason that "howtos" and the like advise using the SSH key is that they find their cons less worrisome than passwords' cons.

SSH keys are long and complex, far more than any password could be. But as you state, they don't have expiry, and they sit on disk where they can be stolen from. On the other hand, they don't get transmitted to the remote system (except key forwarding, natch) which passwords need to be.

Passwords are generally, predictably, unavoidably weak. While it is possible to have strong passwords, time and again it has been shown that people will use weak passwords and have poor password practices... short, simple, word-based, simple patterns ("p@ssw0rd!"), write them down, use them on multiple sites, base them on their phone number, their children's birthdate, their own name. You point out that keys don't expire, but why do passwords expire? To ensure that a brute-force attack is less likely to crack a password before it's been replaced. Not an issue that impacts keys.

And, bad passwords aside, even "good" passwords are vulnerable to brute-force (online or offline) under the right conditions. They have to get transmitted to the other system, or to any other place that the user can be fooled into sending them by mistake.

The balance of evidence strongly suggests that passwords are weaker and keys are stronger.

  • 31
    and they sit on disk where they can be stolen from. You can set passphrases for ssh keys.
    – user10008
    Oct 10, 2014 at 21:12
  • 6
    Agreed - which returns to the password/passphrase problem :)
    – gowenfawr
    Oct 10, 2014 at 21:18
  • 22
    Not at all. That one never gets to the server not even as a hash. Nobody can brute-force it unless they have access to your drive, when ssh has passwords, everybody can brute-force it. It offers the advantages of both approaches.
    – user10008
    Oct 10, 2014 at 21:21
  • 5
    Sorry, I should have been explicit - the ":)" meant "it returns to the human nature password problem"
    – gowenfawr
    Oct 10, 2014 at 21:26
  • 12
    The private key never leaves the owner's computer even in the case of agent forwarding. What's forwarded in that case is a port that the remote system can use to check against the local key, but the actual check is local. Someone in the remote system can sign with the private key but only while the agent is forwarded, the actual private key is never exposed.
    – rewritten
    Oct 11, 2014 at 7:39

With passwords, then the password is sent to the server, so the safety of the password is relative to how well the server protects whatever it uses to verify passwords (e.g. the /etc/shadow file). When you use an SSH key, then your private key remains on the client side, and no secret value is ever sent to the server. Even if the server is under hostile control, or you are somehow induced into connecting to a fake server, then your SSH key remains safe. A fake server does not gain enough information on your key to recover it or do some MitM. In that sense, SSH keys are more robust than passwords against compromises on the server side.

On the other hand, a SSH key must be stored somewhere, on a computer, and this can be a vulnerability. You have to protect your private key with a passphrase; otherwise, a stolen laptop turns into an account compromise. Conversely, a password can be stored in your brain only, which (supposedly) makes it less likely to leak.

Thus, it can be argued that SSH keys are "more secure" than passwords, but the opposite can also be argued. It depends on the context. Most HowTos will take the stance that keys are better because it so happens that, on average, human users have a terrible track record for passwords. Users choose weak passwords, and reuse them (password reuse is very very bad).

  • 1
    I was under the impression that keys and passes in ssh protect the server. The argument that using keys keeps the client's secret intact seems strange: if the server is already compromised then what's the value of keeping client keys/passes secret? (This still leaves the fake-server argument intact.) An attacker can already do whatever on the compromised server, including installing backdoors.
    – n611x007
    Aug 4, 2015 at 11:50
  • 2
    In SSH, client keys are not server-specific (usually). A given user has one public/private key pair, and uses it to connect to several servers. The problem I am talking about here is whether compromising one server indirectly yields access to all other servers to which the user is authorized to connect -- and the answer is no, because of the way client keys are used in SSH.
    – Tom Leek
    Aug 4, 2015 at 12:16
  • Like Reusing Private/Public Keys security.SE/10203, I see. Thanks for clearup!
    – n611x007
    Aug 4, 2015 at 12:41

If what I am understanding in your update, if your can provide the same entropy in your passwords vs keys, than as far as its security it's moot. You could make tthe case that keys are better because it would provide a better "user experience" because your not typing in passwords every time.

I think more to your original point, we are discussing the manageability of SSH passwords vs SSH Keys. Yes passwords can be assigned policies, which allow basic security measures (IE Password expiration, password history, mix-max password length, etc) but this doesn't change human habit, and it also doesn't please users where security becomes encumbering to production (A balance at an organizational level).

Keys provide method for maintaining a degree of entropy and manageability while also providing a method of access that doesn't encumber a user (Once your key pair is setup you can authenticate without a password prompt until it's revoked.)

On top of this, know that Keys can be password protected and providing another layer.

  • 8
    You seem to think that a password of the same entropy as a key has the same security as that key, but that's incorrect since a password, no matter how long is still transmitted to the remote server where as a key isn't. Connect to a rogue server with your password and it gets stolen, connect with a key and the rogue server can't do anything with it.
    – user42178
    Oct 10, 2014 at 22:05
  • 2
    Actually, not all password systems transmit the key over the network. Kerberos, for example, does not: instead, anyone who claims to be the user gets sent a ticket, but the ticket is first encrypted with the user's password. So it has to be decrypted on the client side before it's good for anything, and for that, the password needs to be correct. This gets around needing to send the password over the network all the time. On the other hand, it means that you have to have one machine which stores all the passwords in cleartext, so that machine has to be locked down hard. Oct 11, 2014 at 11:45
  • 4
    @TheSpooniest Kerberos does not need to store a plaintext password on the KDC; it encrypts the ticket not with the user's password, but with something derived from the user's password, preferably with a one-way function. Compromising it compromises accounts within that Kerberos realm (the derived key is all an attacker needs to authenticate), but doesn't let an attacker use compromised passwords to attack independent services any more than compromising /etc/shadow would.
    – cpast
    Oct 11, 2014 at 21:41

Not the answer you're looking for? Browse other questions tagged .