client to support SNI

[Jochen Bern]

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