Name based SSH proxy

Ángel González keisial at gmail.com
Wed May 27 09:42:55 AEST 2015


On 26/05/15 23:42, Kasper Dupont wrote:
>> >  I think the ProxyCommand Kasper ended up describing (checking for v6
>> >  connectivity or using a constrained HTTP CONNECT proxy) is a acceptable
>> >  way to go for people in the particular scenario he's concerned about.
> But it does not address all my requirements. I have a
> requirement that the hostname being used must be visible
> to the administrator of the SSH server. And it must be
> visible with minimal effort without requiring any software
> changes on the server.
>
> Sending the hostname in clear from proxy to server would
> address that concern.
>
> But there are not many opportunities for a proxy to inject
> data into the data stream from client to server without
> breaking integrity checks on the packets.
Why do you want the hostname being used to "be visible to the administrator
of the SSH server"?

I assumed you wanted to send the final hostname to the *proxying SSH 
server*.
In which case, you don't need such thing if using a HTTP CONNECT proxy (the
hostname is now given to the HTTP proxy). And if you use a ssh server 
like the ssh
tunneling I proposed, the final hostname is already provided, too.

If you want instead to give the hostname used to the *final* sshd, 
that's a different
requirement for which you provided no rationale (and I suspect you are 
not really
interested in).


Much more interesting at the final end than the requested would be to 
have the
original client IP (ie. X-Forwarded-For) but that would open a different 
can of worms
(and required software changes) about proxies whose forwarded IPs should 
be trusted.
Something I would prefer not to enter into.


A similar idea I had thought in the past was the ability to 
transparently forward a
connection after authentication to a different machine (after the 
PrivSep step, the
new sshd would be in a different host in the LAN). It differs from 
Kasper proxy in that
the proxy would be trusted (seen as the real machine from the outside).



More information about the openssh-unix-dev mailing list