26

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?

  • 10
    When done right, public key authentication is a form of 2FA with something you know (the passphrase to the private key) and something you have (the private key). – Sven Feb 19 '17 at 13:07
  • 1
    @EEAA Why does it matter as long as your private key has one? – immibis Feb 19 '17 at 23:31
  • 6
    With a private key, if I trick you into connecting to the wrong server by mistake, you don't type your password into my server. – immibis Feb 19 '17 at 23:32
  • 1
    Many organizations must (for whatever reason) require that two-factor auth is used. That is impossible to do by relying on encrypted private keys. – EEAA Feb 19 '17 at 23:33
  • 6
    For what it's worth, I disagree profoundly with Sven about the classification of the private key as something you have. It fails the fundamental test of a something you have, because it's arbitrarily reproducible, being simply digital data. Public-key authentication on its own is not 2FA; if you tell yourself it is, you're fooling yourself about your security. – MadHatter Feb 20 '17 at 7:36
32

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.

  • 2
    2b is very important. authorized keys are easily managed centrally, changing a password and distributing it to all users requires more work. – Jonas Schäfer Feb 20 '17 at 7:00
  • What techniques for managing authorized keys centrally are there? (I'm familiar with putting authorized_keys files on a shared filesystem, but there must be others) – pjc50 Feb 20 '17 at 10:04
  • 1
    At the point you have several tens or hundreds of servers, you are probably using Chef, Ansible, Puppet, Holo or something like that which manages those. Or you have the authorized keys in an LDAP or other database. – Jonas Schäfer Feb 20 '17 at 11:44
  • 1
    Don't forget agent forwarding: you can log in with ssh -A and from there, log into machines that allow the public of you originating host. – Halfgaar Feb 20 '17 at 19:42
  • @Halfgaar ... without specifically changing anything on the host you're connecting from. I just learned that feature, and I love it! – Canadian Luke Feb 20 '17 at 23:35
12

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:

  1. Post from serverfault.
  2. Post from security stackexchange.
  3. Post from superuser.
  • 2
    Keyphrase is a must IMHO. When using ssh-agent, have a look at ssh-add's -t option to make it unload keys after a certain time. – fuero Feb 19 '17 at 13:59
12

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.

2

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.

2

You are right about the "you don't need a password" claim. That is really insecure on the client side.

What makes allowing only public keys for logging in much more secure is the fact that there is no way to brute force access to your server. All an would be attacker can achieve is to put some load on your server - you can employ fail2ban to keep that in check.

For security on the client side you must protect the private key with a good pass phrase. Of course now connecting to the server is more cumbersome than with a password. To overcome this you can make use of ssh agent to store the private key in memory if you intend to connect to the server several times in a row. It is good practice to limit the time for how long a key shall be kept in memory.

  • 3
    no way to brute force access ... i would not say no way ... you can bruteforce the private key the same way as the password, but you have way more of entropy in the private key than in general password, which makes it quite useless (so far without quantum computers). – Jakuje Feb 19 '17 at 18:57
0

Possibly I am better served with Two-Factor Authentication.

One possibility for 2FA for SSH (and one that requires relatively little setup/complexity) is in fact using a public key and password.

I believe something along the lines of AuthenticationMethods publickey,keyboard-interactive can be added to /etc/ssh/sshd_config to make that work.

More generally, the issue is more that passwords (alone) are not a great method for authentication because they are often of dubious quality. A very simple 'argument' for keys vs passwords is that a key will generally be at least 2048 bits, and often more (for EC keys, this would be the effective strength, rather than actual size). Those bits are also generated by a cryptologically secure (or appropriate) mechanism.

A password is often less than 2048 bits, and is often not derived from a cryptographically secure source.

You can also secure your keys with a password, to guard against issues related to losing them (although someone could try and brute force that password).

So basically, the differences can be made fairly transparent between keys and passwords, and using keys buys you a better password than a human could deal with. This isn't to say they are a panacea, but on average, they provide more security than passwords.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.