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.
--
Alasdair Hodge
Principal Engineer,
Cloudsoft Corporation
On 23/01/2015 09:39, Alex Heneveld wrote:
Hi folks-
I finished #465 last night [1] which refactors inferencing for login
credentials to use for jclouds-provisioned machines.
Because logging in to machines is quite important to what we do :) it
would be good to test this in a wide range of situations. If you have
some special login situations I'd appreciate it if you could test this out.
Key changes are:
* if there is an invalid key or a missing passphrase, it fails fast
* if no keys are supplied it tries the usual ~/.ssh/id_{r,d}sa, and if
those are missing or invalid it logs a message and then it creates a new
*key* (rather than a password as some images don't allow passwords)
* an explicit blank value for privateKeyFile can force use of a new key
for each host
* if a passphrase is supplied, the key is decrypted before passing it to
jclouds (previously jclouds wouldn't respect passphrases in some places)
* public keys can be extracted from private key pem files if no *.pub is
present
Also:
* you can set extra public keys to be authorized (comma separated
file/url string in brooklyn.properties or a list in yaml)
* you can supply extra first-boot commands as part of the template
options script (e.g. if sudoers file needs different treatment)
This should be totally compatible with all sensible existing
configurations, but just give more features and better feedback on bad
configs.
Best
Alex
incubator-brooklyn-pull-requests #685
<https://builds.apache.org/job/incubator-brooklyn-pull-requests/685/>
SUCCESS
Best
Alex
[1] https://github.com/apache/incubator-brooklyn/pull/465
