SSH password vs. key authentication

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.

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.

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

• can comprise any amount of challenges (e.g. enter 3 passwords in a row)
• can support one-time passwords (OTP - http://pdub.net/2012/01/03/one-time-passwords-pam/)

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