24

I've usually been told that public key authentication is strongly preferred over password authentication for SSH. However our previous admin was against public keys and only issued passwords and took care to use different passwords for different servers (pwgen generated passwords; they are reasonably difficult to brute-force, but guaranteed to be written down by the user). So I'd like to ask:

  1. Does using password make more sense for administration (non-root with more or less sudo capabilities) full shell login. Given that passwords are different where the key probably wouldn't be and the password than used for sudo as well.
  2. Was it OK even for special account for sftp upload (restricted to particular directory) where the password ends up in a file on some other server, because the upload needs to be unattended? The public key would end up stored unencrypted on the same other server.
Improve this question

6 Answers 6

Reset to default
21

It's kind of like this… I am divorced and have a vitriolic ex wife. I also have three great boys, who like most boys can be forgetful, lose things, and who also love their mom. When my boys got old enough to need a key to my house, I had a decision to make: do I use a keyed lock or one of those numeric key pads? If I use the keyed lock, it was certain that my sons would regularly be losing keys; I would be getting calls to come home from work to let them in; and there was a big possibility I would have to replace the lock or have it re-keyed from time-to-time because the number of "lost keys" (or probability my vitriolic ex wife now possessed one) reached an uncomfortable limit.

While not maybe the safest in the world, with the numeric lock I had no concerns about the keys being lost; I could text my sons the combo from work (without coming home) when they forgot it; and I could periodically change it when I felt it was compromised. I could also decide how long and/or complex I wanted it. If I thought my ex had it, I could change it as well. A lot simpler and less total cost of ownership.

The keyed lock is like PK. The numeric lock is like passwords. In the end, I can tell you, I am a lot safer with the numeric lock, because I choose my own destiny and can do so as dynamically as I want. And remember, the reality is that the door is just one of the ways into my house.

Improve this answer
3
  • 5
    I like this analogy. However, it isn't perfect. In a managed key situation, I think keypair auth would be more secure. By "managed" I mean, the user has no control over his authorized_keys file -- that file is overwritten by a config management system, managed by a central sysadmin team. if the user loses his key, the sysadmin changes the authorized_keys in much the same way as he would change the user's password. Thus you get the security benefits of PK auth PLUS the flexibility described in this analogy
    – JDS
    Aug 14, 2014 at 14:03
  • 1
    Please, do not promote using passwords instead of keys. You can enforce key rotation. And keys should be locked down with passphrases in any case. A key is like a 2048-bit password protected by another password (the passphrase). What stops your vitriolic wife from installing snooping software (keylogger) on your son's phone, easily retrieving the 4-number combination?
    – sleblanc
    May 12, 2015 at 13:10
  • 3
    You obviously didn't get the analogy... This is why security practitioners get the hairy eyeball from the rest of the world. While in a purely technical sense certificates are much stronger than passwords, badly implemented certificates are more swift/silent/deadly than passwords. How many organizations implement them perfectly, oh right, with the recent onslaught of hacks against them, not many.
    – Tek Tengu
    May 12, 2015 at 17:11
11

In the case of password authentication, the user remembers the password and is responsible for not revealing it to anybody. With public key based authentication, the user has the private key somewhere, stored as a file.

Users prefer key-based authentication because it is more convenient to use in practice (SSH clients will use the key transparently, so that's zero-effort for the human user). However, key-based authentication implies the following:

  • The user himself manages the keys, and which keys are accepted or not, by putting the public keys in his .ssh/authorized_keys file.
  • The private key is necessarily stored as a file somewhere, perhaps (but not necessarily) protected by a passphrase.
  • The choice of local passphrase (or lack thereof) is completely out of reach of the server sysadmin.

Some sysadmins prefer users to use key-based authentication because they don't trust human users for remembering strong password; they believe that the security of a private key file will be easier to maintain by average users than generation and usage of a strong password. Most sysadmins, however, consider that private key files are a glaring vulnerability, whereas with passwords they have mitigation mechanisms: they can enforce "password rules" when the password is chosen, and they can centrally block or reset passwords when they want. It is really a balance between how much the sysadmin trusts the users (trust in their competence, not in their honesty) and how much a control-freak the sysadmin is.

Improve this answer
4
  • The passwords he issued were generated. Basically guaranteed they will be written down.
    – Jan Hudec
    Mar 29, 2013 at 15:07
  • Do you have anything to say to the second case, account for use by another application rather than interactive user?
    – Jan Hudec
    Mar 29, 2013 at 15:09
  • 5
    Private key files can also be invalidated and reset in centralized manner.
    – Lie Ryan
    Mar 29, 2013 at 15:10
  • 4
    .ssh/authorized_keys is but the most common way of managing the public keys (and a matter of setting up sshd_config); there are various centralized solutions in use.
    – Piskvor left the building
    Mar 29, 2013 at 15:54
8

Passwords

  • can be easy to forget.
  • can be easy to guess / crack.
  • can have different contraints in terms of characters you can use, length...
  • are very often re-used on different services.
  • have you heard of those passwords database leaked?

Challenge-Response

SSH keys (or api token)

  • don't have to be remembered (stored on your computer).
  • are tougher to guess / crack (compared to dictionary attack).
  • need not be shared on different services.

Asymmetry / password strength.

  • Most public/private key solutions use asymmetric keys (haven't heard otherwise but wouldn't put my money on it). If your public key is compromised, then that does not give an attacker access to the system.
  • Password databases need to have one-way encryption; and one that is strong enough or that wastes enough compute cycles that it becomes difficult to brute-force.

Reset workflow

Using passwords or ssh keys is irrelevant here, at some point a user is going to either forget their password (e.g. they had CAPS LOCK when they created it...) or reinstall their system (e.g. time machine / upgrades ...). How do you cope with such situations? You will have to change the password/key (assume the previous one is compromised) and securely communicate the new one to the user.

See the accepted answer. If your kid is trying to get inside your house. The challenge there is you first need to confirm it's your son (e.g. you know it is their phone number, you recognize their voice, that's the challenge part). The very common workflow is to generate a temporary password / one-time password and have your son change their password. But, this could very well be: give them a one-time password and let them upload their new ssh key / api token. Heck, you could even not bother to let them change their credentials at all and just remotely let them in if your keypad/keylock is connected.

