can ssh passwordless public key authentication be ok if combined with a VPN?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Note:
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.