Unprotected private keys in Windows

Posted: 25 May, 2020 Category: hassles Tagged: windowscryptographykeysssh

(*nix variant OSters, you are allowed to snigger derisively throughout this section. Microsoft is rich. They won't care.)

I ran into this while trying to supply a key-pair to the Secure Shell App Chrome Extension, to connect to a test EC2 instance. In my case, the keys were generated in AWS, which of course lets you download the private key... i.e. half of the keypair... so you have to first generate a counterpart public key whenever you need the complete pair. To do this, you open a command prompt and navigate to wherever you downloaded the .pem key file. Then you're supposed to just do:

ssh-keygen -y -f keyname.pem > keyname.pub

where keyname is whatever you key file is named, and:

  • -y : This option will read a private OpenSSH format file and print an OpenSSH public key to stdout.
  • -f : allows you to specify the input (private key) file

If everything worked without glitches you should now lock down your private key by removing the .pem suffix.

Otoh, Windows may have barf thusly:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'foo.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "foo.pem": bad permissions

So.... while folks on other Oses can simply chmod 400 their pem file to lock it down and get on with life, NOT SO FAST, win users. not. so. fast. You have to:

  • right-click on the offending .pem file
  • nav to properties > security > advanced security options
  • disable "inherited permissions" completely
  • nuke everyone, make yourself the sole user with permissions for this file
  • apply all changes and close the dialog boxes
  • rerun the command above which face-planted; it should work now, and quietly.
  • delete the .pem extension off of your private key for good measure.

After all the above shenaniganry, you can click to import both (yes, select both) when setting up your connection to the EC2 instance via the Secure Shell App. It will use this keypair as your identity henceforth.