<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/"/>

<title>Jeff Epler's blog</title>
<modified>2014-01-31T18:05:49Z</modified>
<tagline>Photos, electronics, cnc, and more</tagline>
<author><name>Jeff Epler</name><email>jepler@unpythonic.net</email></author>
<entry>
<title>Mosh automatic cleanup of dead sessions</title>
<issued>2014-01-31T18:05:49Z</issued>
<modified>2014-01-31T18:05:49Z</modified>
<id>https://gamma.unpythonic.net/01391191549</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01391191549"/>
<content type="text/html" mode="escaped">

I love &lt;a href=&quot;http://mosh.mit.edu&quot;&gt;mosh&lt;/a&gt;, using it to connect to a
long-lived screen session from multiple computers (laptop, chromebook,
$DAY_JOB, and phone).

&lt;p&gt;One problem with it is that a &lt;tt &gt;mosh-server&lt;/tt&gt; 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.

&lt;p&gt;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.

&lt;p&gt;For a long time, my basic setup has been to run a command equivalent to:
&lt;tt &gt;mosh myserver -- bin/cs&lt;/tt&gt; where cs is a script which sets some environment
variables and ends with &lt;tt &gt;exec screen&lt;/tt&gt;, so I already had an excellent
location to put cleanup code.

&lt;p&gt;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?

&lt;p&gt;As soon as I realized I needed to pass the UUID on the commandline or
environment of &lt;tt &gt;cs&lt;/tt&gt;, I realized that meant it would show up in the &lt;tt &gt;
mosh-server&lt;/tt&gt; commandline.  So that led to the following snippet: ($i is already
identified as being the UUID= argument):
&lt;pre &gt;
    ps h --sort start_time -o pid,command -C mosh-server |
        grep &amp;quot;$i&amp;quot; |
        head --lines=-1 |
        awk '{print $1}' |
        xargs --no-run-if-empty -n 1 --verbose kill
&lt;/pre&gt;

&lt;p&gt;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
&amp;quot;Requested mosh server&amp;quot;.  I created a wrapper script reading:
&lt;pre &gt;
#!/bin/sh
exec mosh-server &amp;quot;$@&amp;quot; -- bin/cs UUID=...
&lt;/pre&gt;
and used that script (with full path, in my case) as the configuration
value.

&lt;p&gt;Now I shouldn't have to worry about mosh-server processes piling up
on my main linux box anymore.
</content>
</entry>
<entry>
<title>pam_ssh</title>
<issued>2005-12-18T03:49:33Z</issued>
<modified>2005-12-18T03:49:33Z</modified>
<id>https://gamma.unpythonic.net/software/01134877773</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/software/01134877773"/>
<content type="text/html" mode="escaped">
&lt;div style=&quot;float:right;clear:right&quot;&gt;&lt;!-- pam-ssh.png--&gt;&lt;div class=albumouter style=width:306px id=&gt;&lt;div class=albumimage style=&quot;width:306px;margin-left:0.0px;&quot;&gt;&lt;img src=&quot;https://media.unpythonic.net/emergent-files/software/01134877773/pam-ssh.png&quot;&gt;&lt;br&gt;&lt;span&gt;A console login mediated by pam_ssh&lt;/span&gt;&lt;/div&gt;&lt;/div&gt;
&lt;/div&gt;
This is neat.  &lt;a href=&quot;http://pam-ssh.sourceforge.net/&quot;&gt;pam_ssh&lt;/a&gt; &amp;quot;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.&amp;quot;

&lt;p&gt;The only snag I ran into on FC2 was that the script in &lt;tt&gt;
 /etc/X11/xdm/Xsession&lt;/tt&gt; unconditionally started a fresh ssh-agent, even if &lt;tt&gt;
 $SSH_AGENT_PID&lt;/tt&gt; was already set.  I changed the SSHAGENT= line to read
&lt;span class=indent&gt;&lt;tt&gt;[ -x /usr/bin/ssh-agent &amp;amp;&amp;amp; -z &amp;quot;$SSH_AGENT_PID&amp;quot; ] &amp;amp;&amp;amp; SSHAGENT=&amp;quot;/usr/bin/ssh-agent&amp;quot;&lt;/tt&gt;&lt;/span&gt;
and then everything worked.  I'm now using it for console and gdm logins on one
of my machines.

&lt;p&gt;On FC2 I built the rpm from the tarball.  It looks like FC4 has one available
via yum.

&lt;p&gt;&lt;b&gt;Update 2006/01/09:&lt;/b&gt; 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 &lt;tt&gt;~/.ssh/agent-*&lt;/tt&gt; 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.
</content>
</entry>
</feed>
