Re: new jclouds/login features

Tue, 10 Feb 2015 10:50:40 -0800 


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.

Reply via email to