Can't use a ProxyCommand-based SSH connection

[inducer]

The NAT/firewall-busting problems of issue #48 notwithstanding, mosh also has issues with the "ProxyCommand" style of connecting to machines behind NATs. For specificity, here's an example from my .ssh/config:

Host cims
  HostName linax1.cims.nyu.edu
Host mauler
  User kloeckner
  ProxyCommand ssh cims nc mauler 22

This is convenient, because it lets me type ssh mauler, and ssh will connect to linax1.cims.nyu.edu, and the 'outer' ssh run will then run over the tunnel thus set up. I understand this is hard for mosh to imitate, given UDP connections and what not, so let's assume that there's a hole poked into the firewall at port 60000 UDP on linax1.cims.nyu.edu that lets me get to mauler.

The main problem then is that mosh tries to resolve mauler locally to find the host to connect to, which of course doesn't succeed. I'd argue that it could potentially be smarter about finding the public IP of the target host--when it starts, it is executing codes on both ends of the connection after all. Failing that, I'd like to hhave an option to specify which host is actually meant.

[keithw]

You're right that you can't use a ProxyCommand, but the reason is even simpler. Mosh doesn't try to resolve your hostnames -- it lets SSH do that. You can have a host alias in your SSH configuration and that will work fine. However, mosh itself uses the ProxyCommand feature (because it needs to know the IP address it's connecting to, in case there are multiple A records).

If you can find a way to start up the mosh-server on the remote end, and you can give the mosh-client an IP address to connect to, that's really all you need.

[jonesmz]

My use case is far more complex than inducer's, but if mosh supported ProxyCommand, it would make mosh a drop in solution.

Here's a snippet of my ssh config

host home
ProxyCommand connect -H proxy:3128 %h 443

host home-desktop
ProxyCommand ssh -q home nc %h %p -w 30 2> /dev/null

As you can see, I'm using ssh over a https proxy to form a tunnel to my home gateway, and then using that tunnel to connect to my home desktop machine.

The https proxy server that we have at my day job is unbelievably unreliable, disconnecting several times an hour, but it's the only way to punch out of the building.

I use autossh to keep a psuedo-persistent connection open, but still have to deal with my existing session being interrupted.

If mosh could be set up to pass its data through the ssh session used to start it (or a new one created with the same parameters), then mosh would be a viable option for me when at work.

Thanks

[nicolai86]

+1 on this, I'd greatly appreciate ProxyCommand support.

My setup is simpler tho, support for something like this:

 Host foo

 Host bar
   ProxyCommand ssh foo nc %h %p

would be enough for my needs - and make mosh a drop in solution as well.

[jpawlowski]

+1

[tribut]

If you need ProxyCommand to connect a host but it can be reached from the internet via UDP, you could use a script like this. It starts mosh-server on the remote machine (using SSH and the ProxyCommand from .ssh/config), parses the output and then connects using mosh-client to the machine directly.

[grooverdan]

I guess you could use mosh on the hop if that the only place that has access to farside.

host hop
host farside
  ProxyCommand mosh -- hop  -W farsideaddr:22

(-W is sometimes better option than netcat.)

Instead of using ProxyCommand to determine the address mosh could use the LD_PRELOAD environment variable, overwrite/proxy the connect system call method (to the SSH server) and use that resolution result to determine/resume the specific connection of hop.

[andersk]

@grooverdan: mosh cannot be used as a ProxyCommand. That wouldn’t make any sense. The job of a ProxyCommand is passing on the raw, encrypted SSH stream; mosh doesn’t work that way.

You can, however, run mosh hop ssh farside, ssh hop mosh farside, or even mosh hop mosh farside, to use mosh for one or both legs of the connection. This obviously requires that you trust hop with the credentials you use to access farside.

[Daviey]

I make quite heavy use of bastions, where the destination (farside) is not guaranteed to have mosh installed.

$ mosh hop ssh farside , seems to provide the benefits of mosh - but in a generic environment. I wondered if anyone has integrated this into their ssh config, to make the process simpler.

[porterjamesj]

+1 for support of something like this, if its possible. I ssh into a bunch of VMs (farside) unaccessible from the Internet via a login node (hop) which is, but my situation is the opposite of @Daviey's. I have root on the VMs and so I can install mosh there, but I can't install it on the hop. Is there any way to get the benefits of mosh in this situation?

+1 for this, just figured out I can't use mosh from work to my server due to mosh ignoring ProxyCommand from my .ssh/config.

[akalin]

I came up with a potential solution that avoids ProxyCommand, but has its own downsides. There is a LocalCommand directive that causes ssh to execute a command on the localhost when the connection is established, with the same substitution rules (e.g. %h => remote hostname) as ProxyCommand. Of course, any existing LocalCommand directive will be clobbered, but I think that one is less likely to be used.

The downside is that LocalCommand requires the PermitLocalCommand=true option to be set, too, and that one enables local command execution via the !command escape sequence in ssh(1). So this has security implications -- can an exploit on the remote host use mosh-server to run arbitrary commands on the connecting host? I did a quick search, but couldn't find any history on the LocalCommand and PermitLocalCommand options, but it smells like something that was originally permitted by default, but locked down to avoid "surprise" shell execution vectors.

Anyway, my changes to master are master...akalin:avoid-proxy-command , and my changes to the stable version (which I tested and works swimmingly) are mosh-stable...akalin:avoid-proxy-command-stable .

[akalin]

Oh, and I guess another upside to LocalCommand is that it avoids the need for the "fake proxy" used in ProxyCommand -- one fewer process and one fewer source of buffering to worry about!

[akalin]

Another possible solution that avoids both LocalCommand and ProxyCommand, but is more brittle -- run ssh with -v, and parse the verbose output to look for the line:

debug1: Connecting to x.x.x.x [x.x.x.x] port 22.