I want to do delegate pubkey-based authentication for a given user to a different SSH server, without modifying client configuration but allowing modifications to server software.
There are several similar questions already. This and this ask for dispatch based on host name instead of user name. This and this try to dispatch by user name, but they only have answers where the first ssh session causes the invocation of a second ssh command, so this will only use public keys at the final destination if agent forwarding is enabled. This question here is more specific in how to possibly achieve the stated goal.
Layers
I've read RFC 4251 section 1. According to that, there are three layes in the SSH stack. The TRANS (transport) layer provides integrity and server authentication. The USERAUTH (user authentication) layer does user authentication, and the CONNECT (connection) layer multiplexes actual payload data. So I'd want a man in the middle interception at the TRANS layer, while forwarding the USERAUTH and CONNECT layers.
client proxy server
CONNECT X-----------X
USERAUTH X-----------X
TRANS X---X X---X
TCP X---X X---X
As the TRANS layer does server authentication, the client would obviously see the public key of the proxy, which is acceptable in my application. According to RFC 4252 section 1, the USERAUTH layer does receive a session identifier form the TRANS layer. Which means that the actual server would likely need some added feature so it could use the session identifier negotiated between client and proxy, instead of the one it negotiated itself with the proxy.
Can this be done?
Is there any known implementation of such a scheme?
Or is there something I overlooked, some reason why this can't work even if one has control over the software running on both the proxy and the sever?
Application
Various services come as ready-to-use Docker images which provide git over ssh access to their data, one way or another. Usually all access is done using a single account, using public keys to actually distinguish users. So passing the public key is vital.
It is possible to expose these services using different ports. But using privileged ports for services other than the registered ones might be seen as bad style, using unprivileged port as a security risk, and on the whole user names are much more memorable than port numbers. Furthermore, a user name is required anyway, even if it's just git. Not requiring a non-standard port number allows using the shorter ‹user›@‹host›:‹path› notation of git repositories, as opposed to the more lengthy ssh://‹user›@‹host›:‹port›/‹path›.
I doubt any common Docker images currently make use of something like this. But if it were possible, then one could suggest adding the required server changes to these images, so that approaches like this become viable in the future.
