Jeff Epler's blog

31 January 2014, 18:05 UTC

Mosh automatic cleanup of dead sessions

I love mosh, using it to connect to a long-lived screen session from multiple computers (laptop, chromebook, $DAY_JOB, and phone).

One problem with it is that a mosh-server process that has no living client will linger for a very long time (forever?). This can happen for various reasons, such as letting a device's battery run down.

With some brainstorming help from the participants from #mosh, I came up with a way to automatically kill old mosh-server processes that probably represented defunct clients without killing ones that may represent working clients.

For a long time, my basic setup has been to run a command equivalent to: mosh myserver -- bin/cs where cs is a script which sets some environment variables and ends with exec screen, so I already had an excellent location to put cleanup code.

I also felt that the cleanup rule I wanted was: kill all mosh-server processes started from the same client. $SSH_CLIENT was suggested for this, but it's not useful since my portable devices naturally connect from different networks with different IP addresses (that's the point of mosh after all!) So I jumped to the conclusion that I needed a unique identifier. Why not involve a UUID?

As soon as I realized I needed to pass the UUID on the commandline or environment of cs, I realized that meant it would show up in the mosh-server commandline. So that led to the following snippet: ($i is already identified as being the UUID= argument):

    ps h --sort start_time -o pid,command -C mosh-server |
        grep "$i" |
        head --lines=-1 |
        awk '{print $1}' |
        xargs --no-run-if-empty -n 1 --verbose kill

That seems to work! One final wrinkle, though: In mosh irssi connectbot, there's no way to specify the mosh commandline directly. Hoever, there is "Requested mosh server". I created a wrapper script reading:

#!/bin/sh
exec mosh-server "$@" -- bin/cs UUID=...

and used that script (with full path, in my case) as the configuration value.

Now I shouldn't have to worry about mosh-server processes piling up on my main linux box anymore.

[permalink]

18 December 2005, 3:49 UTC in software

pam_ssh

This is neat. pam_ssh "provides single sign-on behavior for SSH. The user types an SSH passphrase when logging in (probably to GDM, KDM, or XDM) and is authenticated if the passphrase successfully decrypts the user's SSH private key. In the PAM session phase, an ssh-agent process is started and keys are added. For the entire session, the user can SSH to other hosts that accept key authentication without typing any passwords."

The only snag I ran into on FC2 was that the script in /etc/X11/xdm/Xsession unconditionally started a fresh ssh-agent, even if $SSH_AGENT_PID was already set. I changed the SSHAGENT= line to read [ -x /usr/bin/ssh-agent && -z "$SSH_AGENT_PID" ] && SSHAGENT="/usr/bin/ssh-agent" and then everything worked. I'm now using it for console and gdm logins on one of my machines.

On FC2 I built the rpm from the tarball. It looks like FC4 has one available via yum.

Update 2006/01/09: I was having trouble with pam_ssh not leaving an ssh-agent running the next time I logged in after a crash (dead battery). I discovered that the problem was that leftover ~/.ssh/agent-* files would trick pam_ssh into thinking that an appropriate ssh-agent was already running. I now remove these files in /etc/rc.local when booting.

[permalink]