Reconnection and garbage collection

[keithw]

Allow reconnection to existing sessions that were somehow severed. Give command to clean up disconnected sessions.

[pimlott]

I just started using mosh and this is my top priority wish. screen and dtach are not as solid as mosh and disrupt the great user experience that mosh offers.

I suggest simply allowing the user to specify a session name on the command line ("mosh --session-name dev1 ..."). When a session name is given, mosh-server looks for and reconnects to an existing session before starting a new one. Of course there are a lot more details, but you can figure them out. :-)

[pimlott]

I thought this would be as simple as a wrapper that would run a new mosh-client if the appropriate server were already running. But this does not work. If you run mosh-server and mosh-client by hand, then kill -9 mosh-client and run it again, it cannot connect. So I guess this has to be fixed at the protocol level. :-(

I have a prototype wrapper script ready for when this is fixed. By the way, one thing you might want to change is that mosh-server prints its port and key or stdout, but its PID on stderr. Since the wrapper script needs both, it has to do extra work to read both outputs. It would be simpler to print all normal messages to stdout.

[kmcallister]

As @joneskoo pointed out in #284, we could at least add something to kill any mosh-server currently listening on the same port. This would help firewalled users who open only one port for Mosh.

[phmarek]

Any progress on the "re-connect to existing server" front?

[kmcallister]

There are a few possible designs for reconnecting:

• Log in with SSH again, and communicate with the old mosh-server (over a UNIX domain socket or something) to set up a new cryptographic session
• Have mosh-client save its cryptographic state (session key and nonce) to disk, so that a new client can resume the session.

Either design adds a significant amount of complexity and security attack surface. In particular, using the same nonce and key more than once is fatal to security. So in the second design, we would need to be very careful to never use an even slightly stale state file — I consider this basically impossible to get right. @pimlott: you should be careful too, if you go back down the route of launching a new mosh-client with the same key.

A major design goal of Mosh is to keep the security story as simple as possible. I don't think reattaching is a compelling enough feature to go against this principle, when we have acceptable workarounds like mosh host -- screen -dR. (I say this as someone who uses this workaround daily.)

However, I do think there are some simpler features we could implement to make these workarounds nicer. See #324 for an example.

[phmarek]

What's the attack surface for the first item? If I can get to the machine, I can just start GDB and get any cryptographic state out of the running process. So the mosh-server might accept a short plain-text exchange on its UDP socket (sent from localhost) to re-initialize it's crypto data (or on a separate unix-socket - but the requirement "same machine" could be solved by using a mmap()ed file for communicating the new state, and using UDP only to start the re-initialization, eg. by telling the mmap() filename).

In fact, using GDB (and exported variables for the counter and the crypto-state) might be a way to make it work from the outside without any more work within mosh ;)

[kmcallister]

@phmarek: It's mainly that we need a place to put those sockets on the filesystem, such that only the user can access them, and this needs to be correct for all UNIXes (which don't agree on interpreting permissions bits on socket files) and also correct for weird filesystems like AFS which implement their own access control model. I'm not saying this is impossible — programs like screen have to do something similar. But it's just another thing that we could screw up.

(Actually, I think screen uses its setgid powers to create sockets or pipes in an area not normally accessible to users. setuid/setgid is of course another huge can of worms we don't want to open.)

On the other hand, accepting an unauthenticated message with a user-specified (i.e. attacker-controlled) filename and then opening and writing to that file seems like a really bad idea...

Right now, Mosh doesn't do anything with the filesystem (except print /etc/motd, and write utmp entries through a third-party library) and doesn't accept any unauthenticated traffic from anyone. To me, security is about these kinds of principles which exclude whole classes of attacks — not about doing something complex and then patching up the security of each part piecemeal.

[kmcallister]

Also, of course, a "same machine" policy is not good enough for people using Mosh to connect to multi-user servers. There's a server at MIT which has 153 Mosh connections from 35 different users.

I know that it's so passé to use operating systems as operating systems, and we should run every program in its own virtual machine, but there are a few of us who haven't switched over to this new way of thinking yet. ;)

[phmarek]

Well, then have mosh tell the filename to the new session-initator, or whatever else you like ...

But, as I already said - with the ptrace syscalls it's possible to inject a new session key and counter value without any server modifications (although a few would certainly help, like the exported symbols). That should be fairly "same machine" only, right?