juju fails silently when .ssh/config has a ControlMaster set

[Jay R. Wren]

juju bootstrap times out after 10m instead of retrying, if ~/.ssh/config has a wildcard ControlMaster and ControlPersist

    $ grep -A6 'Host \*$' ~/.ssh/config
    Host *
        VerifyHostKeyDNS yes
        StrictHostKeyChecking yes
        ControlMaster auto
        ControlPath ~/.ssh/master-%r@%h:%p
        ControlPersist yes

    $ juju bootstrap -e azure
    Launching instance
     - juju-azure-nj6ut6w4n8-jujunts3syq5fc7rjd01lvr3l0y9yb0j7d9xx8byjm78bw3u7j
    Waiting for address
    Attempting to connect to 10.0.0.4:22
    Attempting to connect to juju-azure-nj6ut6w4n8.cloudapp.net:22

    ERROR bootstrap failed: waited for 10m0s without being able to connect: ssh: connect to host juju-azure-nj6ut6w4n8.cloudapp.net port 22: Operation timed out
    Stopping instance...
    Bootstrap failed, destroying environment
    ERROR waited for 10m0s without being able to connect: ssh: connect to host juju-azure-nj6ut6w4n8.cloudapp.net port 22: Operation timed out

I can work around this by modifying my .ssh/config. IMO this is still a bug, and this patch should be considered:

diff --git a/utils/ssh/ssh_openssh.go b/utils/ssh/ssh_openssh.go
index d266e28..359fa31 100644
--- a/utils/ssh/ssh_openssh.go
+++ b/utils/ssh/ssh_openssh.go
@@ -14,7 +14,7 @@ import (
        "github.com/juju/utils"
 )

-var opensshCommonOptions = []string{"-o", "StrictHostKeyChecking no"}
+var opensshCommonOptions = []string{"-o", "StrictHostKeyChecking no", "-o", "ControlPath none"}

 // default identities will not be attempted if
 // -i is specified and they are not explicitly

[Robie Basak (racb)]

I find the use of my configured control master useful. It speeds up connections. For machines where I use two-factor auth (not Juju stuff yet, but it'd be nice not to rule that out), it saves me having to re-auth all the time. Even without that, the connection time speedup is noticeable and I think it helps with charm development iteration considerably.

So I'd like disabling control socket use to be considered a workaround, rather than a solution, and I'd like the option to have Juju to continue using mine when I do "juju ssh".

I also wonder if this is an Azure-specific bug perhaps? I've used (not current; older) versions of Juju with a control socket enabled, noticed that "juju ssh" was using it, and didn't notice any problems. My settings were:

Host *
  ControlMaster auto
  ControlPath ~/.ssh/control/%r@%h:%p
  ControlPersist 3600