Why is SSH key authentication better than password authentication?

46

13

This isn't so much a technical question as it is conceptual. I understand the cryptography used in an SSH key is far stronger than a regular password, but I don't understand why it is considered more secure.

Most tutorials I read suggest using SSH key authentication rather than password authentication. But my understanding is that anyone who then has access to a pre-approved client machine will then be able to connect to the server, meaning that the level of security provided by the SSH key is only as strong as the level of security of the physical client machine.

For example, if I setup an SSH key on my phone to connect to my home machine, should I lose my phone and someone manages to unlock it, they will be able to connect to my home machine. I know I can then remove the key for my phone from my home machine, but I'm vulnerable until I realise the client device has been lost/breached.

Have I misunderstood something, or are those valid concerns?

BoomShaka

Posted 2011-06-28T12:49:08.137

Reputation: 563

10Do both - a key that requires a password. That way you need two things to be identified, not just one. You can also invalidate lost keys quite easily, and have multiple authorised keys for more control over that, so on. – Phoshi – 2011-06-28T13:00:50.130

2This should probably be moved to security. – None – 2011-06-28T16:58:44.493

10@DKGasser: No, it shouldn't. It's a perfectly valid question here. Just because something can be moved to another SE site doesn't mean it should. – Wuffers – 2011-06-28T17:04:28.983

@Mark If it has a place that was designed precisely for it, I think it should? – None – 2011-06-28T17:20:05.963

4@DKGasser: It could go to that site, it is a perfectly valid question there. But it is also a valid question here, so there is no reason to migrate it. If this question were to be made off topic here, then yes, it could be migrated there. But it is totally on topic on this site and therefore shouldn't be migrated. – Wuffers – 2011-06-28T17:29:11.383

@Mark - according to the FAQ it is offtopic here - but on topic at security.stackexchange. SU is for questions about computer hardware and computer software, but this questions is not actually about either, it is about why a particular method is better than another (and I don't mean method in the programming sense) – Rory Alsop – 2011-06-29T12:01:45.650

@Rory: This is a question about SSH, which is computer software. So it's on-topic. – Wuffers – 2011-06-29T15:36:54.033

But the question is around what is better - key auth or password - which is a pure security question, that pretty much has nothing to do with SSH or whichever toolkit you wish to use. It doesn't really matter whether it stays, but I know which site I would go to for security specific guidance though:-) – Rory Alsop – 2011-06-29T18:53:27.467

3AND don't forget, the SSH key never goes over the network. The remote server NEVER gets the key, as opposed to a password, that is not only sent over the network, but sent to the remote server. Think about that next time you're not sure what password to use, and try a few... that maybe used on other accounts! What passwords did you send to that server??? – 9mjb – 2014-06-18T17:42:11.700

Answers

40

If your SSH service allows password based authentication, then your Internet connected SSH server will be hammered day and night by bot-nets trying to guess user-names and passwords. The bot net needs no information, it can just try popular names and popular passwords. There's an awful lot of people named john with a password of qwerty123. Apart from anything else this clogs your logs.

If your SSH service only allows public-key authentication, an attacker needs a copy of a private key corresponding to a public key stored on the server. They can't just make random attacks, they have to have prior knowledge of your users and have to be able to steal a private key from the PC of an authorized user of your SSH server.

The fact that private keys are often protected by a long pass-phrase is of secondary significance.

Update:

As comments point out, and as I have experienced, moving your SSH service from port 22 to a high numbered port makes a dramatic difference in the number of unauthorized login attempts appearing in your logs. This is worth doing but I do regard it as a form of security by obscurity (a false sense of security) - sooner or later bot-nets will implement slow stealthy port-scanning or you will be deliberately targeted. Better to be prepared.

I always use a long pass-phrase to protect my private key, I guess this is of particular importance on mobile devices that could more easily be lost or stolen.

Also, http://xkcd.com/538/

Security

RedGrittyBrick

Posted 2011-06-28T12:49:08.137

Reputation: 70 632

There's a couple of other things here: (1) kernel tweaks on the server to detect port scanning (plenty of links on the net for them) and (2) the more chilling prospect of your public bastion getting cracked (see (1)) meaning the attacker can then easily slip unnoticed into the private subnets. Password suddenly way more needed in that situation. Although the advice really is to use immutable infra and not have anything other than app ports available on private subnet boxes. Or not have boxes at all and use serverless. You get the idea. – volvox – 2018-07-20T18:17:21.053

7+1 except that public-key auth will do nothing for your logs getting clogged with bots trying to connect. To stop that, run your SSH server on a high port (i.e. 9876 instead of 22). Then if they want to hit you they have to portscan you first, and bots generally don't waste that much time... there are plenty of SSH servers on 22. – Ex Umbris – 2011-06-28T16:07:10.317

3You're not kidding on log size - my /var/log/secure went from megabytes of login attempts, to kilobytes (with just my login records). – John C – 2011-06-28T18:14:47.057

2+1 Interesting, I've run with password based auth for.. like 10 years now.. lol.. Granted, my publically exposed ssh ports are never port 22. Think the botnets will port scan me and try to bust in on every port they can?? Good info, thanks. – James T Snell – 2011-06-28T18:32:16.967

2

@ExUmbris rather than changing the port you should consider using fwknop: Single Packet Authorization and Port Knocking. The benefit here should be obvious: when you don't allow anyone to even see that the port is open anywhere unless they have been given access to the port through knocking with SPA, then they can't even attempt to find it with nmap and exploit it. That is much better than simple security through obscurity.

– aculich – 2012-10-29T19:48:02.287

@aculich Changing the port is not "security through obscurity". All I'm doing is preventing the logs from filling up with warnings. However, you have a valid point about improving security with SPA. – Ex Umbris – 2012-10-29T20:02:30.103

8

The logic is that there are a lot more combinations of SSH keys than passwords so it is a lot harder to guess. Using SSH keys also allows you to disable password authentication meaning that most of the automated attacks going round the internet will be useless.

With regard to physical security there's no difference between saving a password and having an unencrypted SSH key on your device if it gets lost or stolen. The only advantage you'd have is that no one has your password and you could theoretically make sure that all devices have different SSH certificates so you can just disable the one for your phone.

I believe it's also possible to password protect SSH keys.

Matthew Steeples

Posted 2011-06-28T12:49:08.137

Reputation: 2 130

It's worth noting, though, that password brute-forcing attempts against sshd can be detected and protected against (e.g. by fail2ban), whereas someone who has stolen your private key can try passwords on it as fast as their computer (or cluster) will let them. This still isn't a great attack, but they've improved their odds drastically versus a reasonable fail2ban policy.

– Boycott SE for Monica Cellio – 2016-04-26T21:11:23.043

1

Passwords can also be compromised by your keyboard being monitored "over-your-shoulder". In addition, using similar passwords in many places is a weakness, especially if the password is sometimes used on a less-secure computer with potential keyloggers.

You're right that an unencrypted key can be read off the hard disk if the computer is stolen - so encrypt it with a password.

If your computer is compromised by malware, you're stuffed regardless.. - someone can get the encrypted key and keylog your password.

eug

Posted 2011-06-28T12:49:08.137

Reputation: 724

1Note: but you can't encrypt your key with a password if it is to be used programmatically (ie. in a script). – TheStoryCoder – 2018-03-19T10:59:19.583