Name based SSH proxy

[Ángel González]

On 25/05/15 14:51, Kasper Dupont wrote:
> The proxy I am operating will be publicly accessible, and
> due to that I have a few additional requirements:
>
> 1. The proxy have to guarantee that the hostname being
>     used will be easily visible to the administrator of
>     the server which the backend eventually connects to.
> 2. The proxy doesn't trust the users. Hence the users
>     don't have an SSH login on the proxy.
> 3. The users don't trust the proxy anymore than they would
>     trust a random router which the SSH connection got
>     routed through.
>
> Point 3 might not really be a problem. Having the users
> store a host key for the proxy doesn't itself pose any
> problems. Point 2 I could probably work around with
> sufficient sandboxing.
>
> But point 1 on my list appears seems to be a bit of a
> blocker. Any approach used by the proxy to embed the
> hostname into the TCP connection would mean a change of
> data that is subject to integrity check between client
> and server. So I am at loss as to how the proxy could
> communicate the hostname to the server.
I think you can achieve all of this with no changes to ssh(d)
software (but a bit of trickery).


Then ~/.ssh/config would contain

Host v6host1 v6host2 v6host3
  ProxyCommand ssh -W %h:%p -p %p -o UserKnownHostsFile=~/.ssh/known_hosts,~/.ssh/known_proxy %h.example.com

(note that simply a %h in the ProxyCommand would lead to a loop)

and set in vhostN dns both its IPv6 and dualstackhost IP address.

You add in the normal ~/.ssh/known_hosts the normal entry for v6hostX
with its real key, and in ~/.ssh/known_proxy another entry for v6hostX
with the public key for dualstackhost.

If there's IPv6 connectivity, you connect directly to the final machine,
with a redundant tunneling through localhost.

With no IPv6 connectivity, the IPv4 address is used, so you connect
to the proxy. As there is an alias for the proxy public key is listed inside
known_proxy, the tunneling connection is allowed. However, the outer
ssh invocation is not loading known_proxy and won't accept such key
(thus the proxy can't impersonate the hosts).

Your users require a login into the proxy server, but not necessarily the
ability to run processes, just the ability of performing port forwardings
(you can restrict with permitopen= the list of hosts to which they are
allowed to open a connection).

For your specific use case, you may wish to use a well-known user
in the ProxyCommand (ie. all users connect to the proxy with the same login
with a published secret key).


> Also. There is nothing in the requirements for my usage
> scenario, which would benefit from the communication
> between client and proxy to be embedded in another layer
> of SSH. And since it would require configuration changes
> on the client anyway, I would most likely replace that
> part with something with less overhead such as possibly
> using an HTTP proxy supporting a restricted version of the
> CONNECT command.
Sure. There's no special need for protecting the communication
between the client and the proxy in your case.
You could perfectly use a custom ProxyCommand that tunnels
through HTTP CONNECT if there's no IPv6 connectivity.