In kinda the same situation, I was using username for host routing. And real user was determined by the principal in SSH certificate - so the proxy didn't even need to know the concrete certificates for users; it was even easier than keeping track of user SSH keys.

Certificate signing was done by a separate SSH service, which you connected too with enabled SSH agent forwarding, pass 2FA challenge, and get a signed cert injected into your agent.

▲

unsnap_biceps 4 hours ago | parent [-]

Can you expand on your solution a little bit? AFAIK principals don't impact the user that is logged in at all. A principal in the cert and in the authorized list just allows the user to log in as any user they want, which is why you have to write a script that validates the username before listing principals to accept.

I'd love to learn more about how you solved it and what I may be mistaken about.

	▲	binarin 4 hours ago \| parent [-]
		What I had is roughly the following: users connects via SFTP to external.website.com@my.proxy.com. Proxy server (which handles SSH protocol itself) authenticates the user using the principal, then checks whether this principal is allowed to access an external web-site and what exactly it can do here. Then proxy connects to the external website using its own secret credentials. In the end, it solved the problem of having a shared google doc with a bunch of passwords in there which everyone had access to.