Connection caching?

[David Woodhouse]

On Mon, 2004-05-03 at 10:47 +1000, Damien Miller wrote:
> I think that my words were ambiguous: I don't think that a single ssh
> process should represent multiple connections to *different* servers.
> 
> Does that address your concern?

Yes it does; thanks.

> > Doing it in SSH, we can add an option which instructs the client to
> > leave a connection open and daemonize itself, and an option which
> > instructs the client to look for the unix domain socket created by such
> > a daemon.
> 
> That is exactly what I propose: start a ssh to a server, then use a
> client-side listening socket to run multiple sessions to that server
> over the transport.

Are you familiar with fsh? You connect once and it leaves a daemon
running. You connect again and it's fast. There's a configurable
timeout. I think that model of operation -- not having to _explicitly_
start the daemon -- is ideal.

> > You also want to include the username, 
> 
> I don't think you would want to put the control files anywhere other
> than a mode 0700 directory owned by the user who started the
> connection. We enforce similar restrictions on keys and (in -current)
> .ssh/config. Given this, I don't see a need for putting the username in
> there.

Remote username, not local username.

> > and possibly also the _local_ IP
> > address used for the connection in question. Or you have to deal with
> > dynamic IP addresses somehow -- perhaps by means of keepalive. Fsh
> > screws that up, and it's a PITA.
> 
> ssh will terminate when the address changes, so what does this buy you?

I've seen that fail to happen with fsh being used as a wrapper. Perhaps
it's just that fsh isn't noticing that ssh died; I need to investigate
further. 

I haven't investigated much. TBH I'd rather just withhold a proportion
of the extortionate amount I pay my telco for GPRS until they start
providing a service where I can at least expect to keep the same IP
address if I reconnect within seconds of being disconnected. :)

> We do app-level keepalives: {Client,Server}Alive{Count,Max}. We just
> need to ensure that a terminating ssh cleans up its control socket
> gracefully. Anything that wants to make use of this facility could
> just do something like:
> 
> [ -s ~/.ssh/ctl-$host ] || ssh -nNfo ControlSock=~/.ssh/ctl-$host $host
> 
> I.e ensure that the socket is ready, or start a new connection.

That logic surely wants to be in ssh(1) ? If there's a socket, use it.
Else create one.

-- 
dwmw2