Having a debate with a coworker about the merits & faults of public key authentication with ssh.
I'm basically wondering what all the possible merits and faults are, especially in regards to passwordless private keys.

In our environment, ssh is not accessible to the outside world. Meaning that you would have to get in through a VPN before you would be able to ssh to anything. For arguments sake, lets assume this VPN uses the same account backend, so a password used for the VPN is the same password for your account when connecting via ssh.

One argument is that passwordless ssh keys have no use. They are insecure and if compromised would let an attacker access all our systems.

My argument is that further security measures make that argument moot. Because you must first connect through a VPN, having the private key doesnt get you in the front door.

Is this argument valid? Are there any other arguments for or against?

  • 5
    I think your question is buried under a TL;DR mountain. Try to reduce the amount of context and information. My take on your question: "Is public key access to SSH secure if a weak or no password is used to secure the private key?" The answer is obvious, but your context is attempting to spin it around secure VPN access. Good security requires defense in depth. Don't rely on one layer to protect another. Commented Feb 27, 2012 at 22:27
  • @logicalscope ya, youre right. I tried to ask too many different questions. Editing it down to a specific few.
    – phemmer
    Commented Feb 27, 2012 at 22:45
  • You should look into 'ssh-agent'.
    – stolsvik
    Commented Feb 29, 2012 at 6:32

4 Answers 4


This is a typical defence-in-depth question. Why do I need X if I already have Y and Z in place?

The common answer is that your security is usually as good as its weakest link. In your case, your one and only security mechanism appears to be your VPN. This is your strongest and weakest link. In your opinion it is enough protection and no additional protection is necessary.

Perhaps you're right. It might be good-enough. At home, I only have one lock on my door. I know two locks would be stronger, but the cost/hassle of installing another lock, and having to use two keys is not worth it for me. I don't have much worth stealing anyway. But if my lock or your VPN get compromised, then we're left with little or no protection. The VPN security can be compromised in a variety of scenarios, some of them are as trivial as someone accidentally making a stupid configuration change that leaves your VPN open for example. Also, even if the VPN is 100% waterproof, an employee might decide it's a great idea to plug in a wireless router to your network so they can use their iphone more easily, leaving a chance for getting into your network without the VPN. It of course depends on your organisation, the setup and so on. The basic principle is the same.

You'd have to consider the strength/weakness of your protection against the cost/worth of your data. Then add in the 'residual cost' of adding and managing another layer of protection, and see if it's worthwhile for you. Installing another VPN gateway - so you have two VPNs - might be costly and inefficient. Adding passwords to your ssh private keys might however be easy and cheap enough to be worth it.

  • 1
    This is largely the type of answer I was looking for, but what if the public key is only used for jumping between servers, not used for connecting from the personal computer? Though I dont know if its possible to restrict ssh to only accept the key if it comes from a certain subnet.
    – phemmer
    Commented Feb 28, 2012 at 10:39
  • The same principle applies here too, but what you're now saying is that you have one extra layer of protection (for gaining access to the server from the PC you'd need a password or an authorized public key). It might or might not be enough. You can still enhance security between servers, e.g. by using password-protected ssh keys, using iptables to limit access between servers, harden your sshd_config etc. It's all still a question of cost/benefit or cost/risk.
    – Yoav Aner
    Commented Feb 28, 2012 at 11:09
  • 2
    @Patrick You can restrict a key to a subnet with the from option on the key in ~/.ssh/authorized_keys. Commented Feb 28, 2012 at 12:50

There are two main ways for an attacker to obtain the private key file:

  • By compromising the client machine, in which case the attacker can usually obtain the password as well.
  • By compromising a backup of the client machine, or stealing that machine.

If you're comparing private key authentication with password authentication, only the second case is relevant. A strong password on the private key file is indeed necessary for security in the second case.

You can reduce the risk by excluding the private key file from backups, but it sounds like you have little control over the client machines, and theft is always a possibility. You can also reduce the risk by having a way to deactivate a key quickly. If a penetrating your network requires a VPN connection in addition to the SSH key, this increases the time window for deactivating the key before any harm can be done.

