I'm trying to import an existing keypair from my computer to use in EC2. But once I click "Yes, Import", the fingerprint Amazon shows doesn't match the fingerprint shown by ssh -lf for the same key. I've verified that they're the same key, tried reimporting the key, etc. The common practice seems to be to use the "Create Key Pair" part instead, but I'd prefer to use my usual SSH keypair. I'm also unable to login using SSH into an instance that's set to use this keypair (I get Permission denied (publickey).).
Has anyone encountered such issues with AWS? Any insights into what the issue might be?
There seems to be an answer in the AWS forums for the fingerprint difference. I'm pasting the content here for posterity:
Hello,
I discussed with my colleagues and looks like it is a limitation from
our end to provide keypair in different format. You'll notice the
different lengths of the Amazon-generated Key Pair and the Import Key
Pair. In the case of an Amazon-generated Key Pair, the Fingerprint is
for the Private Key, while if you use Import Key Pair the fingerprint
is for your public key. Amazon does not retain a copy of the generated
Private Key, but the EC2 command line tools do provide a way to
reproduce the SSH2 MD5 fingerprint:
ec2-fingerprint-key ./testpair1-private.pem
61:26:cc:7d:2a:2c:a4:e9:fb:86:ca:ef:57:d6:68:f8:24:bc:59:cd
This should match what you see in the console for the region in which
you created the key, such as US-West-1 (North California).
Unfortunately the ec2-fingerprint-key command-line tool does not
fingerprint public keys. If you import the public key in another
region such as US-East-1, the web AWS Console will only display the
fingerprint of the public key.
Secondly, the AWS Console should be more clear on exactly what type of
fingerprint it displays, which is the "MD5 public key fingerprint as
specified in section 4 of RFC4716" (also known as SSH2 format) as
mentioned here:
http://docs.amazonwebservices.com/AWSEC2/latest/CommandLineReference/ApiReference-cmd-ImportKeyPair.html
We have already put in a feature request for the web-based AWS Console
to support the more common OpenSSH format. Unfortunately I was not
able to find any user-friendly tools to generate the SSH2/RFC4716
format fingerprint, though I did find that you can import the same
public key in your original region (with a name such as "Test2") and
match the shown fingerprint between regions.
(emphases mine)
As he mentions, I too wasn't able to locate any tool to generate the SSH2/RFC4716 format fingerprint. This at least solves the mystery of mismatching fingerprints (at least if we assume ssh-keygen -lf gives output in the "more common OpenSSH format", please correct me if this assumption is wrong); I'm still getting a Permission denied (publickey) when i try to ssh, but I'll assume it's not an actual key mismatch now and explore other avenues.
Here's an alternative way to verify finger print:
openssl pkcs8 -in my-aws-key.pem -nocrypt -topk8 -outform DER | openssl sha1 -c
Related
I have an Ethereum private key which consists of 64 bytes. I need to use this key for asymmetric encryption using p256k1 elliptic curve (the signing algorithm used on Ethereum).
This is supported on KMS now in the process of importing my key, I came across the following section in the GCP KMS documentation.
It stipulates the key must be in PKCS#8 format. I have tried a couple of commands using openssl. like the following
openssl pkcs8 -topk8 -in ./private.pem -outform DER -out ./private.key
Here is my private.pem format
-----BEGIN PRIVATE KEY-----
64_CHAR_PRIVATE_KEY_PASTED_HERE
-----END PRIVATE KEY-----
I understand this might not be the correct way to convert as errors happen when I run this command.
unable to load key
4456490668:error:0DFFF07B:asn1 encoding routines:CRYPTO_internal:header too long:/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75/libressl-2.8/crypto/asn1/asn1_lib.c:152:
4456490668:error:0DFFF066:asn1 encoding routines:CRYPTO_internal:bad object header:/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75/libressl-2.8/crypto/asn1/tasn_dec.c:1132:
4456490668:error:0DFFF03A:asn1 encoding routines:CRYPTO_internal:nested asn1 error:/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75/libressl-2.8/crypto/asn1/tasn_dec.c:317:Type=PKCS8_PRIV_KEY_INFO
4456490668:error:09FFF00D:PEM routines:CRYPTO_internal:ASN1 lib:/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75/libressl-2.8/crypto/pem/pem_pkey.c:143:
My goal remains to be able to import the key into KMS as securely as possible. Thank you in advance for your responses :D
So for anyone, who might deal with something similar. John Hanley pointed me to this link which describes the process of basically converting a Ethereum private key into a EC PEM or DER encoded key file.
A couple of strings need to be added (The linked answer does a good job at explaining it). I was able to then convert EC PEM to PKCS#8 DER format which is what I needed for importing the key to GCP KMS.
I have a complete solution for this, but it uses python instead of openssl.
It has 4 main functions.
1 - Create an Import job in GCP KMS
2 - Convert the Ethereum key to PKCS#8 DER and wrap it with the Import job's wrapping key
3 - Upload it to GCP KMS
4 - Send a GCP-KMS-HSM-signed test transaction on your choice of chain.
I suggest converting the key and wrapping it offline or on a secure boot image like Tails.
Read the code first, and use a throwaway pk to test. I hope this helps.
https://github.com/TMCTG/GCP-KMS-ETH-Private-Key-Import-Sign-Tx
We have RSA key pairs generated on on-prem and plan to sync them to GCP-KMS. There is an yearly key rotation policy which would be done on on-prem and new key_versions would be synced to KMS. My concern is with the KMS API.
Problem: The API always asks for the 'key_version' as an argument to encrypt/decrypt a file.
Desired behaviour: During decryption, is it not possible that the KMS sees the certificate thumbprint and returns the appropriate key version to decrypt a given encrypted file? e.g. a DEK wrapped with the RSA_public when supplied to KMS gets decrypted by the RSA_Private(or KEK) of the correct version.
If yes, is there any documentation that elaborates on this use case?
According to the documentation, you can achieve that with symmetric signature (no key version specified), but you can't with the asymetricDecrypt (key version is required in the URL path of the API)
While trying out on a POC with GCP DLP, facing the below issue:
log:
Received the following error message from Cloud KMS when unwrapping KmsWrappedCryptoKey
"projects/<<PROJECT_ID>>/locations/global/keyRings/<<KMS_KEY_RING>>/cryptoKeys
/<<KMS_KEY_NAME>>": Decryption failed: the ciphertext is invalid.
I have just created the key and key ring using the generate key option in KMS and a basic DLP template to Pseudoanaonymize the data with cryptographic deterministic token. The wrapped key I gave is a simple base-64 format key. When testing out this template in console with the data, I am facing this issue. The same issue is replicated in the application logs when trying to encrypt the data.
P.S: We have tried out generating a manual key using Open SSL and importing it into the KMS. We are still facing this issue.
Attaching a screen shot for reference :
Figured out the issue in this case.
The issue was with the way we created the wrapped key which we gave in the DLP template. Below are the steps to generate the wrapped key:
Choose the wrapped key (could be anything. A string, random text etc)
Encrypt the wrapped key in above step using the KMS key that you are going to use in the DLP template.
Convert the above encrypted key into base 64 format and use this in the DLP template.
Below are the commands for above steps in the same order:
openssl rand 16 > secret.txt
This generates random string of 16 bytes. The size had to be one of 16,24,32 (mandatory)
gcloud kms encrypt --location global --keyring <key-ring-name> --key \
<key-name> --plaintext-file secret.txt --ciphertext-file \
mysecret.txt.encrypted
This encrpts the random string.
base64 mysecret.txt.encrypted
Use this in the DLP template.
This answer helped me figure out the issue : https://stackoverflow.com/a/60513800/6908062
I recently changed the region of my EC2 instance via creating an AMI of the previous instance and sending it to the new region and launching a new instance from it. However, it now uses the key in the key pair in the old region.
In order to avoid confusion for myself in the future, I want to move the key from the key pair in the old region to the new region (so I have everything in the same region)
I can import the key into the new region, but to do so I need the public key. Question is, I have no idea how to get the public key. I've Googled and looked everywhere, can't find how to get the public half of my key on file so I can import it in the new region
How do I get the public key file?
Thanks in advance
Found the answer.
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html#retrieving-the-public-key-windows
On your local Windows computer, you can use PuTTYgen to get the public key for your key pair.
Start PuTTYgen, choose Load, and select the .ppk or .pem file. PuTTYgen displays the public key.
Thank you, anyway
If you can login to the ec2 instance, you should be able to go to your ~/.ssh folder. You should see something like this:
You need to know the name of your public key. In my case, this is id_rsa.pub. Now you can open a terminal on your local computer and use scp command to copy the file into your local.
l$ scp -i ~/.ssh/your_key.pem your_user_name#11.12.123.34:/home/your_user_name/.ssh/id_rsa.pub ~/Desktop
id_rsa.pub 100% 405 16.5KB/s 00:00
Now you should have the public key on your Desktop. Now you can go the new EC2, login into it (using password) and copy and paste the text in the id_rsa.pub into any file you want.
I lost my .pem file due to which I am not able to login to my ec2 instance. Luckily I had my machine key added to the auth_keys file, so I am able to login using it. I removed the master pub key from the auth_keys file and restarted sshd service. But my colleague who is having the master.pem key file is still able to login to the instance. Am I missing something to disable the complete access to the instance using the master.pem file.
Please advice.
Thanks
Does the auth_keys file exist in two places? Maybe you deleted the wrong one? Maybe you should try changing the fingerprint of the server.
New commentary: removing the public key doesn't affect the private key. The master pem file may be associated with the private key. If the private key remains, other public keys will still work. The topic says "Remove key pair." But the description doesn't indicate removing the private key.