feature request - reverse shell

[lambdaq]

Hello,

I manage a shit ton of Linux/Android devices behind a NAT'd 3G network, I just found Mosh now and I was like OMG this is such an awesome tool exactly what I was hoping. For a 3G network the latency and packet loss are the norm. So I happily chose Mosh. But there's a problem with NAT, you need first somehow VPN or tunnel into the intranet and then mosh to individual devices, it would be cool if mosh devices could connect to a centralized server with a public IP, then I can just connect to the central server to connect to each devices.

Is it possible with some kind of hack, and is this feature within the scope of Mosh?

[zenware]

I feel like a centralized mosh server is a bad idea, but you running your own server for those devices doesn't seem unreasonable. Probably outside the scope of this project though.

[ghost]

@lambdaq You can write this yourself. The session creation procedure would be something like this: replace the mosh wrapper script with your own that does something like this: script1 (on the client): ssh to the centralized server execute script2 execute mosh-client session after session close, ssh to centralized server and remove the iptables rule.

script2 (on the centralized server): ssh to the individual device, get the secret and port. Then, on the centralized server, execute a port forward (iptables -t nat -I PREROUTING -p udp .... -j DNAT ...) from a free port on the centralized server to that individual device to the port you got from that individual device. Then return the secret from the individual device and the free port on the centralized server to the client. The client can then start the mosh-client session to the centralized server using the free port on the centralized server and the secret from the individual device.

[lambdaq]

@adrighem I'll try it out. Thanks!

[zenware]

@adrighem :+1: I figured setting that up was obvious, but I'm glad someone took the time to explain it anyways, hopefully it helps anyone else who comes looking as well.

[ratboy666]

I too would like a "reverse shell" option to mosh. I need to support 200 systems that are mobile (and, in future, maybe more). Each of these is not available for incoming ssh! So, I would like:

Client: mosh to central server. No visible terminal.

Central Server: Access shell on client. Tell that shell to ssh to central server (possibly port forwarding).

On completion, exit the shell application - mosh may then restart.

The clients are vehicle computers (firetrucks) or tablets (inspectors).

"mosh twisted", I think.... ssh -R 2221:localhost:22, where 2221 is unique for every station.

[cgull]

The terminology is a little ambiguous here. @ratboy666, I think you mean "mobile system" when you say "client" above, is that right? I'll use "mobile system", "central server", and then "client" to describe your desktop/laptop where you're working from.

I think you're wanting to use this reverse-Mosh as a way to pass commands to the mobile systems to initiate SSH or other connections to the central server, right? And in this scenario, mosh-client would run on the mobile system, and mosh-server would run on the central server, right? Mosh could be used to send commands to a remote, but it's far from ideal-- the TCP notions of reliability and liveness are quite useful here.

This is a different scenario from the one discussed earlier, btw, where @lambdaq wants to mosh from his client to the mobile systems, which need to make a reverse connection to the central server, and some kind of proxying at the central server.

If you actually just want SSH + port forwarding, then autossh might fill your needs well-- the mobile systems would then just always keep an SSH session to your central server up and running.

Another suggestion I'd make is for the mobile devices to run VPN clients + sshd, with sshd only reachable on the client's private VPN address.

It'd be possible to rework Mosh so that mosh-server can act as a network client (roaming IP address, actively initiates connections) and mosh-client can act as a network server (fixed IP address, passively listens for connections). That might solve @ratboy666's problem, but there's probably a fair bit of work involved to get there.

[ratboy666]

cgull

You've nailed it! Exactly what I am after. The thought behind this is that mosh can sustain a "connection", that will/may be more available. With autossh (also considering), the "connection" may not be as available. Currently, we use a combination of techniques, and are looking to expand. We have something homebrew we call "vpsproxy" that uses tcp/ip, and tries to sustain a "connection". However, this suffers from autossh's defects. So, yes, mosh for the mobility, but the ability to reverse the terminal copying. Coupled with a "mosh-view" that connects to a "mosh-server" and manipulates the terminal. Right now, we are evaluating (planning) -- if we go with mosh, our organization could make the needed changes (I would need to convince them, but it is doable). What do you consider a "fair bit of work?" In your estimation -- assuming f/t resources.

[CrazyPython]

Any updates on this? I love being able to set up a SSH reverse proxy in a single command, something like that in Mosh would be wonderful.

[sudofox]

I have a Raspberry Pi I'm working on setting up to track my bike by auto-connecting to open wifi and establishing an SSH connection. However, this tends to leave a lot of open SSH connections on my server and it would be great to just have one persistent session that I can connect to. Would be great to have functionality like this so I can reconnect when able without leaving residual bash sessions all over by way of autossh hooks on NetworkManager

[sdylix]

DEV1 -> NAT -> SRV1

I belive that doing this on DEV1, the device behind NAT: autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -p $SRV1_SSH_PORT -R $SRV1_LOCAL_SSH_TUNNEL:127.0.0.1:$DEV1_SSH_PORT $SRV1_SSH_USER@SRV1_SSH_HOST

and this on SRV1 SSH server: ssh -p $SRV1_LOCAL_SSH_TUNNEL $DEV1_SSH_USER@localhost

ex: autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -p2122 -R 8000:127.0.0.1:22 user@server.test ssh -p 8000 android@localhost

[achernya]

I think most use cases today would probably be served better by something like Tailscale for access and then running mosh over the resulting tunnel.