35

So a while ago I set up a server on AWS, and used their generated SSH key. I saved the key to Lastpass, and have successfully retrieved it from there before, and got it working. However, after trying that again today, I can't get it to work.

-rw------- 1 itsgreg users 1674 Jun 6 12:51 key_name

I've tried ssh -i key_name, ssh-keygen -f key_name, but nothing works, I always get this error message:

Load key "key_name": invalid format

Is there any way to fix this?

  • just noticed something: it should be chmoded 0400 (read-only). It looks like it's not here, since user has the write privilege. – pixeline May 22 at 15:27

17 Answers 17

17

Check the contents of key_name, if the agent says invalid format, then there's something wrong with the key - like .. are you sure that's the correct key? Even if it's not the private key you need, the ssh agent won't return invalid format if the key is working, you simply won't be able to connect. You might have placed your public key in there, for some reason. Check it!

| improve this answer | |
  • 8
    Definitely checked. Starts with ----BEGIN RSA PRIVATE KEY----- and ends with -----END RSA PRIVATE KEY-----. Plus it used to work. – Gregor Menih Jun 6 '17 at 12:35
  • 2
    A highly unlikely, but still possible, is that the file is corrupted. Create a new one and populate the contents again from lastpass. – 13dimitar Jun 6 '17 at 12:43
  • 5
    Wow, that actually helped! After generating the new key, I noticed that the new key had 64 characters per line whereas my old key had 76. I reformatted my old key to only have 64 characters per line, then it started working! I was also missing one dash from the first line. – Gregor Menih Jun 6 '17 at 12:57
  • 2
    "I was also missing one dash from the first line." Ditto. Thank you @ItsGreg for that. I miss the first character so often when selecting and copying between terminals! – starfry Nov 30 '18 at 14:30
  • Mine was simply empty ?!?! – gebbissimo Jul 1 at 15:16
24

What i did to fix this issue is that i use to convert the PPK file using PuttyGen.

First load the urkey.PPK, then on the conversion menu, click export to Openssh file format. It will create newkey file.

now, ssh -i "newkey" user@127.0.0.1

Done. Hope it helps.

| improve this answer | |
  • 1
    Here's how to do this on a Mac Terminal (assuming you have Brew installed): brew install putty && puttygen ~/.ssh/my-key-name.ppk -O private-openssh -o ~/.ssh/my-key-name – Chris Gillatt Apr 21 at 11:33
14

I had the same issue, and it turns out I had Windows-style (CRLF) line separators in the file for some reason.

In addition, the file must end with a single LF.

Fixing those made things dandy again.

| improve this answer | |
  • It's shocking that that final LF is so necessary, but it was indeed partially the issue, with the other part being that I created the file in Windows and doing so gives it CRLF line breaks. For the reference of others, dos2unix is the command to convert from CRLF (Windows-style) to LF (Linux-style) line breaks. – Prometheus Aug 10 '19 at 13:15
  • Thanks !!!!! I spent all day to find that solution. – Omtechguy Jan 20 at 21:44
  • Thank you so much, I used Notepad++ to do the EOL conversion and problem solved! – Gavin Sinai Feb 10 at 9:49
6

I was asking openssh to use a particular identity file by specifying it in .ssh/config file.

The original working configuration had

IdentityFile = <path to public key file> 

This stopped working without any changes. On a little thinking I replaced the "path to public key file" above with "path to private key file" . That worked. The reasoning is that both public and private key files have large peudoprime related numbers as per the RSA algorithm. If you replace the private key file by public key file, these cryptographic numbers would not be extracted correctly from the base64 block saved within the key files. It seems some versions of ssh can figure out the .pub extension and use it to identify the correct private key file - and other versions dont do that. This is another way this error can happen. Hope it helps someone.

| improve this answer | |
  • In my case, I had setup config file with path_to_public_key and everything was working. However when the mac did a hard restart and a few days later I tried to do a git push, I started getting the error stated above. But when I now changed it to path_to_private_key things are working... Hmmm. Not sure why.. – lukik May 27 '19 at 0:15
  • Yeah, pointed to private key and all good now. Thanks. – Murwa Jan 30 at 16:57
  • Wow, it helped, you saved my day! – Mixaz Jan 31 at 22:47
  • It has to be a private key file for the IdentityFile section. – Yuki Matsukura Mar 29 at 7:24
6

After a recent update in Fedora 32 I started to get this warnings when connecting to remote hosts.

I solved the problem adding pkcs11: to the IdentityFile parameter in my .ssh/config like this:

IdentityFile pkcs11:~/.ssh/my_key.pem 

For reference, excerpt from ssh_config man page:

The authentication identity can be also specified in a form of PKCS#11 URI starting with a string pkcs11:.

| improve this answer | |
  • 2
    this solved the issue for me, when running on Fedora 32 and connecting to Amazon EC2. Thanks for sharing! – Kevin Jun 10 at 12:35
  • What openssh version does this use? On OpenSSH_8.3p1 the pkcs11: prefix is not recognized and it tells me "no such file or directory pkcs11:/my/file.pem". But I seem to be having the same issue: the warning and things like line endings, adding a newline at the end, etc. don't fix it. – Luc Jun 15 at 9:38
  • openssh-8.3p1-2.fc32.x86_64 IdentityFile pkcs11:/home/vquintans/.ssh/vquintans.pem – vquintans Jun 16 at 10:54
  • 2
    Weirdly I get the warning, but can login. Adding pkcs11: fixes the warning, but prevents me logging in, as if the key is now wrong. Trying to ssh to AWS EC2 from fedora 32 – Nigel Atkinson Jun 23 at 1:47
