Hey all, on the distcc mailing list, a thread about load balancing got a bit out of hand, and we started thinking about moving fsh-like connection caching into ssh itself to get rid of the overhead of starting up the python interpreter to run rsh. (Interestingly, mit's "rex", described at http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-884.pdf, considers connection caching one of the advantages it has over ssh.) Here are a few ideas, not quite boiled down to a proposal yet. You'd run a local agent (maybe not ssh-agent, since that deals with keys and wants to stay svelte, but in any case something that is started just like ssh-agent and leaves its socket name and pid in the environment) which could keep connections open for a while to recently accessed machines so that new sessions could be opened instantly instead of requiring new cryptographic handshaking. (I suppose perhaps you could cache the result of the handshake rather than caching the actual connection, kind of like ssl does, but that doesn't sound like the ssh way of doing things.) If ssh noticed the connection cache was there (i.e. its variable is set in the environment), it would tell the cache where it wanted to connect to, and the cache would pass back an already- connected fd ready to go. The tricky part is, how would the client pass back the fd when it's finished with the command? Simplest would be for the client to just close the connection. Then the connection cache would be more like a connection prefetcher; it would have to start connections before being asked for them. Alternately, if all traffic was actually sent via the local agent, it could just keep the same TCP connection open to the remote host no matter how many streams were active, and just multiplex them all. That means one extra copy of the data, but it does get rid of the need for any psychic powers on the part of the local agent. And (bonus!) it kind of means that all the smarts are in the local agent, and apps can just talk directly to it instead of forking an ssh (or loading an ssh library). It might also be easy for this agent to do simple load balancing, i.e. if the hostname given is the name of a cluster of ssh servers rather than a real server, it should give the command to the least loaded of the servers. That would come in handy for distcc, and would keep people from trying to use distcc for a general purpose job distributor :-) OK, glad I got that off my chest. Maybe if I sleep on it, I'll realize which way to go with it. - Dan
Dan Kegel wrote:> Hey all, > on the distcc mailing list, a thread about load balancing > got a bit out of hand, and we started thinking about > moving fsh-like connection caching into ssh itself > to get rid of the overhead of starting up the python > interpreter to run rsh. > (Interestingly, mit's "rex", described at > http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-884.pdf, > considers connection caching one of the advantages it has over ssh.)The SSH protocol already includes the necessary capabilities to implement this, and I have been wanting to do this for a little while (but have obviously not gotten around to it). One you have established a SSH transport, you can fire off lots of sessions (command, shell or subsystem) which have independant lifespans. Our client only supports a single such session, but Our sshd already has this capability and I believe that the ssh.com windows client supports multiple connections against OpenSSH sshd. To implement this in OpenSSH's ssh, I was thinking about adding an argument to get ssh to listen on a unix domain socket after authentication. Additional sessions could be established by connecting to this socket, using SCM_RIGHTS messages to pass the std{in,out,err} fds to the connected ssh. It would probably be easiest to modify ssh to be the client, as it already does most of the buffering, etc. This wouldn't add much complexity to ssh, just a little bit of logic to deal with the control socket - we already have most of the infrastructure in the event loop to deal with multiple connections. This would be a good medium-sized project for someone to sink their teeth into :) -d
Hi, On Sun, May 02, 2004 at 07:13:46PM +1000, Damien Miller wrote:> One you have established a SSH transport, you can fire off lots of > sessions (command, shell or subsystem) which have independant > lifespans. Our client only supports a single such session, but > Our sshd already has this capability and I believe that the > ssh.com windows client supports multiple connections against > OpenSSH sshd.Putty also supports this. Quite impressive, actually. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
Gert Doering wrote:> On Sun, May 02, 2004 at 07:13:46PM +1000, Damien Miller wrote: > >>One you have established a SSH transport, you can fire off lots of >>sessions (command, shell or subsystem) which have independant >>lifespans. > > Putty also supports this. Quite impressive, actually.lsh does too (lshg/lsh -G). Hmm, someone really ought to hack it into ssh(1) ... -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Gert Doering <gert at greenie.muc.de> wrote:>On Sun, May 02, 2004 at 07:13:46PM +1000, Damien Miller wrote: >> One you have established a SSH transport, you can fire off lots of >> sessions (command, shell or subsystem) which have independant >> lifespans. > >Putty also supports this. Quite impressive, actually.You are wrong. http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ssh2-generality.html The "duplicate session" function opens a new connection. Tony. -- f.a.n.finch <dot at dotat.at> http://dotat.at/ PORTLAND PLYMOUTH: SOUTHWEST VEERING NORTHWEST 5 TO 7, OCCASIONALLY GALE 8, PERHAPS SEVERE GALE 9 LATER IN PLYMOUTH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.
John Davidorff Pell wrote:> Can I ask you (or someone else) to define "session"? I can think of a > number of reasons that a single shell/pipe can carry many different > "sessions". > > Just trying to follow the discussion, and this part is a little > confusing. :-) > > On 3 May 2004, at 22:36, Jefferson Ogata wrote: > >> It is a reasonable expectation for an admin to be able to say: one >> authentication authorizes one session.It is a reasonable expectation for an admin to be able to say: one successful authentication authorizes only one shell channel. -- Jefferson Ogata <Jefferson.Ogata at noaa.gov> NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
Ben Lindstrom wrote:> On Wed, 5 May 2004, Jefferson Ogata wrote: >>Now you add connection caching, and the compromise is no longer contained. If >>the user is legitimately logged from the gateway into the secure system, the >>intruder can now log in to the secure system, as many times as he likes. > > I think Damien/Markus would agree when I say that the user would have to > enable such a thing for it to be used. Either via a ssh_config or via > a commandline option. Much like how X11 sessions are. > > Why would a user do such a thing on a machine as you describe? What gain > do they get? I see none.No doubt the lazy user /would/ enable such a thing. The control needs to be on the server side. -- Jefferson Ogata <Jefferson.Ogata at noaa.gov> NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
Dan Kegel wrote:> Hey all, > on the distcc mailing list, a thread about load balancing > got a bit out of hand, and we started thinking about > moving fsh-like connection caching into ssh itselfFYI OpenSSH has connection sharing in CVS now. It isn't well tested beyond a couple of platforms: OpenBSD (obviously), Linux and OSX and parts of it are still subject to change - in particular the protocol spoken between the "master" ssh connection and its sharing clients. It certainly won't do anything fancy, like opportunisticly starting up a connection if one doesn't already exist - but we want to get the guts of it well tested before we add features (if we ever do). The sort of thrashing that distcc would likely put it through would be welcome. It has certainly been useful enough to change the way that I use ssh :) (hint: set up aliaes for master and client connections in .ssh/config) -d