Is it possible to choose the underlying ssh server based on the username?

[kuolemaaa]

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

[ftasnetamot]

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, ...
But you read the ssh documentation, the RFCs 4250-4256 are the most important.
Maybe, there is a way, that the username can be transmitted in clear.

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.

[kuolemaaa]

My "problem" is that I want to connect to different ssh servers that runs on a single machine and this machine is behind a NAT, behind a single public port. My idea was to expose and "multiplex" a single port and differentiate these ssh servers by usernames.

For example:
ssh -p 9922 user@myhostname.com -> to reach my main machine that exposes its ssh server to port 16565
ssh -p 9922 git@myhostname.com -> to reach my git instance that actually is locally accessible from port 23568
ssh -p 9922 anything@myhostname.com -> to get, i dont know, another service, exposed locally as another port

Having public port 9922 forwarded to an entity (asking for sslh) that let me connect to the correct internal ssh server reading the username.

Does it make any sense?

[ftasnetamot]

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.
You can have multiple destinations defined in your local .ssh/config and do a SNI based mapping.

[psychowood]

I recently had a discussion on this and looked for alternatives, and I want to share my 2cents (referring #89 too).

Main requirement was using a standard ssh client, small impact on sslh (no decryption), and no additional software on the server, so I investigated a bit on which parts of the ssh protocol could be set client-side and intercepted by sslh before forwarding to the ssh server.

Long story short, since OpenSSH v7.9 (2018) the client has an option called VersionAddendum that appends arbitrary text to the openssh client version string that is sent to the server before encryption.

So configuring the client as follows

# ~/.ssh/config
Host server1
    Hostname mux.mydomain.com
    Port 443
    VersionAddendum [target=server1]

or directly running

$ ssh -o 'VersionAddendum=[target=server1]' -p 443 mux.mydomain.com

sends the server a client string similar to this:

SSH-2.0-OpenSSH_10.0 [target=server1]

Sslh could intercept and forward to server1, where server1 is either the direct hostname of the server overriding the default (supposedly insecure for obvious reasons) or with specific configuration keys like sni_hostname

# /etc/sslh/sslh.cfg
protocols:
(
    {
        name: "ssh";
        host: "localhost";
        port: "22";  # Default SSH backend
        
        # VersionAddendum hostname routing (like SNI for TLS)
        versionaddendum_hostnames:
        (
            {
                hostname: "server1";
                protocol: { name: "ssh"; host: "192.168.1.10"; port: "22"; }
            },
            {
                hostname: "server2";
                protocol: { name: "ssh"; host: "192.168.1.20"; port: "22"; }
            },
            {
                hostname: "dev-server";
                protocol: { name: "ssh"; host: "192.168.1.30"; port: "2222"; }
            },
            {
                hostname: "*.production";  # Wildcard support
                protocol: { name: "ssh"; host: "192.168.2.10"; port: "22"; }
            },
            {
                hostname: "bastion";
                protocol: { name: "ssh"; host: "10.0.0.5"; port: "22"; }
            }
        );
    },
    {
        name: "tls";
        host: "localhost";
        port: "443";
        
        sni_hostnames:  # Your existing TLS SNI config
        (
            { hostname: "example.com"; protocol: "local"; }
        );
    }
);

If you believe this could be useful I can try to prepare a PR.