TL;DR: I expect ProxyCommand to have effect in preference to ControlPath. I've just tripped over this one. I have an ssh Host (let us call it "MAIN") with a ControlPath and with ControlMaster=no, from the .ssh/config file. I also have a shell script whose purpose is to hop to a remote host through a port forward, which uses the ProxyCommand option like this: ProxyCommand ssh MAIN nc 127.0.0.1 7777 because the remote host is accessible via port 7777 on host MAIN. So the script invokes an ssh commandlike this: ssh -o "ProxyCommand=ssh MAIN nc 127.0.0.1 7777" remoteuser at MAIN The expectation is that the inner proxycommand ssh goes via the control socket and that the outer ssh uses the ProxyCommand to get to the remote host. Imagine my surprise when the ControlMaster from the config file takes precedence over the ProxyCommand from the command line. By contract, this works as I intended: ssh -o ControlPath=none -o "ProxyCommand=ssh MAIN nc 127.0.0.1 7777" remoteuser at MAIN On reflection, of course these are distinct options and that side of things isn't, of itself, a bug. However, is there a sane use case for using ControlMaster/ControlPath at all if there is a ProxyCommand? I would have thought not. Can someone explain a use case for this precedence (ControlPath before ProxyCommand), or is this a misfeature which would benefit from a fix/change? Thanks, Cameron Simpson <cs at cskk.id.au> (formerly cs at zip.com.au)
On Fri, 3 Nov 2017, Cameron Simpson wrote:> TL;DR: I expect ProxyCommand to have effect in preference to > ControlPath. > > I've just tripped over this one. I have an ssh Host (let us call > it "MAIN") with a ControlPath and with ControlMaster=no, from the > .ssh/config file. > > I also have a shell script whose purpose is to hop to a remote host > through a port forward, which uses the ProxyCommand option like this: > > ProxyCommand ssh MAIN nc 127.0.0.1 7777 > > because the remote host is accessible via port 7777 on host MAIN. > > So the script invokes an ssh commandlike this: > > ssh -o "ProxyCommand=ssh MAIN nc 127.0.0.1 7777" remoteuser at MAIN > > The expectation is that the inner proxycommand ssh goes via the > control socket and that the outer ssh uses the ProxyCommand to get to > the remote host. > > Imagine my surprise when the ControlMaster from the config file takes > precedence over the ProxyCommand from the command line. By contract, > this works as I intended: > > ssh -o ControlPath=none -o "ProxyCommand=ssh MAIN nc 127.0.0.1 7777" > remoteuser at MAIN > > On reflection, of course these are distinct options and that side of > things isn't, of itself, a bug. However, is there a sane use case for > using ControlMaster/ControlPath at all if there is a ProxyCommand? I > would have thought not. > > Can someone explain a use case for this precedence (ControlPath before > ProxyCommand), or is this a misfeature which would benefit from a > fix/change?They are quite othorgonal features, but the whole point of multiplexing is to avoid the need to make additonal connections. So it's quite logical that ssh checks ControlPath for an active mux master before attempting a new connection (that may use ProxyCommand). There's little point to specifying ControlMaster=no and a ProxyCommand because there is no fallback to making a new connection in that case, but ControlMaster=yes/auto/autoask with ProxyCommand is quite sensible: "try to use multiplexing but if you have to open a new connection then do it via this proxy". BTW> ProxyCommand ssh MAIN nc 127.0.0.1 7777If your ssh client is new enough, you should try ssh -J / JumpHost instead. -d
On 03Nov2017 13:07, Damien Miller <djm at mindrot.org> wrote:>On Fri, 3 Nov 2017, Cameron Simpson wrote: >> TL;DR: I expect ProxyCommand to have effect in preference to >> ControlPath.[...]>> On reflection, of course these are distinct options and that side of >> things isn't, of itself, a bug. However, is there a sane use case for >> using ControlMaster/ControlPath at all if there is a ProxyCommand? I >> would have thought not. [...] > >They are quite othorgonal features, but the whole point of multiplexing >is to avoid the need to make additonal connections. So it's quite >logical that ssh checks ControlPath for an active mux master before >attempting a new connection (that may use ProxyCommand). > >There's little point to specifying ControlMaster=no and a ProxyCommand >because there is no fallback to making a new connection in that case, >but ControlMaster=yes/auto/autoask with ProxyCommand is quite sensible: >"try to use multiplexing but if you have to open a new connection then >do it via this proxy".Ah, now the rationale is apparent. Ok, that makes sense to me. Thank you.>> ProxyCommand ssh MAIN nc 127.0.0.1 7777 >If your ssh client is new enough, you should try ssh -J / JumpHost instead.I give this particular script to others, so that may not be feasible yet. But I saw that option arrive and intend to make us of it. Nice! I discovered -G too recently, very useful to me. Not least for autorestarting persistent tunnels when I modify a config file (I use the output as a signature string). Cheers, Cameron Simpson <cs at cskk.id.au> (formerly cs at zip.com.au)