There are a couple things to consider here: how the "authorizePublicKey" behaves has never been formalised, and I agree we should do that. Let's use this thread to come to a consensus we are all happy with.
I think the main point to discuss is whether jclouds should *always* create a (hidden) key pair so jclouds itself has access to the node, or it should just create it *when requested*. The current and more recent implementations assume the latter, based on how the aws-ec2 provider, which was the most used, behaved (see [1]). DigitalOcean [2] and GCE [3] assumed similar strategies, which could be described as: * Do not automatically create a key pair for jclouds if the user specifies a custom key. If the user provides a public key, just install it, but don't install an additional (hidden) one created by jclouds, to be used by jclouds. We assume users want a restricted access to the nodes they provision. * If the user does not provide ssh keys and the "auto generate key pair option" (in DO and GCE) is enabled, then auto-generate a new key pair for jclouds. Both approaches have their limitations: * Always creating a key pair by default may not be desired by users, as nodes could end up with authorised keys that are not controlled by them. * Not creating a keypair for jclouds can leave the node inaccessible unless the user explicitly provides the corresponding private key (which makes sense) or the key is already loaded in the ssh-agent. The latter is the issue you are experiencing, but take into account that the provided public key is *always* configured (see [4]). What happens is that jclouds is missing the private key and can't connect to the node (unless it is already loaded in the ssh-agent). This said, I think the current approach makes sense (in fact both make sense), but can be changed if always creating a key pair for jclouds seems a better idea. There was already JCLOUDS-468 [5] to fix Nova the same way, but we could reformulate the issue to align all compute providers to behave the same way. Regarding the "multiline string proposal", I'd suggest we change the option to accept a varargs argument. This way the option would be better understandable and easier to use (most providers don't just write the authorized_keys file but create keypairs using their API so we'd have to parse that string), and would still be backwards compatible. Let's discuss how we want this to behave! I. [1] https://github.com/jclouds/jclouds/blob/master/providers/aws-ec2/src/main/java/org/jclouds/aws/ec2/compute/strategy/CreateKeyPairPlacementAndSecurityGroupsAsNeededAndReturnRunOptions.java#L122-L139 [2] https://github.com/jclouds/jclouds-labs/blob/master/digitalocean2/src/main/java/org/jclouds/digitalocean2/compute/strategy/CreateKeyPairsThenCreateNodes.java#L98-L114 [3] https://github.com/jclouds/jclouds/blob/master/providers/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/strategy/CreateNodesWithGroupEncodedIntoNameThenAddToSet.java#L116-L127 [4] https://github.com/jclouds/jclouds/blob/master/providers/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/GoogleComputeEngineServiceAdapter.java#L155-L158 [5] https://issues.apache.org/jira/browse/JCLOUDS-468 On 29 August 2015 at 03:42, Alex Heneveld <alex.henev...@cloudsoftcorp.com> wrote: > > Hi All- > > I'm noticing something strange with google-compute-engine and > `TemplateOptions.authorizePublicKey(key)`. > > I assumed this is meant to allow a user to supply an *additional* public key > to be authorized on the machine. Is this right? > > In google-compute-engine, if you set this, jclouds is not able to ssh in > (and provisioning fails) unless you also TO.overrideLoginPrivateKey with the > corresponding private key, and that becomes the *only* mechanism enabled on > the machine. GCE's CreateNodesWithGroupEncodedIntoNameThenAddToSet uses > this as the primary/default mechanism for access: > > // Configure the default credentials, if needed > if (templateOptions.autoCreateKeyPair() && > Strings.isNullOrEmpty(templateOptions.getPublicKey())) { > logger.debug(">> creating default keypair..."); > Map<String, String> defaultKeys = keyGenerator.get(); > templateOptions.authorizePublicKey(defaultKeys.get("public")); > templateOptions.overrideLoginPrivateKey(defaultKeys.get("private")); > } > > I think this should be changed so that defaultKeys is installed unless > *overrideLoginPrivateKey* is set. And anything the caller supplies in > templateOptions.getPublicKey() should be kept, in addition, I think. > However there is no formal mechanism within TO.authorizePublicKey for > setting multiple keys. Although in practice you can for most clouds supply > multiple public keys, one per line. (See e.g. how > TemplateOptionsToStatement is implemented.) > > If we formalize this requirement, that authorizePrivateKey(...) respect a > multi-line string, then I think it becomes pretty easy to fix this problem > in GCE, with the above tweak in CreateNodes.... and fix the formatting of > "sshKeys" in GoogleComputeEngineServiceAdapter accordingly. > > Does this seem reasonable? > > Are there any other cloud providers who do custom things with the > "publicKey" in TO? > > Best > Alex > > > -- > Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. > Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP > > This e-mail message is confidential and for use by the addressee only. If > the message is received by anyone other than the addressee, please return > the message to the sender by replying to it and then delete the message from > your computer. Internet e-mails are not necessarily secure. Cloudsoft > Corporation Limited does not accept responsibility for changes made to this > message after it was sent. > > Whilst all reasonable care has been taken to avoid the transmission of > viruses, it is the responsibility of the recipient to ensure that the onward > transmission, opening or use of this message and any attachments will not > adversely affect its systems or data. No responsibility is accepted by > Cloudsoft Corporation Limited in this regard and the recipient should carry > out such virus and other checks as it considers appropriate.
