On 12/06/2019 11:56 PM, Aleksandar Lazic wrote: > Looks like every ~2 Years raises someone the question about SNI support in the > openssh client. (ObRant(*): I refuse to call that "SNI".) > It looks like that the OpenSSH community don't like to implement such a feature That doesn't surprise me. When you look at an SSH connection with a packet sniffer, you'll see that the first data going through the TCP connection comes from the server (or, in your scenario, the "backend"), and effectively contains identifying information on it. That would need to be changed so as to allow the client to "dial" the desired backend first - in other words, the two sides are not even speaking the SSH(2) protocol anymore. *Definitely* rather low on the OpenSSH developers' priorities list. > Maybe there is a possibility to use the ProxyCommand for a solution? Sure. Make the frontend a HTTP proxy with support for the CONNECT command (say, squid - and be *real* careful when configuring the auth) and you can use the likes of corkscrew for a ProxyCommand. Or install a SOCKS proxy for a frontend (same caveat, and, e.g., using nc/netcat as ProxyCommand). Or allow users to ssh (sans a shell, if you insist) into the frontend so that they can use OpenSSH's "-D" option to run their own SOCKS proxy to connect to the backend through. Moving the extra functionality into an outer tunnel / proxying solution, rather than shoehorning it into "the SSH protocol" itself, IMHO is *the* way to go here. Note that it also circumvents the problem of ssh having to learn/store/verify all the *backends'* host pubkeys with only the *frontend's* IP+port to use as their identifier in the currentl KnownHostsFile format (assuming that the "number dialed" may *not* be IP+port based, or difficult to inject into the existing KnownHostsFile-handling code). (*) "SNI" is the established name for one *specific* solution of the general "client connects and *then* selects from several available but different backends" feature, namely, the one integrated into SSL *and* interacting with the verification of the server's/backends' X.509 certificate. If anything, the patch proposals you referred to rather resemble the "Host:" header introduced into HTTP with protocol version 1.1, to implement name-based web servers in *pre*-SSL times ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev