[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!