Why use SSH and VPN in combination?

Question

My employer requires me to first log on to a VPN, and only then I can SSH into the servers. But, given the security of SSH, is a VPN overkill?

What is the use of a VPN in terms of security if I am already using SSH?

Answer 1

The reasoning behind your current setup is probably some combination of the following three reasons.

The VPN is a security solution for outside your company's network (See #1 below). SSH however, might be a second layer of security outside of your company's network... but its main purpose is to secure the traffic within your company's network (See #2 Below). VPN is also necessary if the device you are trying to SSH into is using a private address on your companies network (See #3 below).

1. VPN creates the tunnel to your company network that you push data through. Thus no one seeing the traffic between you and your company's network can actually see what you're sending. All they see is the tunnel. This prevents people that are outside the company network from intercepting your traffic in a way that is useful.

2. SSH is an encrypted way of connecting to devices on your network (as opposed to Telnet, which is clear text). Companies often require SSH connections even on a company network for security sake. If I have installed malware on a network device and you telnet into that device (even if you're coming through a VPN tunnel - as the VPN tunnel usually terminates at the perimeter of a company's network), I can see your username and password. If it's SSH you're using, then I cannot.

3. If your company is using private addressing for the internal network, then the device you are connecting to may not be rout-able over the internet. Connecting via a VPN tunnel would be like you are directly connected in the office, therefore you would use the internal routing of the company network that would not be reachable outside of the company network.

Answer 2

SSH is an extremely popular target for brute-forcing attempts. If you have an SSH server directly on the Internet, within minutes, you will see login attempts with all kinds of user names (and passwords) - often thousands per day even on small insignificant servers.

Now it is possible to harden SSH servers (the main three mechanisms are requiring an SSH key, denying root access to SSH, and if possible restricting the IP addresses that are even allowed to connect). Still, the best way of hardening an SSH server is to not even have it available on the Internet at all.

Why does it matter? After all, SSH is fundamentally secure, right? Well, yes, but it is only as secure as users make it - and your employer may well be concerned about weak passwords, and SSH keys being stolen.

Adding a VPN adds an extra layer of defense that is controlled at the corporate level, instead of at the individual-server level as SSH is.

All in all, I would commend your employer on implementing some good security practices here. At the expense of convenience, of course (security usually comes at the expense of convenience).

Answer 3

The VPN allows you to connect to your employer's private network and acquire an IP address of that private network. Once you're connected to the VPN, it's like you are using one of the computers inside the company -- even if you are physically located on the other side of the world.

Most probably, your employer requires you to connect via VPN first because the servers are not accessible from the Internet (i.e. they haven't a public IP address), which is a good idea. The VPN adds another layer of security, as if the servers were publicly accessible via SSH they would be vulnerable to a range of attacks.

Answer 4

SSH is an encryption protocol used for several things. Encrypting traffic in a VPN tunnel is one of them. Your traffic is encrypted using SSH, but it then needs to be wrapped in valid IP packets (tunnel) to traverse a network like the Internet. This tunnel is the VPN.

Basically, your employer blocks outside network traffic, for security, unless that traffic comes through a VPN which the employer controls. A VPN may or may not encrypt the contents of the tunnel. Using SSH will encrypt the traffic carried in the VPN tunnel.

Answer 5

You need the VPN to get into the local network.

You don't then need to secure your connection to individual servers, as it'll already be encrypted by the VPN link.

However, how else would you connect to them? SSH is the de facto console access protocol for remote servers; installing and configuring an unsecure one would be an additional management overhead, and decrease security within the local network (which may or may not be a problem).

Don't forget, not everybody even within the company will have total access to every server, and the ability to use key-based encryption even within the local network allows your network administrator to easily and securely ensure that only people who ostensibly know what they are doing, even within the company, are allowed to touch the server.

Answer 6

You can drive additional layers of security through the VPN as well. Such as device criteria checks, 2 factor authentication, etc.

Answer 7

Typical reasoning is that you want to reduce the exposure and possible attack vectors as far as possible.

If you begin from the premise that both SSH and VPN are required (for their own purposes), then have both externally facing means that attackers have two potential routes into your environment. If you make SSH local-only it adds an additional layer to the security of the server. Consider the following scenarios:

1. SSH + VPN externally. Attacker needs only compromise SSH to compromise the server.

2. SSH external. Functionally the same as the previous scenario.

3. VPN external (SSH internal). Doubles up on security. Attacker must break through both before they can do anything to the server.

Consider that alongside the fact that VPN would be nessecary for other functions, and may be better configured for external access and it's a no-brainer.

Answer 8

I would hazard that the answer is simply that NAT is involved and (as many others have stated) exposing the ultimate target server to the world invites another attack point. Unless you are doing heavy bulk data transfers with large keys, SSH doesn't generally get in the way. The bottleneck will almost always be the network. (Almost != Always).

If you are 'lucky' enough to have IPv6 this is not likely to be as much of an issue, but with IPv4 and the limited address space available NAT is (IMO) ultimately what I think is behind this 'policy' more than any other 'accidental' or 'purposeful' security.

Answer 9

From my current understanding, SSH - because it simply uses a tcp key exchange to verify that a client user has the correct credentials to access the user ID in the server, is susceptible to man in the middle attacks where a ISP, or compromised router could intercept the handshake request and act as the one sending authentication, in effect hijacking the connection. This allows commands to be injected into the stream and then the output filtered out before it reaches the initial authentic client, thus hiding the man in the middle injection of arbitrary commands into the server ssh shell.

However by a VPN tunnel allows something that ssh does not. An additional pre-agreed symetric encryption key. This means that traffic between the two machines is not susceptible to a man in the middle attack because the traffic, if intercepted and forwarded on behalf of the authentic client in order to control the ssl encryption layer would not be able to pass the vpn encryption key requirements because the third party would not have the ability to spoof the vpn keys the same way that they would be able to control a middle man forwarding of ssh tcp ssl connection.

So, ssh is not good enough to stop man in the middle from an ISP or compromised router that a client is required to go through in order to connect to the server.