[alexk]

> yeah this is a bad idea in general. If you have critical stuff you need to SSH into from the public internet, keep it all in private IP space and have an openvpn gateway

This is not a bad idea in general. In fact, teleport proxy implements this exact model you have just described, where only proxy is available and acts as a jump host to the set of machines available only on the private net. The only difference is that instead of open VPN gateway it uses SSH jumphost model.

Teleport proxy uses OpenSSH cert auth, in addition to that teleport node also does cert auth.

Not everyone needs to always set up VPN, sometimes jumphosts + cert auth are perfectly fine.

[walrus01]

I encourage all of my competition to allow access to relay to critical internal things with only SSH based authentication on a bastion/proxy, and nothing else.

[anon263626]

Critical infrastructure demands solid, understandable security (ie defense-in-depend). Throwing around shiny, new, unprovens things to "give the emperor new clothes" increases risks for major security breaches.

Plus, this commercial thing doesn't do anything pam ldap and config mgmt can't do. Just reinventing the wheel yet again to charge people money for proprietary "solutions."

[alexk]

This is not how SSH jumphosts and Teleport Proxy work. With jumphost ssh client goes through the authentication and authorization twice:

* first when connecting to the jumphost public ip and requesting to execute a subsystem to allow proxying to some internal IP/host

Jumphost does not terminate the SSH and in fact it is MITM capabilities are very limited.

* Second time authentication and authorization happens when ssh client connects to the target SSH node.

This pattern is in fact quite modern and is being expanded in the beyond corp architecture.

https://research.google.com/pubs/pub43231.html

It deprecates perimeter security model that you mention via VPN gateways and replaces it with on-demand end to end access via controlling gateway.

[throw049483498]

Yeah but the security model it implements is vulnerable to any new remote code execution that pops up for OpenSSH.

With the VPN as your boundary, you can configure it so the VPN doesn't even respond to packets unless they are TLS authenticated. A huge security win, you're not exposed to random attempts to do remote code execution against your open sockets!