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?

  • 10
    Do 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
    Jun 28, 2011 at 13:00
  • 2
    This should probably be moved to security.
    – DKGasser
    Jun 28, 2011 at 16:58
  • 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
    Jun 28, 2011 at 17:04
  • 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
    Jun 28, 2011 at 17:29
  • 3
    AND 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
    Jun 18, 2014 at 17:42

3 Answers 3


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.


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/


  • 8
    +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
    Jun 28, 2011 at 16:07
  • 3
    You'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
    Jun 28, 2011 at 18:14
  • 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. Jun 28, 2011 at 18:32
  • 3
    @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
    Oct 29, 2012 at 19:48
  • @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
    Oct 29, 2012 at 20:02

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.


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.

  • 1
    Note: but you can't encrypt your key with a password if it is to be used programmatically (ie. in a script). Mar 19, 2018 at 10:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .