On 25/05/15 21.16, Darren Tucker wrote:
> On Mon, May 25, 2015 at 5:39 PM, Kasper Dupont <
> kasperd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> [...]
>
> > I'll try to explain my usage scenario in a bit more detail.
> > I have a number of servers each running IPv6 only. Since
> > some clients will only have access to IPv4, I have deployed
> > a proxy on a dual stack host. But the proxy only has a
> > single IPv4 address.
>
>
> Assuming you have sufficient CPU and an account on the dual stack host (but
> it could be a single restricted one), we already have a pretty functional
> SSH proxy: ssh "netcat mode".
I don't know if CPU usage is going to be an issue for me.
Given an approach where CPU usage was the only known issue,
I would surely give it a try.
>
> It takes a little bit of client side configuration, but basically it looks
> like this in ~/.ssh/config
>
> Host v6host1 v6host2 v6host3
> ProxyCommand ssh -W %h:%p dualstackhost
I know of this approach and occasionally use it in other
scenarios, but I don't think it could address all of the
needs my proxy would have.
First of all, the proxy is only supposed to be used as
fallback when the client does not have IPv6 connectivity.
The client might move between different networks, and when
it is on a network with IPv6 connectivity, I want it to
connect directly to the target.
The ProxyCommand approach works great when there is a
desire to not put the target host directly on a publicly
reachable IP address for security reasons. That is however
not the scenario I am trying to address. The scenario I am
trying to address is when the only reason for not having
the target on a public address is shortage of IPv4
addresses.
A ProxyCommand which attempts direct IPv6 connectivity and
then falls back to a proxy if direct access didn't work is
surely an option. There is however a few other concerns
which apply to my specific usage scenario.
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.
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.
--
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);
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
