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.
