88

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.

techraf
  • 9,141
  • 11
  • 44
  • 62
thequestionthequestion
  • 1,181
  • 1
  • 10
  • 9
  • 6
    fail2ban is no silver bullet. They write on their own [website](http://www.fail2ban.org/wiki/index.php/Main_Page): "Configure services to use only two factor or public/private authentication mechanisms if you really want to protect services." – user10008 Oct 10 '14 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. – LordOfThePigs Oct 10 '14 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 '14 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. – Jonas Schäfer Oct 12 '14 at 10:38
  • Related: [Good practice to use same ssh keypair on multiple machnies](https://unix.stackexchange.com/questions/27661/good-practice-to-use-same-ssh-keypair-on-multiple-machines) unix.SE 27661 – n611x007 Aug 04 '15 at 11:57
  • You could force your users to expire their SSH keys if you control the server by periodically requiring them to submit a new public key and then rotating it in their .ssh directory and deleting the old key. – Simon Woodside May 09 '16 at 20:04

3 Answers3

78

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.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 31
    *and they sit on disk where they can be stolen from*. You can set passphrases for ssh keys. – user10008 Oct 10 '14 at 21:12
  • 6
    Agreed - which returns to the password/passphrase problem :) – gowenfawr Oct 10 '14 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 '14 at 21:21
  • 5
    Sorry, I should have been explicit - the ":)" meant "it returns to the [human nature](http://www.cbsnews.com/news/the-25-most-common-passwords-of-2013/) [password problem](http://www.whatsmypass.com/the-top-500-worst-passwords-of-all-time)" – gowenfawr Oct 10 '14 at 21:26
  • OK thats an issue. When it doesn't get sent to the server, you can't check the list of top 5k passwords – user10008 Oct 11 '14 at 00:12
  • 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 '14 at 07:39
  • Also, even if it /would/ get forwarded, it'd be forwarded across an established and secured SSH connection. – Shadur Oct 11 '14 at 16:31
  • 2
    @Shadur, the concern with forwarding is not the transmission step, it's the whether-the-middle-box-is-trustworthy-or-not step. – gowenfawr Oct 11 '14 at 17:25
  • How is it possible to brute force a password? Isn't it limited how many login attempts you can perform in a certain amount of time? – KaareZ Dec 12 '17 at 11:02
  • 1
    @KaareZ online (e.g., through the SSH process) attempts can be rate limited, but still fall victim to things like "top 1000 password lists" and the like. Offline attacks - like if someone gets a copy of the shadow file for a system - are not constrained in that manner. Bear in mind an attacker might get copies of files like shadow through broken or misconfigured services, but not have account access until they can brute-force those passwords. With SSH keys, on the other hand, the important bit isn't on the server at all. – gowenfawr Dec 12 '17 at 16:58
  • 2
    Mostly correct but there's a minor error: "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." The primary reason for expiring a password is to stop the damage going forward if the password has been compromised without anyone knowing. Rotating the password doesn't slow down a brute force attack much. (If it takes 1 year to search password space, then if you don't rotate, I have 100% of getting it in a year. But if you change every 6 months, I still have 75% chance of getting one of them) – Bennett Oct 04 '19 at 21:32
  • A client or server could "expire" keys, it could be as simple as "if file creation date for my half is older than 6 months delete it". So there is no way the connection will work, forcing you to create a new pair, or at least reinstate the old pair :) – pilkch Apr 06 '20 at 10:24
  • So, doesn't this answer fall apart when you start using auto-generated passwords the length of SSH keys? Any security issue with "guessability" has long evaporated with password generators. – Douglas Gaskell Dec 13 '20 at 08:56
44

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

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 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 04 '15 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 04 '15 at 12:16
  • Like [Reusing Private/Public Keys](https://security.stackexchange.com/questions/10203/reusing-private-public-keys) security.SE/10203, I see. Thanks for clearup! – n611x007 Aug 04 '15 at 12:41
6

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.

Shane Andrie
  • 3,780
  • 1
  • 13
  • 16
  • 7
    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. –  Oct 10 '14 at 22:05
  • 1
    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*. – The Spooniest Oct 11 '14 at 11:45
  • 3
    @TheSpooniest Kerberos [does not need to store a plaintext password](http://security.stackexchange.com/questions/15849/does-the-kerberos-kdc-know-the-users-plaintext-passwords) 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 '14 at 21:41