3 ms·

Sorry this will come off as a super dumb question. I use ssh. I can login, edit, develop, run, basically anything. What am I missing? I thought VPNs are for

Sorry this will come off as a super dumb question. I use ssh. I can login, edit, develop, run, basically anything. What am I missing? I thought VPNs are for 'admin' types that need access to a MS Excel file.

justabystander 9y ago
The VPN changes your network route. This can get you around geographic locks (services that only work in certain areas). It can also get you around traffic issues, if your ISP has technical/political routing issues. Like with Comcast/Verizon refusing to add additional peering because they wanted to double-bill netflix traffic. Some VPN services also advertise additional privacy or anonymity, but trusting a stranger to not sell you out to their local government isn't usually a good idea. From a business standpoint, you may want web and network services without exposing them to the wider internet. So they're only accessible on IPs in local subnets. VPNs will get you inside the wall.
- deleted 9y ago
  [deleted]
rsync 9y ago
"I use ssh. I can login, edit, develop, run, basically anything. What am I missing?" You're not missing anything and you have an extremely efficient and secure workflow that runs laps around any of this. The tradeoff is you work in a terminal and understand SSH, etc., which is too much to ask of many non-technical users. If you wanted to obfuscate your traffic or the direct path to your remote host was blocked for some reason, a VPN might get you there, but you'd still run SSH over that VPN and your workflow should remain unaltered (albeit, higher latency). To address a sibling posts comment, you can enjoy this very same workflow without exposing your sshd to the global Internet by placing it behind a "knock" with knockd. Highly recommended.
gerdesj 9y ago
ssh can be used as a VPN - you can proxy ports and tunnel all sorts of things through it. You can easily drill a connection through to say an "internal" Windows or NFS file server and grab docs off it. There is file transfer built in as well eg sftp and scp, with easy rsync integration. It doesn't really matter whether you use ssh, RDP or whatever for remote system access but you should be aware of the capabilities of your methods and the strengths and weaknesses of them. If your username and password are reasonably hard to guess, and ideally you use passwordless logins, and you keep your system regularly patched, and you definitely don't allow remote root logins, and you cycle your passwords say 90 days or so, then you should be fine. Do not bother changing port 22 to say 2222 or requiring 20+ char passwords. You may want to disable some of sshd's functionality if you don't use it but that might be a step too far. Also, reset your sshd's keys occasionally and get them into your local ~/.ssh/known_hosts as soon as possible and read up and understand why ssh warns you when the keys and names look odd - that could save you a MitM attack from a bored techy in a hotel with wifi or whatever. To sum up: a well handled sshd and client can be a fairly decent VPN and remote access solution. However, a separate VPN eg OpenVPN and then ssh over that is better and need not be inconvenient. You pays your money .... 8)
brandon 9y ago
Google's model allows SSH to "internal machines" over a set of relays that apply the same machine authentication and trust tier logic that's laid out in the papers. So your workflow would still be supported, and it would likely be more secure than exposing SSH traffic to the internet at large.

justabystander 9y ago

The VPN changes your network route. This can get you around geographic locks (services that only work in certain areas). It can also get you around traffic issues, if your ISP has technical/political routing issues. Like with Comcast/Verizon refusing to add additional peering because they wanted to double-bill netflix traffic. Some VPN services also advertise additional privacy or anonymity, but trusting a stranger to not sell you out to their local government isn't usually a good idea. From a business standpoint, you may want web and network services without exposing them to the wider internet. So they're only accessible on IPs in local subnets. VPNs will get you inside the wall.

deleted 9y ago
[deleted]

rsync 9y ago

"I use ssh. I can login, edit, develop, run, basically anything. What am I missing?" You're not missing anything and you have an extremely efficient and secure workflow that runs laps around any of this. The tradeoff is you work in a terminal and understand SSH, etc., which is too much to ask of many non-technical users. If you wanted to obfuscate your traffic or the direct path to your remote host was blocked for some reason, a VPN might get you there, but you'd still run SSH over that VPN and your workflow should remain unaltered (albeit, higher latency). To address a sibling posts comment, you can enjoy this very same workflow without exposing your sshd to the global Internet by placing it behind a "knock" with knockd. Highly recommended.

gerdesj 9y ago

ssh can be used as a VPN - you can proxy ports and tunnel all sorts of things through it. You can easily drill a connection through to say an "internal" Windows or NFS file server and grab docs off it. There is file transfer built in as well eg sftp and scp, with easy rsync integration. It doesn't really matter whether you use ssh, RDP or whatever for remote system access but you should be aware of the capabilities of your methods and the strengths and weaknesses of them. If your username and password are reasonably hard to guess, and ideally you use passwordless logins, and you keep your system regularly patched, and you definitely don't allow remote root logins, and you cycle your passwords say 90 days or so, then you should be fine. Do not bother changing port 22 to say 2222 or requiring 20+ char passwords. You may want to disable some of sshd's functionality if you don't use it but that might be a step too far. Also, reset your sshd's keys occasionally and get them into your local ~/.ssh/known_hosts as soon as possible and read up and understand why ssh warns you when the keys and names look odd - that could save you a MitM attack from a bored techy in a hotel with wifi or whatever. To sum up: a well handled sshd and client can be a fairly decent VPN and remote access solution. However, a separate VPN eg OpenVPN and then ssh over that is better and need not be inconvenient. You pays your money .... 8)

brandon 9y ago

Google's model allows SSH to "internal machines" over a set of relays that apply the same machine authentication and trust tier logic that's laid out in the papers. So your workflow would still be supported, and it would likely be more secure than exposing SSH traffic to the internet at large.