Replies: 2 comments 1 reply
-
I am almost sure, that sslh can't do that. In opposition to an tls-SNI name, which is sent unencrypted as part of the opening mechanism, the ssh username is first sent, after the server offered its key, and the client already sends data -encrypted with this key- back to the server. in this connection the client sends the username along with the wished authentication method and information, like password, key, ... If there is a possibility, that the username could be extracted in the first packets of the connection, there is a possibility to configure that. However, I don't see currently the benefit. If I wish to connect to different services, and I am using for this different users, why not using different destination names? If you describe, why exactly you need this, there could be alternatives. |
Beta Was this translation helpful? Give feedback.
-
You can have a look at the second part of this document. Its a little overhead, as you need to use a proxy-command and need a frontend nginx, but that could work. |
Beta Was this translation helpful? Give feedback.
-
Something like a SSH "reverse proxy" based on username instead of the domain name.
if the client connect to user@ it will be connected to the ssh server of the host
and if the client connects to git@ it will be connected to another ssh server maybe on a container running on the same host; with sslh listening on port 22 and the other servers listening on other ports
Beta Was this translation helpful? Give feedback.
All reactions