Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 alex.heneveld@cloudsoftcorp.com designates 209.85.212.170 as permitted
 sender)
From: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Message-ID: <54DA5255.1000304@CloudsoftCorp.com>
Date: Tue, 10 Feb 2015 18:47:49 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dev@brooklyn.incubator.apache.org
Subject: Re: new jclouds/login features
References: <apache/incubator-brooklyn/pull/465@github.com>
 <apache/incubator-brooklyn/pull/465/c71165826@github.com>
 <54C216C1.3010804@CloudsoftCorp.com> <54DA4EF3.1090007@cloudsoftcorp.com>
In-Reply-To: <54DA4EF3.1090007@cloudsoftcorp.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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.