Mosh: Implement ProxyJump

[Gunni]

mosh -o ProxyJump proxy.example.com target.example.com (or similar, use ssh config?)

local mosh authenticates with proxy.example.com and starts the mosh server on proxy that forwards the packets to target.example.com.

local mosh then connects to the mosh server on proxy as usual and asks to forward a stream which then gets forwarded to target where it authenticates and finally connects to the mosh server on target.

This way, no agent forwarding is ever required since i can always connect from localhost and all agents and keys stay there.

Also lets me authenticate using my yubikey / pgp key directly with the end host, again, without ever exposing my agent og key.

todo:

• how does the proxy know the connection should end and it should exit?
• can it be multiplexed like using ssh ControlMaster to multiplex multiple connections?

[Daviey]

Is this the same issue as issue #285 ?

[cgull]

@Gunni, I think you're proposing that mosh-server (mosh-proxy?) would 1) tunnel another SSH session to target.example.com (I don't see how you'd avoid exposing the ssh agent to the proxy otherwise) and 2) would forward the UDP session to target.example.com. Have I got that right?

It is in fact pretty much impossible for a proxy to know when the session ends (unless it had the Mosh session key, which it wouldn't in the description I gave). The client can disappear at any time and reappear on a different address and/or port, and the server will stop sending messages a short while after messages from the client stop.

Pretty much the only two ways a proxy can know about a session's lifetime in the existing Mosh architecture are 1) having the session key and decrypting/observing the session, or 2) maintaining some sort of out-of-band observation of the server's lifetime such as a TCP connection or pipe or something.

[Gunni]

Hey,

How about this:

Local client authenticates to the first hop, asking mosh-server to start in proxy mode, mosh-server starts and listens for the connection.

The local client then exits that ssh connection and starts a new one like this:
ssh -J proxyserver.example.com destinationserver.example.com

and on that connection performs the normal mosh-server setup, when ready, exits this ssh connection but leaving mosh-server listening.

The local client then sends some packets to the proxy mosh-server, with a "ping" packet, and an encrypted blob to forward to the target ip address. The proxy can never decrypt this blob because it does not have the session keys for that blob.

On the target host, it receives the udp frames as per normal procedure, not even caring that the proxy is there.

The dead session handler that mosh-server already uses could be used here, currently when i connects it displays a list of idle mosh-servers that i can kill, and i can use the idle kill feature which is already documented.

This way:

1. i can proxy to hosts behind firewalls
2. authentication is done end-to-end
3. no ssh authentication keys EVER leave my system
4. no ssh agent forwarding is required
5. idle timeout will kill proxies that recieive no data if i choose to configure it
6. if it is implemented well, i should be chainable endlessly

[oparkins]

This feature would be super useful. I've just started to use mosh, but it is very limiting to not be able to use the ProxyJump feature. More than half the hosts in my ssh config file use ProxyJump due to firewall policies.

[srd424]

I have implemented a bodge to allow me to use ProxyJump: https://github.com/mobile-shell/mosh/issues/285#issuecomment-515752843

[pabloab]

This was already discussed on #120, where @keithw suggest using guardian-agent. From IRC:

I usually have to go through a proxy/bastion/jump server to get to my servers:
ssh -J john@jumpbox john@myserver. Iis this not possible with mosh?

_{(-J is somewhat similar to -A)}

@keithw said:

I think our position on jump servers is that you really don't want to be giving the bastion access to the plaintext -- better to just relay the ciphertext (in our case, the UDP datagrams) and run one pair of mosh-client/mosh-server. This is also a lot better for the predictive local echo algorithm. Of course it would be better if we had a real mosh-proxy that you could run on the bastion that would do this and also track the roaming client for you.

Also said there:

it may be possible for someone to develop a mosh-proxy as a separate project from mosh itself

Maybe @keithw could create a new repository called mosh-proxy so people could start sending PRs to have this feature separately of the secure mosh core.

[quentinmit]

I built a prototype already:

https://github.com/quentinmit/mosh-jump

But this really needs to be embedded in mosh/mosh-server, not a separate repo. You should see what I have as a proof-of-concept.

[maximeborges]

+1
Could be very useful in high-latency configuration, i.e connecting to a server in Asia from Europe with an intermediate proxy

[aduong]

I think it'd be great if there were an official way to accomplish this. I've been getting around this with a wrapper by doing some UDP proxying, bookkeeping, and calling mosh-server and mosh-client directly: https://github.com/aduong/mosh-with-jump. It seems it's quite similar to the approach at https://github.com/mobile-shell/mosh/issues/970#issuecomment-611128129.

[matheusfillipe]

I think it'd be great if there were an official way to accomplish this. I've been getting around this with a wrapper by doing some UDP proxying, bookkeeping, and calling mosh-server and mosh-client directly: https://github.com/aduong/mosh-with-jump. It seems it's quite similar to the approach at #970 (comment).

This doesn't work for me. Fails with:

Network exception: Bad IP address (): Name or service not known: Success
[mosh is exiting.]

This is very important to me since most ISP's here block outgoing on port 22.