Note that a password is not a panacea either. SSH clients tend to make password authentication difficult to automate, but sufficiently annoyed users will write the password in a plain text file anyway, and may even expose it in a script or configuration file somewhere. Using a private key file has the advantage that the confidential information is concentrated in one file that users don't tend to copy around.

Another consideration that is to the advantage of private keys is that they tend to be easier to revoke, from a social point of view. Telling a user that they have to change their password is never appreciated, and you have no way to make sure that they won't change from Password123 to Password456. (Unless you force the passwords, in which case you know they've written it down somewhere.)

Furthermore, if the VPN has the same password as SSH, then for most intents SSH does not perform any extra authentication. Therefore SSH with key authentication represents an extra layer of security in this scenario (regardless of whether the key is well-protected), whereas SSH with the same password does not. If the alternative is having the password get you through the back door as well as the front door, having the backdoor protected by a different mechanism is a plus.

  • Good point on the merit of a key when VPN and ssh share a password. I hadnt looked at it that way. I really like this answer along with AndrewRussell's. Will think on it and decide which I want to be the accepted answer. Thanks
    – phemmer
    Commented Feb 28, 2012 at 15:29
  • Edit: meant to say I like YoavAner's answer. Doh!
    – phemmer
    Commented Feb 28, 2012 at 15:41

Your question revolves around storage of private keys not the ssh authentication mechanism.

So, to the answers:

  1. Yes the ssh private/public key mechanism and protocol seems to be secure.
  2. Yes the private key should be encrypted via a complex passphrase (especially important if stored on the client machine).
  3. This doesn't stop all attacks, just some.
  4. So layered defences are required.
  5. This is not an especially important issue with respect to the other issues that are likely to be ignored in the security architecture (and no I dont work at the same place you do, just extrapolating).

First of all, SSH keys are categorically better than ssh passwords:

  • You can't reasonably brute-force guess an SSH key. With passwords, you can get a lucky hit by guessing "changeme" or "12345" or "nicole". Keys, on the other hand, consist of 2048 pseudo-random bits. It's not even worth even trying.

  • SSH keys use asymmetric cryptography to prevent the disclosure of any secrets. If you connect using password auth to a malicious SSH server, you will disclose to them your username and password, which they could use for all sorts of attacks. Perpetrating an attack against someone who uses key-based authentication is much more difficult. (I'm not even sure it's possible; are there any examples of this?)

  • SSH keys access can be revoked or extended on a per-user basis rather than a per-account basis.

  • SSH keys can be used to implement additional security or restrictions on a per-user basis beyond what is available via passwords.

  • You can use the same key to access multiple servers with no significant reduction in security.

  • SSH keys allow you to do really cool stuff like agent forwarding, which is absolutely the coolest thing ever (don't grumble at me about hostile-server security implications; it's awesome. La-la-la-la not listening).

With respect to encrypted or unencrypted client keys; that's a matter of personal taste and policy. If there is zero chance of your private key ever leaking, then unencrypted is fine. But really, with key agents, there's no reason not to encrypt it, and the added security is welcome.

Finally, and this is probably salient here, SSH with key-based authentication is more secure than most VPN systems, specifically because popular VPNs generally use password-based authentication and have no built-in protection against man-in-the-middle attacks. Note: some VPNs used key-based two-way authentication. Those are at least as safe as SSH.

So the fact that you're possibly using better security inside the VPN than you use to construct the VPN itself is subtly ironic. And your defense of key-based authentication based on the safety of the enclosing VPN is even more so.

Much of the above is geared around the idea of using ssh keys for interactive sessions rather than for automated systems such as scheduled backups, etc. But the comparison against other technologies still stands regardless. Any reduction in security with a hands-off (passwordless) system with respect to key safety applies just as much to storing your VPN password or key on the system as it does to storing your SSH key unencrypted. Storing credentials is never secure, but a stored SSH key is always more secure than a stored password because of the asymmetric technology and resistance to network-based attack.

You must log in to answer this question.

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