Difference between VPN and SSH? [closed]
What is the difference between connecting to a remote system via SSH and connecting to a remote network via VPN?
For instance, if I can connect to a remote machine on another network via SSH, why the need for VPN?
Solution 1:
A VPN (Virtual Private Network) creates a new network level connection on your machine. Typically this is done for privacy/encryption reasons. All network traffic on that machine will now use the VPN instead of a raw/plain network connection.
SSH (Secure Shell) is simply a way to remotely connect to a terminal/command line on another machine. So if you are using a VPN for the network connection, that alone won’t connect you to a remote machine; SSH is the protocol/method used to connect you to the other machine.
Now with that said, I think I understand your question a bit more: Why would one need to explicitly use SSH when using a VPN since the VPN would imply privacy/security. I mean if you are 100% trusting of your VPN connection, you could simply use non-secure Telnet or even plain FTP, right?
Well, the thing is using SSH and a VPN in combination assures a deeper level of security. Meaning, even if the VPN is compromised, then an attacker/prober would still need to penetrate the SSH connection to get anything of value.
Another aspect is not all VPNs are built for deep privacy/security. Some VPNs are simply private routes to other networks which other users are accessing as well. And in that case, a VPN would be no different than a LAN (Local Area Network) where VPN peer connections would have somewhat equal access to other VPN peer connections.
It all boils down to purpose, privacy and trustworthiness. If you are 100% positive you trust your VPN and don’t feel it poses a risk to data leakage, do whatever you want on it without the need for the extra layer of security SSH provides. But generally, it’s better to be proactively safe than reactively sorry. Using SSH even within a secure VPN is the way to go. Not to mention, SSH is so common nowadays there’s little reason not to use it. Heck, people tend to forget about the non-SSH days of Telnet.
Solution 2:
VPNs typically work by creating a virtual network adapter on your system. Traffic going to this virtual network adapter is intercepted by the VPN software, which encrypts and otherwise processes it, then is sent to a VPN server endpoint where it may be further forwarded, such as by an interior enterprise router. To the application a VPN is no different than a standard network adapter.
SSH forwarding is your SSH client listening on a port on 127.0.0.1, then forwarding data that comes into that local port to a port on the server, using the same encryption method as your shell does. If there is nothing listening on the remote server's port, nothing happens.
Here's at least some significant differences:
SSH can only forward a single port (well, it can forward multiple ports, but you must specify them all). That means if you want to securely access multiple services on a remote host, each running on a unique port, you have to setup and maintain forwards for each service.
Your typical SSH clients do not support specifying multiple servers to connect to, trying the first one that works. This type of thing is built into OpenVPN, for example.
SSH does not support tunnelling UDP by itself.
Since VPNs look like a network adapter to the operating system, routes involving the VPN adapter can be specified. Thus, the OS can send any traffic destined to a subnet through the VPN adapter. This can do things like make all your Internet traffic go through the VPN, for filtering or privacy. SSH cannot do this easily.
Layer-2 VPNs can work with broadcast traffic, allowing things like DHCP, multicast, ICMP, and Windows SMB-related traffic to work through them.