Note: nothing prevents your ex-wife to collude with your son in order to trick you and gain access to the house.

Which one is better?

This depends on your use-case and acceptable losses. Since both passwords / ssh keys / api tokens are being possessed by a user, the user can share them. If you support password authentication and passwords get leaked, then some of your users may have to change their passwords on external websites -- just because they re-use the same passwords elsewhere. If you use public/private keys, then you have less to worry about.

You don't have to choose one or the other. You can use both! E.g. you can have both a keylock (your personal copy) and a numeric padlock (guests).

Improve this answer
6

Passwords can be brute forced. Guessing a public key is so essentially impossible that they can be considered perfectly secure. Passwords can only be assigned one per user, whereas a single user account can have multiple keys installed. If I lose my laptop, I only have to delete the entry for my laptop's key in the authorised_keys file, and that account is still accessible from my other devices with their own keys. Individual keys can also be given command restrictions, allowing an automated connection that runs a specific command but not a full shell. The only way passwords are of any benefit is sharing access to an existing account without logging in (to upload the new key) and this opens the security hole of having to change that password if you need to remove that access where a key is individual.

Improve this answer
2
  • That's all the advantages of private keys that I know. But I was curious why someone might elect to not use them and use passwords (autogenerated ones that everybody is guaranteed to write down somewhere) instead.
    – Jan Hudec
    Feb 7, 2014 at 7:29
  • My very last point is the only benefit I know of to passwords, and thus my answer; I felt the need to post the counter-point as well for the sake of those who read answers here as good reasons to not use keyed connections.
    – mikebabcock
    Feb 8, 2014 at 4:33
3

Interesting topic, for me the safest is password, I use 4 different passwords for different things depending on the security required, for example for a site like this I will use something like (mexico1970) which I dont care if it gets cracked since I just post to the site and there is no credit card info or any other important info to protect, then I will have another password for more important issues lets say for email something like (!!carmelita.99) then I will have one for server user access (XrE.67-73up) then another for root access and for bank stuff, (!!.CeRto-49er) then I make sure I dont write down this passwords, I memorice them, whenever I am connecting to my servers I make sure the ssh fingerprint is already added to my known hosts, otherwise there might be a MITM attack going on also make sure the bank TLS/SSL certificate is valid, and never share passwords.

What I hate is those services that require you to set a password so imposible that you have to write it down, or some other that have password policies where I have to use a different password each month and cant use the last 5 passwords used, that is just stupid, since there is no security in writing down the passwords, changing passwords is something good but it shouldnt be enforced, on the other hand, certificates are prone to be lost or even compromised, think you have someone with access to your computer they can install keyloggers or also they could also get the certificates. so there is no one thing that will keep you safe, but certificates for sure are not safer that passwords. with servers I get a feeling of security when multiple mechanisms are set, lets say a VPN to access a machine from where you can connect to your servers via SSH, obscurity? maybe but have never been hacked.

Cheers, I like a site where I can post without passwords.

Improve this answer
1

Barrett et al. (2005) says:

Passwords, however, have serious drawbacks:

  • In order for a password to be secure, it should be long and random, but such passwords are hard to memorize.

  • A password sent across the network, even protected by an SSH secure channel, can be captured when it arrives on the remote host if that host has been compromised.

  • Most operating systems support only a single password per account. For shared accounts (e.g., a superuser account), this presents difficulties:

    • Password changes are inconvenient because the new password must be communicated to all people with access to the account.
    • Tracking usage of the account becomes difficult because the operating system doesn’t distinguish between the different users of the account.

To address these problems, SSH supports public-key authentication: instead of relying on the password scheme of the host operating system, SSH may use cryptographic keys. Keys are more secure than passwords in general and address all the weaknesses mentioned earlier. (p. 26)

References:

Barrett, Daniel J., et al. SSH, the Secure Shell: The Definitive Guide. 2nd ed, O’Reilly, 2005.

Improve this answer

You must log in to answer this question.

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