$SSH_USER is indeed root in this case, although I also tried with a
non-root username with the same effect.
It seems likely that tweaks to the crypto routines are to blame, given
the exception message contains:
Unable to reach a settlement: [] and [aes128-ctr, aes192-ctr,
aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc,
blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour,
[email protected]]
Will poke around and see what I can find.
Thanks for the suggestions!
A.
--
Alasdair Hodge
Principal Engineer,
Cloudsoft Corporation
On 10/02/2015 18:47, Alex Heneveld wrote:
Hi Alasdair,
Building it up dynamically shouldn't make a difference. Can you try the
same settings in a brooklyn.properties to confirm?
You might also want to try setting loginUser.privateKeyFile . It's
possible there was a default being used there which must now be
explicitly specified. (On that subject, is SSH_USER root? And can you
see in the logs if AWS is giving us credentials for loginUser?) If not
that then I wonder if the update to bouncycastle crypto routines might
have changed something; you could try reverting just the crypto changes.
Best
Alex
On 10/02/2015 18:33, Alasdair Hodge wrote:
Hey Alex,
I've just discovered that these changes break my (not-too-wacky??) use
case in a customer project.
In my scenario, the top-level application class has a main() method
that gets invoked by a deployment script which *dynamically builds a
Brooklyn named location* via a handful of system properties:
[snip]
java -cp ${DEFAULT_CLASSPATH} -Xmx1024m \
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}=jclouds:aws-ec2:${AMAZON_REGION}
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.user=${SSH_USER} \
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.privateKeyFile=${SSH_KEY}
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.publicKeyFile=${SSH_KEY}.pub
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.imageId=${AMAZON_REGION}/${AMAZON_IMAGE}
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.hardwareId=${AMAZON_INSTANCE_TYPE}
\
${JAVA_MAIN_CLASS} $* named:${BROOKLYN_LOCATION_NAME}
Public and private keys (RSA) are contained within the project itself,
and EC2 credentials are in my regular brooklyn.properties file.
Commit 793c990 (which merged your improvements back to master) fails
for this scenario: the VM is obtained from EC2, but subsequent jclouds
init throws SshException:
1) SshException on node us-west-1/i-2499d9e7:
org.jclouds.ssh.SshException:
(root:rsa[fingerprint([snip]),sha1([snip])]@54.219.228.35:22)
(root:rsa[fingerprint([snip]),sha1([snip])]@54.219.228.35:22)
error acquiring {hostAndPort=54.219.228.35:22, loginUser=root,
ssh=null,
connectTimeout=60000, sessionTimeout=60000} (out of retries - max 50):
Unable to reach a settlement: [] and [aes128-ctr, aes192-ctr,
aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc,
blowfish-cbc,
cast128-cbc, aes192-cbc, aes256-cbc, arcfour,
[email protected]]
at org.jclouds.sshj.SshjSshClient.propagate(SshjSshClient.java:385)
at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:204)
at org.jclouds.sshj.SshjSshClient.connect(SshjSshClient.java:224)
at
org.jclouds.compute.callables.RunScriptOnNodeAsInitScriptUsingSsh.call(RunScriptOnNodeAsInitScriptUsingSsh.java:72)
at
org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:121)
at
org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:49)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: net.schmizz.sshj.transport.TransportException: Unable to
reach a settlement: [] and [aes128-ctr, aes192-ctr, aes256-ctr,
arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc,
cast128-cbc,
aes192-cbc, aes256-cbc, arcfour, [email protected]]
at net.schmizz.sshj.transport.Proposal.firstMatch(Proposal.java:165)
at net.schmizz.sshj.transport.Proposal.negotiate(Proposal.java:147)
at
net.schmizz.sshj.transport.KeyExchanger.gotKexInit(KeyExchanger.java:239)
at
net.schmizz.sshj.transport.KeyExchanger.handle(KeyExchanger.java:364)
at
net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:477)
at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:127)
at net.schmizz.sshj.transport.Decoder.received(Decoder.java:195)
at net.schmizz.sshj.transport.Reader.run(Reader.java:72)
'loginUser=root' is correct but 'ssh=null' looks potentially
suspicious (although I've no idea what it refers to). I can tell from
previous Brooklyn logging that the imageId and hardwareId flags have
been correctly passed through, but I guess something's gone awry with
the keys. I have a more detailed log but haven't gone through it to
redact sensitive bits; hopefully the above executive summary is helpful.
FYI, the commit immediately prior to this on master (40b4ccd) works fine.
A.
