4

Background: I am running my own servers for personal use, I have complete control over all passwords used and for the foreseeable future things will stay this way.

I understand the arguments for why SSH keys are a stronger option, specifically that the entropy is far greater and bruteforcing is effectively impossible. Obviously, even with a good password, the entropy will be lower.

My question is this: If a good password is used, and all other security practices held equal, does a server administered by a single person gain much practically by switching to SSH keys? i.e., would the increase in entropy affect the probability of successful attack in any significant way? Are there factors I have not considered here which would lend a preference for one method versus the other?

To clarify, I am asking in terms of common threats a relatively small webserver with no interesting financial or personal information might face, less so than a motivated and targeted attack.

marked as duplicate by Community Jun 24 '17 at 1:17

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    It is more a question of comfort (using agent forwarding and caching keys). With passwords you need to use unique strong and long passwords for each service to avoid the risk of compromised servers. – eckes Jun 23 '17 at 19:32
  • Yes, and I mean disabling password-based logins entirely. – Davis Jun 23 '17 at 22:38
4

It might help to think of the authentication to SSH in stages and layers.

The first stage (building the first layer) involves establishing a symmetric encryption channel. This is done by using something called Diffie-Hellman (explanation here.) Once the encrypted channel is formed authentication starts.

Password Auth

In a traditional password example, the password is then passed to the server over this encrypted channel.

The risk here is that the password is reversible if you happen to have knowledge of the symmetric key that was negotiated. Further the password has to exist in some state on both systems.

Key Authentication

In the key model, it's more complicated but at the core it uses the asymmetric crypto properties: the server encrypts a nonce with the public key component, and since the client should have the private key it can decrypt the nonce and send back the md5hash to the server to verify it's identity. (Digital Ocean has a good explanation.)

Tl;DR: in the password case, both sides must have knowledge of the password. This leads you open to a leak/reuse style attack on the password.

In the key case, only the public key is required to verify the user. The private key stays private and only needs to exist on the client side. You can share the public key with as many services as you like and not change the risk associated with using the keypair.

  • 1
    I like the extra details about the authentication I had not considered. Now, as a follow-up, how hard is it to get that knowledge of the symmetric key? Is this a common attack? – Davis Jun 23 '17 at 22:41
  • 1
    @DylanCromer: It's hard and not going to happen unless someone screwed up. But there are lots of other issues too like side channel attacks, relative impact of successful MITM, etc. that make pubkey auth a much better choice. – R.. Jun 24 '17 at 0:35
1

My question is this: If a good password is used, and all other security practices held equal, does a server administered by a single person gain much practically by switching to SSH keys?

The problem with this question is that it's built on the premise of people using good passwords—something that people, in actual practice, do not do. You're asking us to draw a "practical" conclusion from an theoretical premise that doesn't hold up in practice.

In both cases, I think the biggest risk is that an attacker could obtain a user's secret and use it to authenticate as that user. With password-based authentication they might:

  • Target your users with a phishing attack. As 2016 has shown, this can be very successful.
  • Steal your password database and crack the entries to find weak passwords.
  • Target your users to steal their passwords on other services, on the hopes that some of them will reuse those passwords on your system.

With key-based authentication (as usually practiced, with the keys stored on the users' PCs with weak or no passphrase), the ways an attacker can obtain your users' keys is by hacking into their computer that stores the private key. This could be achieved by targeting your users with malware, which is another realistic attack.

If you're really serious about SSH authentication security, you have to look not just at using private keys, but also at how to store them securely so that attackers can't easily steal them from your users. Smartcards are the classic solution here; a dedicated hardware device that generates a keypair internally and promises never to reveal the private key; the SSH client must forward the authentication request for the smartcard to sign.

A more recent variant is to use a smartphone app to generate and store the SSH keys on the phone, and an SSH client that forwards auth requests to the phone, so it can authenticate the user without revealing the private key. I have no connection to the company, but I've been using the free edition of Kryptonite recently and though it's a young tool it's shaping up pretty well.

  • For larger companies or teams, this would be true, however for servers where there is only one user with SSH access I think they can safely assume that if they are using a good password, all of the passwords will be good (and it's up to that person to ensure it really is a good password). Now, obviously this isn't scalable to any situation with an arbitrary number of users. – Davis Jun 23 '17 at 22:47
1

Keys are immune to man in the middle attacks since the private key is never transmitted.

Passwords realisticially are not, no matter how good they are. If you use a password, there are far easier methods of cracking than brute forcing, so quality of password is likely meaningless.

also see Is it more secure for SSH clients to use a Private Key (RSA-2048) or a long random password (256 bits of entropy)?

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