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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
