From: Joel VanderWerf on
Brian Candler wrote:
> Joel VanderWerf wrote:
>> Ivan Evtuhovich wrote:
>>> Why don't you use Net::SSH
>> One reason not to use Net::SSH is that IIUC it doesn't use the config
>> file of ssh, which can be used to define hosts, tunnels, proxies,
>> control sockets, etc. (I hope I'm wrong about that...)
> By default it uses .ssh/config, but you can tell it not to if you don't
> want it. You can also set up tunnelling and the like programatically in
> Ruby.

Huh, so it does!

How about control sockets? That doesn't seem to work out of the box.
(Control sockets are a way of multiplexing sessions over one master
session, to reduce the setup time. Very useful for slow connections, or
frequent brief access, like svn+ssh.)

I have a host set to use a master socket whose (local filesystem) path
is specified in .ssh/config. Using openssh, the second connection
happens with much less delay than the first.

However, Net::SSH does the setup with the same delay regardless of
whether there is another session already set up. Also, closing the
pre-existing session while the Net::SSH session is open doesn't hang, as
it should if they are multiplexed. So it seems Net:SSH isn't, by
default, multiplexing over the control socket.

Maybe there is some option to set?

From: Brian Candler on
Joel VanderWerf wrote:
> How about control sockets?

I don't think so.

If you had a persistent Ruby process you'd just do a single
Net::SSH.start and then start and stop shell channels down it as
required, since Net::SSH gives you much finer grained control.

So the only benefit would be for one-shot ruby processes, and then only
where there is a persistent client ssh session in another process, which
is configured to be a ControlMaster. I suspect it would require a lot of
code to implement for marginal benefit.
Posted via