For the author there is a little typo in the article. It says "This is problematic for three reasons", while listing two reasons.

The last section talks about choosing proxies over jumphosts, without mentioning what would be necessary to setup such a proxy. I would be really interested in a more indepth explanation of how such a proxy would work.

The author compares the proxy to a "dumb switch". How do you authenticate users without terminating encryption? And, if you don't authenticate users on the bastion, why bother with a bastion at all?

The proxy does not authenticate users. When a user shows up without a certificate, a proxy simply redirects to an OAuth2 / SAML endpoint such as Github or Google. When OAuth redirect comes back, the proxy forwards user's identity to the certificate authority (usual SSO flow), which issues an SSH certificate which gets sent back to the client.

Now, "armed" with a certificate, the client can try again, in which case the proxy simply forwards the request to the destination host, which verifies the certificate. It is the same as having a non-terminating HTTP/TLS proxy/load balancer, just for SSH.

Ah, interesting! Thanks for your response. What do you use to get this work flow going? Would be really interested in the underlying infra. Do you have any pointers to get me deeper in this subject?

Quickstart: https://gravitational.com/teleport/docs/quickstart/

To quickly answer your question: if you rename teleport client "tsh" to "ssh", trying to use it without a certificate will trigger SSO workflow. The alternative is to issue "tsh login" CLI command in the morning.