Name based SSH proxy

[Kasper Dupont]

On 27/05/15 22.42, Ángel González wrote:
> On 27/05/15 09:40, Kasper Dupont wrote:
> >On 27/05/15 01.42, Ángel González wrote:
> >>Why do you want the hostname being used to "be visible to the 
> >>administrator
> >>of the SSH server"?
> >In case the AAAA record used by the proxy to find the
> >server for some reason points to the wrong IP address,
> >I want to ensure that the administrator of the [target] server
> >has the opportunity to see the DNS record causing
> >connections to end up on their server. That's only
> >possible if the hostname is sent to the server somehow.
> Well, John Doe connecting through your proxy to 192.168.1.1

My proxy only connects to IPv6 backends, but let's not dwell
too much on that detail.

> because foo.example.org is pointing there instead of 192.168.111.111
> is no different from John Doe doing exactly that with a different 
> connection.
> 
> If the dns record is wrong, there's little 192.168.1.1 can do

I'd say that depends on the circumstances. I certainly think
the administrator of the target host is in a better position
to do something if he knows about the DNS record than if he
doesn't.

> 
> 
> >>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.
> >Communicating the hostname to the proxy is probably going
> >to be the easy part.
> Indeed, that's trivial.
> 
> >The tricky part is to make it visible to the administrator of the target 
> >server.
> Yes. ssh protocol is quite guarded against alterations from the outside.

One week ago I thought any change whatsoever that an
intermediate host would make to the stream of bytes between
SSH client and SSH server would be detected and cause the
SSH connection to be terminated.

But I have since learned, that it is not that picky. Not
every byte exchanged during the key exchange is subject to
integrity check.

Changing any of the bytes fed into the key derivation
algorithm is obviously going to break the connection when
the first MAC is validated with a mismatching key.

Changing the number of messages send during the key exchange
is also going to break the connection because the first MAC
validation would fail due to the message sequence number
mismatching between client and server.

But any other modification of the bytes transfered during
key exchange will go unnoticed.

> 
> Would you consider acceptable for the proxy to send an udp packet to the 
> target server
> (eg. udp 514) informing it of the requested hostname it's forwarding?

That's not a bad idea. It's an idea I hadn't thought about
before, but now I will. I'll have to think about what
advantages and disadvantages there are to this idea. So far
I can see some advantages in your proposal compared to the
ideas I have otherwise considered.

Do you by any chance know if there is an RFC documenting the
format of the packets?

-- 
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);