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?

muru
  • 589
  • 8
  • 26
Aravor
  • 371
  • 3
  • 6
  • 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
  • @Sven Yes, but the rub there is that it's impossible to *require* private key passphrases. – EEAA Feb 19 '17 at 19:52
  • 1
    @EEAA Why does it matter as long as *your* private key has one? – user253751 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. – user253751 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
  • If someone hacks into your computer, they can most likely also sniff your password. It’s a different story when someone steals your harddrive. Against that, there’s Full Disk Encryption or passphrases on keys. – Jonas Schäfer Feb 20 '17 at 06:58
  • 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 07:36
  • 1
    You can have both: put the private key on a smartcard! https://access.redhat.com/articles/1523343 (not that this is very widely used) – pjc50 Feb 20 '17 at 11:55
  • 1
    @pjc50 I agree, but it's important to note that *the thing you have* then is not the private key, but the smartcard. The private key, and the cryptographic use thereof, is how you prove at a distance that you do have *the thing* at the moment you are asked. If the smartcard is badly-designed and makes it possible to extract the private key from it, or if the private key is ever known to the smartcard holder (eg, if (s)he puts it into the card in the first place), then again, the security is broken. – MadHatter Feb 20 '17 at 11:58
  • 1
    @MadHatter 2FA isn't predicated on there being exactly one copy of both factors. It's very much the opposite: disclosure of the private key isn't considered a harmful event because it's still useless without the other factor. That's enough to make access inconvenient to all but those who are willing to derive the passphrase using [rubber-hose cryptanalysis](https://xkcd.com/538). The card or whatever else you're using is just a carrier for the data. – Blrfl Feb 20 '17 at 20:01
  • @Blrfl I can't agree. Two data are just two *things you know*, and that's not 2FA. – MadHatter Feb 20 '17 at 23:52
  • @MadHatter It's _all_ data. To change my mind, you'd need to show me how a software system could come to understand that you're in possession of the thing you have without there being data involved. – Blrfl Feb 21 '17 at 00:01
  • 1
    @Blrfl I'd be delighted to, and you have cut neatly to the crux of the matter (well, nearly - the issue is not whether data are involved but *how* data are used to prove contemporaneous possession of a nonreproducible artifact, which is eminently possible) but this is not the place. Feel free to post exactly that question, if you'd like. – MadHatter Feb 21 '17 at 00:04
  • Please, people, don't use pass*phrases* (the client-side thing used to decrypt the key before using it), but server-side passwords (or both) in addition to the key. Why? Because on the server there are things like fail2ban, while on the client there are absolutely no rate limits and no limits how many GPUs etc. are used to bruteforce it. – deviantfan Feb 21 '17 at 03:19
  • You are going to get zelous discourse here due to the variations in experience and idealism. Passwords and keys can be equally secure or insecure, depending on many variables. It is really a loaded topic and folks will get emotionally committed to a response. TL;DR, if you follow good practices at every step, you are in a better place than others. The challenge is getting everyone around you to follow good practices. People are basically lazy and ssh keys are everywhere. :-D Even the creator of ssh agrees with me on this. Time for a do over. – Aaron Feb 21 '17 at 05:02
  • @deviantfan If we posit an attacker that gains access to the private key file on your workstation, we could just as easily posit an attacker that gains access to /etc/shadow on the server (or a backup copy thereof). In neither case does fail2ban & Co provide any protection, and the answer is the same: Use strong passphrases to protect your assets (the account or the private key), and change them if you have any reason to believe that they may have been compromised. Oh, and while fail2ban may or may not help much; why aren't you running at least something like logcheck on your workstation? – user Feb 21 '17 at 08:22
  • @MichaelKjörling In my experience, servers are indeed better secured than client devices, especially eg. some top managers insist on having root access (even if the only command they really know is "free -m"). Sure, stupid, but that's reality. ... And independent of how and where I check logs, how would logcheck help me when eg. the managers running laptop is stolen? – deviantfan Feb 21 '17 at 14:58

6 Answers6

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.

pjc50
  • 1,720
  • 10
  • 12
  • 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 07: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.
Community
  • 1
Khaled
  • 36,533
  • 8
  • 72
  • 99
  • 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.

Paŭlo Ebermann
  • 253
  • 1
  • 8
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.

fuero
  • 9,591
  • 1
  • 35
  • 40
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.

warren
  • 18,369
  • 23
  • 84
  • 135
guntbert
  • 631
  • 9
  • 21
  • 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.

iwaseatenbyagrue
  • 3,688
  • 15
  • 24