brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Hodge <alasdair.ho...@cloudsoftcorp.com>
Subject Re: new jclouds/login features
Date Tue, 10 Feb 2015 18:53:43 GMT
$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,
> rijndael-cbc@lysator.liu.se]

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,
>>> rijndael-cbc@lysator.liu.se]
>>>     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, rijndael-cbc@lysator.liu.se]
>>>     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.
>


Mime
View raw message