jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-1356) jclouds occasionally can't log in to AWS EC2 instance
Date Thu, 16 Nov 2017 09:11:00 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254983#comment-16254983
] 

ASF GitHub Bot commented on JCLOUDS-1356:
-----------------------------------------

Github user andreaturli commented on a diff in the pull request:

    https://github.com/apache/brooklyn-docs/pull/237#discussion_r151353928
  
    --- Diff: guide/locations/_AWS.md ---
    @@ -43,6 +43,51 @@ Below are examples of configuration options that use values specific
to AWS EC2:
       For example, `securityGroups: mygroup1` or `securityGroups: [ mygroup1, mygroup2 ]`.
     
     
    +### Using a Registered Key Pair
    +
    +You can specify a `keyPair` to use for initial provisioning as a configuration option.
    +If this is omitted, Brooklyn will use jclouds to create a new ad hoc key pair at AWS
    +for that machine, and it will delete it afterwards.  This is usually seamless and
    +occurs behind the scenes, with the post-provision user set up and configured as normal
    +for all locations.  However if you are optimizing for creation of many machines,
    +or you are using an image where keypair installation is not reliable (such as [some
    +RightImages](https://issues.apache.org/jira/browse/JCLOUDS-1356)), then you may wish
    +to use a registered key pair.
    +
    +First, in the AWS Console, open the EC2 service in the region you are interested in,
    +then click "Key Pairs" at the left.  For `us-east-1`, the link is 
    +[here](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#KeyPairs:sort=keyName).
    +Click "Create Key Pair" (or "Import Key Pair" if you want to provide a public key) and
    +follow the instructions.
    +
    +Then define your location as follows for `aws-us-east-1`.  Make sure to replace the
    +`XXXX` sections with the key-pair name defined above and the corresponding private key
data. 
    +
    +```yaml
    +brooklyn.catalog:
    +  version: "1.0"
    +  itemType: location
    +  items:
    +  - id: aws-base
    +    item:
    +      type: jclouds:aws-ec2
    +      brooklyn.config:
    +        identity: XXXXXXXXXXXXXXXX
    +        credential: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
    +  - id: aws-us-east-1
    +    item:
    +      type: aws-base
    +      region: us-east-1
    +      keyPair: XXXXXXXXX
    +      login.privateKeyData: |
    --- End diff --
    
    isn't `loginUser.privateKeyData`? there is also `loginUser.privateKeyFile` which can maybe
be more convenient in some cases.


> jclouds occasionally can't log in to AWS EC2 instance
> -----------------------------------------------------
>
>                 Key: JCLOUDS-1356
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1356
>             Project: jclouds
>          Issue Type: Bug
>    Affects Versions: 2.0.2
>         Environment: Amazon, CentOS RightImage
>            Reporter: Alex Heneveld
>
> I call to create a machine in AWS with basic settings (unique key pair and security group),
and jclouds ultimately comes back failing with:
> {code}
> 2017-11-15T11:22:10,546 ERROR 107 j.compute [user thread 3] << problem customizing
node(us-east-1/i-00fc246bb83203e67): 
> org.jclouds.rest.AuthorizationException: (root:rsa[fingerprint(fc:4f:57:c5:e6:db:00:f5:39:7b:f5:6b:1b:de:cf:fa),sha1(87:28:ea:42:e7:9f:6b:45:4a:ce:09:0a:30:02:46:ee:95:fa:b2:16)]@54.210.213.222:22)
(root:rsa[fingerprint(fc:4f:57:c5:e6:db:00:f5:39:7b:f5:6b:1b:de:cf:fa),sha1(87:28:ea:42:e7:9f:6b:45:4a:ce:09:0a:30:02:46:ee:95:fa:b2:16)]@54.210.213.222:22)
error acquiring {hostAndPort=54.210.213.222:22, loginUser=root, ssh=null, connectTimeout=60000,
sessionTimeout=60000} (out of retries - max 50): Exhausted available authentication methods
>         at org.jclouds.sshj.SshjSshClient.propagate(SshjSshClient.java:394) [108:jclouds-sshj:2.0.2]
>         at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:205) [108:jclouds-sshj:2.0.2]
>         at org.jclouds.sshj.SshjSshClient.connect(SshjSshClient.java:224) [108:jclouds-sshj:2.0.2]
>         at org.jclouds.compute.callables.RunScriptOnNodeAsInitScriptUsingSsh.call(RunScriptOnNodeAsInitScriptUsingSsh.java:72)
[100:jclouds-compute:2.0.2]
>         at org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:123)
[100:jclouds-compute:2.0.2]
>         at org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:50)
[100:jclouds-compute:2.0.2]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:?]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:?]
>         at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication
methods
>         at net.schmizz.sshj.SSHClient.auth(SSHClient.java:217) ~[?:?]
>         at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:316) ~[?:?]
>         at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:335) ~[?:?]
>         at org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:163)
~[?:?]
>         at org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:49) ~[?:?]
>         at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:195) ~[?:?]
>         ... 8 more
> {code}
> The machine _is_ created in AWS, and accessible on 22, just it doesn't like jclouds attempting
to log in.
> This is using imageId us-east-1/ami-5492ba3c - autodetected looking for a CentOS 7.0
machine from one of a set of trusted providers (including Rightscale who provide this).
> Most of the time it works fine.  It's <5% of such requests which fail.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message