Timo (one of the SSH authors) sent me this and we thought it might be better to discuss on the list.<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Timo J. Rinne</b> <span dir="ltr"><<a href="mailto:tri@iki.fi">tri@iki.fi</a>></span><br>
Date: Wed, Oct 31, 2012 at 4:39 PM<br>Subject: About mosh + ssh-agent forwarding support<br>To: <a href="mailto:keithw@mit.edu">keithw@mit.edu</a><br><br><br>Hi<br>
<br>
Just got interested in mosh. What a great software and what a great<br>
effort in server side terminal emulation! However, I think today's main<br>
uses for terminal connections are different admin tasks and different<br>
development tasks. And typical for both uses is that the user wants to<br>
log in to other systems (e.g. ssh/scp/git ...) and typically these<br>
commands need authentication and security aware people typically store<br>
their authentication keys in the machines they use hands on rather than<br>
in a large number servers here or there. That's what makes ssh-agent<br>
interesting.<br>
<br>
I know there are several people that would be happy to see agent<br>
forwarding appear in mosh. I haven't had opportunity to look into mosh<br>
source code more closely, but still I'd imagine it couldn't be that much<br>
of a problem, because much of the problems apparent in generic channel<br>
forwarding can just be forgotten (mainly i think channel based buffering<br>
+ windowing + flow control that is a major pain in ssh). Also<br>
performance is not an issue. The amount of data is in the magnitude of<br>
kilobyte in one agent connection and it really doesn't matter whether<br>
the authentication takes 10ms or 250ms.<br>
<br>
I've personally implemented the agent forwarding for commercial version<br>
of ssh (the original one by SSH Communications Security Corp.) and might<br>
be able to help with this one too so that the obvious caveats are avoided.<br>
<br>
I don't know how much you know a about the agent, but basically there is<br>
very little mosh needs to know about it and it surely don't have to know<br>
anything about the agent protocol. Actually if you run ssh-agent in your<br>
local system, it opens a local socket in user owned subdirectory under<br>
/tmp and sets environment variable SSH_AGENT_SOCK to point to that<br>
listener and passes that environment to a shell (or X session) that is<br>
going to be executed. Then whenever an application wants to access<br>
ssh-agent, it connects to the local listener, lists the keys available,<br>
and requests the cryptographic operation to be executed for one of the<br>
keys and then gets the result. The result is then used in ssh<br>
authentication. Agent forwarding is nothing more than a method for ssh<br>
client to request the server to open ssh agent socket listener and<br>
forward all incoming connections to that listener upstream via existing<br>
ssh connection back to the client so that the client can then forward<br>
the connection to local agent listener. Naturally these forwards can be<br>
chained, because apart from delay, there is no difference between local<br>
and forwarded agent connection.<br>
<br>
In case of mosh there are a few additional things to consider, because<br>
the connection can be broken and then re-established, but actually they<br>
are quite minor.<br>
<br>
1) The server must be aware that agent forwarding is going to be used<br>
before it spawns the user shell, because it must open the socket<br>
listener and set SSH_AGENT_SOCK environment variable accordingly.<br>
<br>
2) If the connection is down, the listener must still work, but<br>
naturally what it should do, is to accept connections but immediately<br>
close them. Other more elaborate alternative would be to code to the<br>
mosh server the ability to tell to the connection that no keys are<br>
currently available (using ssh agent protocol), but I don't really see<br>
much point in it.<br>
<br>
3) If the connection goes down while the agent connection is ongoing, it<br>
must close the active agent connection, but still leave the listener<br>
active, so that subsequent connections can be handled (closed if the<br>
connection is down, or forwarded again when the connection is revived).<br>
<br>
I've been using mosh only so that the client is running all the time. I<br>
don't know if it's actually possible to kill the client and somehow<br>
start another one and connect to existing connection (using some magic<br>
cookie key or something). But if this is (or will be) the case, then of<br>
course also new client invocation must be aware that the server can send<br>
agent forwarding requests. Actually I think that in that kind of<br>
scenario, the new client instance must be told whether to allow agent<br>
forwarding or not (just like the initial one too) and if the initial one<br>
allowed those and the new one doesn't, then agent forwarding requests<br>
passed from the server are just denied and the server in its turn just<br>
closes the agent connection. Then again it might be possible to replace<br>
the second client with the third one again allowing forwarding which<br>
would make the agent forwards to go through again. The other way it's<br>
not possible. If the initial mosh connection is opened so that the<br>
server doesn't set SSH_AUTH_SOCK environment variable, it's not possible<br>
(in any practical way) to set up forwarding using that server.<br>
<br>
Random thoughts, should you be interested about further information, I'm<br>
more than happy to help. I may also help with some code but I'm quite<br>
busy with other stuff at the moment. I can however promise to<br>
contribute the local domain socket stuff if someone else does the<br>
required channel stuff (I don't know if mosh has some channel concept<br>
already in the protocol) and upstream connection requests etc.<br>
<br>
Best regards,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Timo J. Rinne <<a href="mailto:tri@iki.fi">tri@iki.fi</a>><br>
</font></span></div><br>