Why should I use Public-Key Authentication for SSH?
I am running a SSH server and I am still using simple password authentication. Everywhere I read about security I am advised to use Public-Key Authentication. But I don't get the advantages. Using them is, in my eyes, either insecure or a lot of handy work.
Of course, if someone tries to brute-force the login into my SSH server Public-Key is a lot stronger than any password. But aside from that, it's totally insecure.
The advisors mostly argue that you don't have to remember a password. How insecure is that? So if someone hacks into my computer, he doesn't just get my computer, but my server too? If I am using SSH from various different clients, I have to store the public keys one every one of them, which multiplies the possibility that they fall into the false hands. I could save them on a usb-stick which I carry with me, but it can be lost and the finder has access to my server.
Possibly I am better served with Two-Factor Authentication.
Is there any argument I am missing? What is the best way for me?
Solution 1:
if someone hacks into my computer, he doesn't just get my computer, but my server too?
This is potentially true anyway with keyloggers: as soon as you log into your server from the compromised computer, they get the password.
But there are 3 advantages to keys:
1) Cacheable authentication. Enter your passphrase once, carry out multiple ssh commands. This is very useful if you're using something that uses ssh as a transport, like scp, rsync or git.
2) Scaleable authentication. Enter your passphrase once, log into multiple machines. The more machines you have, the more useful this is. If you have 100 machines, what do you do? You can't use the same password (unless it's a clone farm), and you can't remember that many. So you'd have to use a password manager, and you're back to single point of compromise. Effectively the key passphrase is your password manager.
2b) It scales in the other way if you have multiple admins using the same systems, because you can revoke keys from user A without having to tell B,C,D,E,F... that the password has changed.
(This can also be done with individual accounts and sudo, but then you have to provision those accounts somehow)
3) Automation and partial delegation. You can set up SSH to run a particular command when a key connects. This enables an automated process on system A to do something on system B without having full passwordless trust between the two.
(It's a replacement for rlogin/rsh, which was hilariously insecure)
Edit: another advantage to public keys rather than passwords is the common scenario where the server is compromised through a vulnerability. In this case, logging in with a password compromises the password immediately. Logging in with a key does not! I would say this is more common than the admin's originating desktop getting compromised.
Solution 2:
If you are using good passwords, this can be secure enough. I usually limit the number of publicly accessible servers to the minimum and allow SSH from specific IP(s) whenever possible.
Also, you can protect your keys by passphrase (password). So, this passphrase must be entered whenever you need to login to your server(s). No one can then use your key unless the right passphrase is provided.
There are similar posts:
- Post from serverfault.
- Post from security stackexchange.
- Post from superuser.
Solution 3:
One way where public-key authorization is more secure is when the attacker manages to be man-in-the-middle (MitM) between your client computer and the server, and you don't notice the changing host key (possibly because you didn't have the old key, e.g. because this is the first time using this specific client computer).
(The same applies when the attacker manages to take control of the server, and there are other servers where the same credentials work.)
With standard password-based authentication, you are submitting your password (inside the encrypted connection) in plain text, the genuine server will normally hash it and compare the result to a hash stored in its password database. A MitM attacker could instead take this password, open a connection to the real server, and login there ... and either forwarding the contents to you (so you don't notice anything), or just doing its own evil stuff on your server.
With public-key authentication, the client is basically signing some data known by both server and client to prove it is in possession of the private key, and sending the signature to the server. This signed data includes a session identifier, which depends on random numbers chosen by both client and server, and is thus different for each session. If the MitM opens its own SSH connection to the real server, that one will have a different session ID, and thus the signature provided by the client will not work there.
Of course, as other answers already told, you need to keep your private key secure, e.g. encrypted with a passphrase, or possible on a separate device which only creates signatures after entering a PIN.
Solution 4:
OpenSSH can keep its own CA to manage SSH host and client keys and can use revocation lists on them. This could add to the security provided by key-based authentication.