Specifying SSH key for AWS provider is not used #7432
Assignees
Labels
Projects
Milestone
Comments
|
hi @RunningJon - Can you confirm the steps you followed? It seems like you selected "Provide custom keypair information". Did you enter the custom keypair name / pem key etc? I created #7536 to track the ability to specify the username part. This issue will be used to address custom key-pair not being used.
|
|
Yes, I picked "Provide custom KeyPair information" and then picked an existing Keypair name and uploaded the PEM config file. It was ignored. Also, if the AMI being used has a different cloud-init user other than centos, you have to pick customer KeyPair information so the SSH User parameter is exposed. The SSH User parameter should be tied to the AMI, not the KeyPair. |
artem-mindrov
added a commit
that referenced
this issue
Apr 28, 2021
Summary:
1. Fix PEM content wrongly treated as JSON during form submission
2. Only allow PEM files up to 256Kb
3. Make PEM file required if custom keypair is chosen
4. Fix error message rendering against labeled drop zones
5. Fix parameter handling in CloudAccessKeySetup (ssh keys were only used if user and key pair name
were specified, and even then the key file was left hanging in /tmp)
6. Don't leave empty /opt/yugaware/keys/{uuid} when the provider is deleted
Test Plan:
1. When creating an AWS provider, choose to use a custom key pair and try to submit without
uploading a private key. Expected: validation error displayed over the drop zone.
2. Supply a private key file, leave optional fields blank. They should get assigned default values
as before.
3. Create a universe in this provider.
4. Use your private key to connect to a node in the universe.
5. Delete the universe and the provider, make sure that the keys directory no longer has a subdir
for the deleted provider.
6. Verify that the normal workflow of creating a GCP provider works as well.
For AWS, GCP and Azure:
1. Create a cloud provider. For AWS, specify multiple regions.
2. Verify that the keys were stored.
3. Delete the provider.
4. Verify that the keys were removed. For AWS, also check that none of the regions used in step 1 have the key.
Reviewers: wesley, andrew
Reviewed By: andrew
Subscribers: jenkins-bot
Differential Revision: https://phabricator.dev.yugabyte.com/D11241
|
Validated this issue on build 2.7.1.0-b184 with following steps
cc @VijiYB |
YintongMa
pushed a commit
to YintongMa/yugabyte-db
that referenced
this issue
May 26, 2021
Summary:
1. Fix PEM content wrongly treated as JSON during form submission
2. Only allow PEM files up to 256Kb
3. Make PEM file required if custom keypair is chosen
4. Fix error message rendering against labeled drop zones
5. Fix parameter handling in CloudAccessKeySetup (ssh keys were only used if user and key pair name
were specified, and even then the key file was left hanging in /tmp)
6. Don't leave empty /opt/yugaware/keys/{uuid} when the provider is deleted
Test Plan:
1. When creating an AWS provider, choose to use a custom key pair and try to submit without
uploading a private key. Expected: validation error displayed over the drop zone.
2. Supply a private key file, leave optional fields blank. They should get assigned default values
as before.
3. Create a universe in this provider.
4. Use your private key to connect to a node in the universe.
5. Delete the universe and the provider, make sure that the keys directory no longer has a subdir
for the deleted provider.
6. Verify that the normal workflow of creating a GCP provider works as well.
For AWS, GCP and Azure:
1. Create a cloud provider. For AWS, specify multiple regions.
2. Verify that the keys were stored.
3. Delete the provider.
4. Verify that the keys were removed. For AWS, also check that none of the regions used in step 1 have the key.
Reviewers: wesley, andrew
Reviewed By: andrew
Subscribers: jenkins-bot
Differential Revision: https://phabricator.dev.yugabyte.com/D11241
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The option to specify an existing SSH key for an AWS config is not used. The username is correctly used but the ssh key name and private key supplied are ignored. I confirmed the username is working by creating an AMI with the cloud user of "opc" for Oracle Enterprise Linux testing. This works but the ssh key name isn't used.
I confirmed his problem using 2.5.2 and specified my existing SSH key. The VMs created for the universe use a keypair created by Platform and you can see this with describe-instances or in the AWS console.
The UI should also allow a user to specify the username but still let Yugabyte manage the keys. The username could be any number of values from centos, ec2-user, opc, or any other default username a customer may use in their AMI.
The text was updated successfully, but these errors were encountered: