Permit re-using AWS keypair #1837
Conversation
Adds a 'ssh_keypair_name' option to the configuration for AWS, along with some munging to create the temporarily keypair if one isn't specific. NOT YET WORKING. From a 'make' I get the following errors: builder/amazon/ebs/builder.go:94: b.config.SSHKeyPairName undefined (type config has no field or method SSHKeyPairName) builder/amazon/instance/builder.go:199: b.config.SSHKeyPairName undefined (type Config has no field or method SSHKeyPairName)
These changes permit the use of pre-created SSH keypairs with AWS. If so, the configuration for the builder needs to include an ssh_keypair_name option and a ssh_private_key_file. If ssh_private_key_file is *not* defined, it'll go through the rigamarole of creating a temporary keypair. The ssh_keypair_name option by itself won't make that change, because it doesn't make sense to specify a keypair but not tell packer where the private key is, but it does happen that you could have a private key and the public-key is "baked in", and not part of your EC2 account.
|
The problem I see with pre-created keypair is that the fingerprint stays in authorized_keys after baking, therefore instancess will be reachable with the baking key. Other than that, I can see indentation problems in code. |
|
I wondered about the formatting, turns out that |
|
As for your first comment - the For me specifically, it is useful, since I'm changing the |
|
@nyetsche The side-effect of leaving baking keys in authorized_key isn't that clear for everyone and I guess default behaviour should be to delete it after baking. |
|
I concur, the default behavior remains the same. The line https://github.com/nyetsche/packer/blob/9d097f9d4ef331adac5f322d14ca185e879331a0/builder/amazon/common/step_key_pair.go#L24 remains the same as in mitchellh/master ; if |
|
@nyetsche Yes, it is the same and authorized_keys will have the baking key in it. Normally, packer doesn't save the secret key during baking, making authorized_keys entry useless. For permanent keys you posses to the PrivateKeyFile and therefore you will have access to all instances started from the AMI, which is not a desirable behaviour. |
|
I think it's against the main point that making assumptions about how infrastructure should be left out. Not all infrastructures are the same, so tools like packer should make no assumptions. |
|
LGTM! |
ghost
locked and limited conversation to collaborators
For various reasons not everyone wants to create and delete a keypair each time an AWS provisioner runs. I see an issue here: #1635 and a slightly different one here: #1697.
This PR adds a
ssh_keypair_nameoption that is used by AWS "instance" and "ebs" builders, the previousssh_private_key_fileoption remains as-is.If
ssh_keypair_nameis unset (internally seen as to "") ANDssh_private_key_fileis unset; the AWS builders default to creating and deleting a temporary keypair.This is my first attempt Go code, so apologies for any amateur mistakes. It took me a while to realize that I needed to clone the main repo and add my fork as a remote, so that the
import ( "github.com/mitchellh/packer/[...]" )etc. statements worked.