binxio/cfn-secret-provider

Failed to decrypt the password for a Windows EC2 instance using the keypair

Closed this issue · 7 comments

I am using the example code to create a keypair that is then associated with a Windows EC2 instance.

When accessing the private key in the SSM parameter store the output is as such:
-----BEGIN PRIVATE KEY----- MIIEwAIBADANBgkqhkiG9w0BAQEFAASCBKowggSmAgEAAoIBAQDQ80SY1C5zcjhQ
...SNIP...
-----END PRIVATE KEY-----

Trying to use this to decrypt the password fails with the following error:
Error decrypting your password
Private key must begin with "-----BEGIN RSA PRIVATE KEY-----" and end with "-----END RSA PRIVATE KEY-----"

Changing the key to use -----BEGIN RSA PRIVATE KEY----- still fails with the following error:
Error decrypting your password
There was an error decrypting your password. Please ensure that you have entered your private key correctly.

The relevant parts of the cloud formation template I am using are:

PrivateKey:
   Type: 'Custom::RSAKey'
    Properties:
        Name: !Sub 
                - '/ec2-keypairs/${environmentType}/${AWS::StackName}-privatekey'
                - environmentType: !FindInMap
                  - EnvironmentConfigs
                  - !Ref 'AWS::AccountId'
                  - EnvironmentType
        Version: v1
        KeyAlias: !Sub '${AWS::StackName}-privatekey'
        ServiceToken: !Sub 'arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:binxio-cfn-secret-provider'
  KeyPair:
    Type: Custom::KeyPair
    DependsOn: PrivateKey
    Properties:
      Name: !Sub 
              - '${environmentType}-${AWS::StackName}-keypair'
              - environmentType: !FindInMap
                - EnvironmentConfigs
                - !Ref 'AWS::AccountId'
                - EnvironmentType
      PublicKeyMaterial: !GetAtt 'PrivateKey.PublicKey'
      ServiceToken: !Sub 'arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:binxio-cfn-secret-provider'

Am I doing something wrong here ? I have double checked the article here (https://binx.io/blog/2017/10/25/deploying-private-key-pairs-with-aws-cloudformation/) and the docs in the repo but cannot see anything obvious. Thanks.

Hi,

The private key is stored in PKCS8 format. Apparently the AWS cli tool expects the traditional OpenSSL (PKCS1) format for the private key.

You can easily convert this key to the expected format of get-password-data.

aws --query Parameter.Value --output text ssm get-parameter --name my-private-key --with-decryption | openssl rsa > my-private-key.pem

or

openssl rsa -in my-private-key.pem -out my-private-key-pkcs1.pem

Let me know if this helps...

Cheers,

Mark

Thank you, that works fine. Is there another purpose for the private key that means it needs to be stored as it currently is or is it worth modifying the Lambda function to store it in this format natively in parameter store rather than requiring that extra step?

Thanks

Carl

Hi @reidca , I cannot change the default behaviour for backward compatibility. Adding a switch will just introduce another path in the code.

if you want to submit a PR for it, I am willing to review & merge it.

Thanks for replying again.

I am curious what the original purpose of storing the key in the existing format that it stored in was? The only use cases I can see are for key pairs and in the case of both Windows Get-Password functionality and Linux SSH the format needs to be PKCS1.

Whilst I understand the need for backwards, in the case of the the primary purpose for this could this not be considered a "bug" rather than a change?

Whilst I am here please accept my gratitude for what you have done here, it is very useful as is your support.

Original the private key was generated for use in signing JWT tokens validated by the Kong API Gateway. The next used case was to add the public key as keypair in EC2.
The private key as stored, can be used directly to ssh into the machine:

install -m 0600 mykey
aws --query Parameter.Value --output text ssm get-parameter \
    --name /demo/private-key --with-decryption > mykey
ssh -i mykey ec2-user@bastion

I will spent a few minute to experiment with an extra option..

In release v0.11.0 you can specify the KeyFormat to TraditionalOpenSSL to get the format you need.