Yes, that's what I mean. Invoke the factory there, only if there's a need to connect to the SSH agent. This does not fix the issue, but it is a reasonable improvement to have.
If you provide a patch I'll be happy to test it and give feedback! :) On 6 April 2015 at 23:49, Andrew Phillips <aphill...@qrmedia.com> wrote: >> That should minimize the impact of the issue, and allow normal >> operation when jclouds knows how to conenct to the node. >> >> WDYT? > > > If I understand your proposal correctly, you mean essentially moving the > first attempt to find a connector to here: > > https://github.com/jclouds/jclouds/blob/master/drivers/sshj/src/main/java/org/jclouds/sshj/SSHClientConnection.java#L166 > > ? That would certainly help in the sense that, if you're providing any one > of the other connection methods, you would not see this problem. > > I'm not sure what would happen in case you *do* want to use an agentproxy, > though. I guess what we want to ensure is that, if usocket-nc works on your > system, you do *not* get an error when using jclouds-cli. > > I think we would need to verify this...and then we should probably also > document (if not already done) that agent proxying is *only* supported using > netcat, i.e. not on Windows or using JNA. > > If I put together a quick PR that moves the first call to JSch's > ConnectorFactory as you describe, would you be able to test whether a CLI > built using that patch works with netcat available? > > Regards > > ap
