On top of which, OpenVPN has actually had fewer security vulnerabilities released than OpenSSH, and HMAC validation enormously restricts the surface area of exposed code as compared to OpenSSH.
- Exposes less code to attack
- Can be run on a single machine, distinct from your production systems, where compromise will only result in a compromise of VPN communications, not of an actual production machine on which your production data/processes exist.
[1]: http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...
I expose ssh externally on the edge gateway (but can't provide evidence for sanity). The major attractions over a vpn is a limit in what traffic gets sent on the ssh connection - by default just the shell, and whatever port forwards are needed. vpns end up forwarding DNS traffic and a bunch of other gunk. They can also expose the client machines to unintended traffic from the remote end.
As far as the bastion host, you need an actual VPN to do more than forward SSH connections. For instance, connectivity to your LDAP server, internal web services, etc.
Port forwarding gets you part of the way there, but it's inconvenient to use with SSL, requires using weird local port numbers when connecting to services, etc.
SSH does have VPN support via tun/tap, but it's not nearly as functionally complete as OpenVPN, and you still have the entire SSH authentication path exposed to the world.
That said, both are very good, and if you do want a full VPN there's a lot to recommend OpenVPN.
- OpenVPN takes only minutes to set up
- There are easy to use GUI clients for all major desktops (Windows, Mac OS X, Linux) and phones (Android, iOS)
- It supports running with zero privileges (chroot+setuid) since it only needs to forward packets to /dev/(tun|tap), which does not require privileges after the device has been opened.
- It limits your compromise exposure to only one edge gateway (you can put any number of machines behind a single dedicated gateway). If the gateway is pwned, you still have the defense-in-depth of internal SSH, internal encrypted comms, etc.
- Supports HMAC validation of incoming data to avoid any complex processing (and thus exposure of bugs) of packets from users that don't have the shared HMAC key. This means that only the HMAC code is exposed to untrusted users.
- Supports public key +/ password authentication.
There's no reason to expose SSH to the public internet when you can run a gateway that handles only VPN traffic and greatly limits your attack surface. Defense in depth!