3

You should convert your .ppk key to OpenSSH key

Here is how you do it:

  1. Download PuttyGen and generate your keypair (if you don't have keypair ready). Save private key to your folder (.ppk)
  2. If you are already had the private key, load the private key file (.ppk) by pressing the "Load" Button. Otherwise, skip this step
  3. Under menu "Conversions", choose Export OpenSSH key then save it to your folder
  4. Now you are ready to use the key to login your server without typing the password (I assume you already put the public key under /root/.ssh/authorized_keys, chmod 600 /root/.ssh/authorized_keys, And Restarted SSH demon )
| improve this answer | |
  • Thank you! This works! – Player1 Feb 18 at 23:03
  • I had to re-install all my applications, and keys that once worked started doing this. My solution was similar, except I had to pick "Export OpenSSH key (force new file format)". The regular "Export OpenSSH key" generated the same key that didn't work. – BrianVPS Jul 16 at 18:00
2

I just ran into this today when was writing some git tagging utils for my CI pipeline.

Here was the difference between my two keys:

$ diff ~/.ssh/gitlab ~/.ssh/git_ssh_key
27c27
< -----END OPENSSH PRIVATE KEY-----
---
> -----END OPENSSH PRIVATE KEY-----
\ No newline at end of file

I changed my code like so:

     with open(ssh_key_file, 'w') as skf:
-        skf.write(ssh_key)
+        skf.write(ssh_key + '\n')

And now my ssh key works.

TL;DR - I guess you have to have a newline at the end of your private key.

| improve this answer | |
2

In my case, it turned out that I had newlines between the start/end "headers" and the key data:

-----BEGIN RSA PRIVATE KEY-----

- Key data here -

-----END RSA PRIVATE KEY-----

Removing the extra new lines, so it became

-----BEGIN RSA PRIVATE KEY-----
- Key data here -
-----END RSA PRIVATE KEY-----

solved my problem.

| improve this answer | |
0

Use your private key instead of the public key.

| improve this answer | |
  • same solution as my answer - where an explanation is also added – vpathak Apr 17 '18 at 12:43
0

I had this issue because I had a key in ~/.ssh that actually was an invalid format and I had a lot of keys, which meant SSH was trying them all, even though I specified my identity file in the command. It just happens to fail because it can only try 5 keys I think, and then left me with that error, which was legit, just for the wrong identity file. The solution was to just use IdentitiesOnly yes in my ~/.ssh/config.

| improve this answer | |
0

I had this error because there was a blank line at the beginning of the key file. Easy to miss if you are cating it out.

| improve this answer | |
0

This is also the error ssh (at least some versions) emits if you have a passphrase on your private key, and enter the passphrase wrong when you attempt to connect.

(In particular, this happened to me with: OpenSSH_7.6p1, LibreSSL 2.6.2, which is the built-in SSH for Mac OS X 10.13.6 .)

So double-check that you're using the right passphrase, and that CAPS LOCK is off.

| improve this answer | |
0

My issue was due to encoding. Looking in VSCode the encoding of the file (which I had created using Out-File in PowerShell) was UTF-16LE. When I switched to UTF-8, the key was valid.

| improve this answer | |
0

You are logging with the wrong user

In my case, I was trying to connect to an Amazon AWS EC2 instance, but getting the error

load pubkey "MyPrivateKey.pem": invalid format

This was because I was trying to log with the wrong user (ec2-user)

I was using an Ubuntu machine, with user ubuntu instead of ec2-user (as is stated on the official Amazon Linux server OS).

But why that error?

It turns out Amazon uses an old format (puttygen says upon loading "openssh ssh-2 private key (old pem format)") that openssh doesn't like very much, so it is really a warning and not an error.

The real error (there is no such user on that server) is hidden by the server (otherwise you could brute force login names), but instead a "Connection closed" is shown.


You can find the name you use to connect to your machine on AWS under Actions>Connect.


How to fix the warning?

Just follow the answer of "Ras", which is, use PuTTYgen to convert to the OpenSSH format.

| improve this answer | |
0

Starting openssh 7.6, it defaults to a new more secure format. You can force it to convert to that format using the commands below to change your key password. In case you don't have and/or don't want a password, you can simply press enter and it will still rewrite the key in the new format

ssh-keygen -f ~/.ssh/id_rsa -p
| improve this answer | |
0

If you get a warning about an invalid public key format but the command still works then it may be because you only have a private key file and are using OpenSSH 8.3.

OpenSSH 8.3 includes a change to the ssh client where it looks for the private key's corresponding public key file and outputs this load pubkey "/home/user/.ssh/id.rsa": invalid format warning but continues to connect successfully. Tools using ssh, such as scp or git may show key_load_public: invalid format.

The client does not need the public key when connecting, only the private key. So this check is pointless and it has already been removed by an upstream commit but isn't in a relase (yet).

There's a discussion about this on the ArchLinux forum.

| improve this answer | |
-2

Make sure you to rename your PRIVATE key and remove the file extension that is the issue.

Steps I took

Create your public key:

Make sure you are in the same directory you have the private key

How to create the Public Key:

ssh-keygen -y -f Private-Key.pem > Public-key.pub

make sure the PUBLIC key has a .pub file extension

after that provide proper permissions for security reasons:

chmod 600 Private-Key.pem
chmod 400 Public-key.pub

THEN the most important part and the reason you got the error "invalid format"

Make sure you to rename your PRIVATE key and remove the file extension:

Remove the .pem from your Private key.

mv Private-Key.pem Private-Key

or if on a windows computer rename the private key, same name just remove the .pem

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.