Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-5853

Allow Amazon EC2 Plugin to use ssh keys other than the EC2 private key

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • ec2-plugin
    • None
    • Hudson v1.348 and Hudson Amazon EC2 plugin v1.6

      I'm fairly certain that the EC2 private key is not required to launch an AMI - just the access key and secret key. I think it would be useful (and more secure for users) to allow us to add an ssh private key that's not necessarily the EC2 key. Of course this would only help those who are launching AMIs that are made with the ssh key inserted, but I think most of us that use AMIs as hudson slaves make our own.

          [JENKINS-5853] Allow Amazon EC2 Plugin to use ssh keys other than the EC2 private key

          gregcoit created issue -

          EC2 private key is used to login to the launched EC2 instance, not to launch an AMI.

          I'm not sure why it's "more secure for users" to use keys outside EC2. In fact I think it's less secure — using a key pair from EC2 allows the AMI not to be pre-baked with a particular key pair, which helps you avoid using the same key for prolonged period. You can also share the same image to different people securely.

          With that said, I suppose we could relatively easily add this support — we already let you enter a private key, so we just allow you to enter arbitrary private key, and we trust you that you know what you are doing. A warning could still be issued to let the user know that the private key doesn't match any key pair in EC2, to prevent operator errors.

          Kohsuke Kawaguchi added a comment - EC2 private key is used to login to the launched EC2 instance, not to launch an AMI. I'm not sure why it's "more secure for users" to use keys outside EC2. In fact I think it's less secure — using a key pair from EC2 allows the AMI not to be pre-baked with a particular key pair, which helps you avoid using the same key for prolonged period. You can also share the same image to different people securely. With that said, I suppose we could relatively easily add this support — we already let you enter a private key, so we just allow you to enter arbitrary private key, and we trust you that you know what you are doing. A warning could still be issued to let the user know that the private key doesn't match any key pair in EC2, to prevent operator errors.
          Kohsuke Kawaguchi made changes -
          Component/s New: ec2 [ 15625 ]
          Component/s Original: plugin [ 15491 ]

          gregcoit added a comment -

          Kohshuke,

          Our feeling is this: There's no need for root access on a slave for it to do it's job - we use an account called hudson. And we guard our ec2 private key very carefully - if someone gets access to that they get access to all our ec2 servers. Since our hudson server is in the cloud, adding the ec2 private key to it makes us nervous.

          I'm very ok with the solution you mentioned.

          gregcoit added a comment - Kohshuke, Our feeling is this: There's no need for root access on a slave for it to do it's job - we use an account called hudson. And we guard our ec2 private key very carefully - if someone gets access to that they get access to all our ec2 servers. Since our hudson server is in the cloud, adding the ec2 private key to it makes us nervous. I'm very ok with the solution you mentioned.

          lifeless added a comment -

          @gregcoit - the EC2 infrastructure uploads the key; why can't you just create a dedicated keypair called 'hudson' for EC2 - that way:

          • your hudson instances can login by specifying the 'hudson' public key component
          • your other EC2 instances still use their existing key
          • hudson cannot access your other EC2 instances.

          Note that this is ignoring the really big issue which is that a rogue hudson could stop all your important instances; the SSH key is really the least component to worry about here.

          lifeless added a comment - @gregcoit - the EC2 infrastructure uploads the key; why can't you just create a dedicated keypair called 'hudson' for EC2 - that way: your hudson instances can login by specifying the 'hudson' public key component your other EC2 instances still use their existing key hudson cannot access your other EC2 instances. Note that this is ignoring the really big issue which is that a rogue hudson could stop all your important instances; the SSH key is really the least component to worry about here.

          gregcoit added a comment -

          The overall question, I think, is why does the module restrict how it's used? Why should a user of this module not be allowed to log into their worker instances using any account and with any key they wish? I can't think of a programmatic reason, nor a functional one. Hudson itself has no restriction, why does the module?

          Of course, the fair response is "this is open source - feel free to fix it yourself". And it is fair, unfortunately, I'm allergic to java and have a doctors note saying so.

          Greg

          gregcoit added a comment - The overall question, I think, is why does the module restrict how it's used? Why should a user of this module not be allowed to log into their worker instances using any account and with any key they wish? I can't think of a programmatic reason, nor a functional one. Hudson itself has no restriction, why does the module? Of course, the fair response is "this is open source - feel free to fix it yourself". And it is fair, unfortunately, I'm allergic to java and have a doctors note saying so. Greg

          lifeless added a comment -

          I can certainly see the EC2 module being enhanced; I'm really just trying to note that the overall behaviour you want: log in with a different key - is already supported (as is logging in as non-root - though that code needs some polish - its new with the UEC support).

          As to why it restricts things, its new code, its evolved only as far as needed to make things work, so its not so much restricted as unpolished.

          lifeless added a comment - I can certainly see the EC2 module being enhanced; I'm really just trying to note that the overall behaviour you want: log in with a different key - is already supported (as is logging in as non-root - though that code needs some polish - its new with the UEC support). As to why it restricts things, its new code, its evolved only as far as needed to make things work, so its not so much restricted as unpolished.

          +1 for this. When I create my AMIs for Jenkins it has the same built-in 'ci' user as my non-ec2 slaves - configured using puppet.

          I would be fine with simply importing my existing public key into AWS and giving the contents of the private key to the ec2 plugin, but see JENKINS-15389 for why this is not possible.

          Nick Robinson-Wall added a comment - +1 for this. When I create my AMIs for Jenkins it has the same built-in 'ci' user as my non-ec2 slaves - configured using puppet. I would be fine with simply importing my existing public key into AWS and giving the contents of the private key to the ec2 plugin, but see JENKINS-15389 for why this is not possible.

          Joseph Lawson added a comment - - edited

          I too ran into this problema (JENKINS-17683) and submitted a pull request (https://github.com/jenkinsci/ec2-plugin/pull/45) which was accepted so this should be resolved at the next release. If you are feeling adventurous just get the plugin from github, compile and this should be working.

          Edit: Never mind I misread this. The patch I submitted allows you to upload the public key of any private key you have generated to EC2 and use that as the launch key.

          -Joe

          Joseph Lawson added a comment - - edited I too ran into this problema ( JENKINS-17683 ) and submitted a pull request ( https://github.com/jenkinsci/ec2-plugin/pull/45 ) which was accepted so this should be resolved at the next release. If you are feeling adventurous just get the plugin from github, compile and this should be working. Edit: Never mind I misread this. The patch I submitted allows you to upload the public key of any private key you have generated to EC2 and use that as the launch key. -Joe

          Joseph Lawson added a comment - - edited

          Seems to me the way to do this is to take the private key given and then upon startup feed it via the user-data to the authorized_keys file of the ec2-user.

          ie:

          #!
          echo ssh-rsa AAAB3N...QcGskx keyname >> ~ec2-user/.ssh/authorized_keys
          echo ssh-rsa BBRdt5...LguTtp another-key >> ~ec2-user/.ssh/authorized_keys

          From: http://stackoverflow.com/a/13202445

          Regardless, the plugin still needs an keypair to launch the instance so I feel like this is a won't implement feature and your workaround is as described.

          Edit (again . So yes EC2 doesn't need a keypair to launch an instance, just your access keys.

          Thinking about it even more, I'm going to change my opinion here. The plugin could instead, if it doesn't find the keypair match on EC2 to automatically submit the public key to the authorized_keys for the user specified. That could implement this feature.

          Joseph Lawson added a comment - - edited Seems to me the way to do this is to take the private key given and then upon startup feed it via the user-data to the authorized_keys file of the ec2-user. ie: #! echo ssh-rsa AAAB3N...QcGskx keyname >> ~ec2-user/.ssh/authorized_keys echo ssh-rsa BBRdt5...LguTtp another-key >> ~ec2-user/.ssh/authorized_keys From: http://stackoverflow.com/a/13202445 Regardless, the plugin still needs an keypair to launch the instance so I feel like this is a won't implement feature and your workaround is as described. Edit (again . So yes EC2 doesn't need a keypair to launch an instance, just your access keys. Thinking about it even more, I'm going to change my opinion here. The plugin could instead, if it doesn't find the keypair match on EC2 to automatically submit the public key to the authorized_keys for the user specified. That could implement this feature.

            Unassigned Unassigned
            gregcoit gregcoit
            Votes:
            9 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: