11

SSHing into my system succeeds but even without the -v flag I get key_load_public: invalid format message. Below is the output w/ using the verbose flag.

Specifically

debug1: key_load_public: No such file or directory debug1: identity file /home/myname/.ssh/private_rsa_key-cert type -1

seems to be the problem as I don't have such a file. However, I checked w/ another system and I also get the same two above lines. However there is no key_load_public: invalid format before that, which is what I actually want to get rid of. Permissions on the authorized_keys file on both remote systems looks the same, permissions on the private_keys look the same too.

    $ ssh -v desired_host
    OpenSSH_7.2p2, OpenSSL 1.0.2g  1 Mar 2016
    debug1: Reading configuration data /home/myname/.ssh/config
    debug1: /home/dli/.ssh/config line 16: Applying options for desired_host
    debug1: Reading configuration data /etc/ssh_config
    debug1: Connecting to desired_host [X.X.X.X] port 22.
    debug1: Connection established.
    key_load_public: invalid format
    debug1: identity file /home/myname/.ssh/private_rsa_key type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /home/myname/.ssh/private_rsa_key-cert type -1
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_7.2
    debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
    debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
    debug1: Authenticating to desired_host:22 as 'myname'
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
    debug1: kex: host key algorithm: ssh-rsa
    debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
    debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<3072<8192) sent
    debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Server host key: ssh-rsa SHA256:EmG/FBK0OCXtaAqAkfHKxoXKLGiZiHUsQpObK6aWd30
    debug1: Host 'desired_host' is known and matches the RSA host key.
    debug1: Found key in /home/myname/.ssh/known_hosts:39
    debug1: rekey after 4294967296 blocks
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: rekey after 4294967296 blocks
    debug1: SSH2_MSG_NEWKEYS received
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
    debug1: Next authentication method: publickey
    debug1: Trying private key: /home/myname/.ssh/private_rsa_key
    debug1: Authentication succeeded (publickey).
    Authenticated to desired_host ([X.X.X.X]:22).
    debug1: channel 0: new [client-session]
    debug1: Requesting no-more-sessions@openssh.com
    debug1: Entering interactive session.
    debug1: pledge: network
1
  • getting similar, slightly different "load pubkey .... invalid format", putting this here for the search engines since there are literally 0 results for that query. Dec 20, 2018 at 6:04

8 Answers 8

5

Same issue for me, different source and solution:

I had both id_rsa.foo (correct private key) and id_rsa.foo.pub (matching pubkey) in my .ssh folder on the client. Removing or renaming the pubkey made the message disappear.

2
  • This solved it for me, it removed the key_load_public: invalid format. The script seems to check the public key because it has the same name (except for the extension ".pub") as the private key. You do not need the public key on the client anyway, but instead, it only needs to be on the server. Thus, I deleted it from the client. Mar 13, 2021 at 17:30
  • Alternatively, ensure id_rsa.pub is in the OpenSSH Public Key format. ssh-rsa <public key> <comment> and not SSH2 format ---- BEGIN SSH2 PUBLIC KEY ----
    – Will B.
    Jun 3, 2021 at 16:34
3

There are two separate messages:

This one tells you that .ssh/private_rsa_key is in wrong format:

key_load_public: invalid format
debug1: identity file /home/myname/.ssh/private_rsa_key type -1

This one does not show up in without -v switch and is just informative to tell you that you don't have a certificate:

debug1: key_load_public: No such file or directory
debug1: identity file /home/myname/.ssh/private_rsa_key-cert type -1

There is nothing to worry about the second message.

4
  • 1
    How does an invalidly formatted private key still validate? Isn't a key correct or incorrect? (I checked the EOLs in both private keys and they are both not using carriage returns)
    – hiandbaii
    Apr 27, 2016 at 16:21
  • It is a generic error. It might be anything. How does the header of the file look like?
    – Jakuje
    Apr 27, 2016 at 16:43
  • -----BEGIN RSA PRIVATE KEY-----
    – hiandbaii
    Apr 27, 2016 at 16:53
  • This thread looks incomplete. What happened after @hiandbaii you disclosed that you have -----BEGIN RSA PRIVATE KEY----- as header of the id_rsa file? I am also getting the same error key_load_public: invalid format. But the solution seems evasive.
    – user30994
    Nov 26, 2018 at 15:50
3

when I issued

ssh myid@mydomain

and got message (even though I successfully logged into remote box)

key_load_public: invalid format

it happened because somehow my local ~/.ssh/xxx.pub actually had contents of my private key file even though the remote host correctly had my public key in file ~myid/.ssh/authorized_keys SO solution was to correct my local ~/.ssh/xxx.pub so it had my public key

4
  • Have you replicated the problem? Seems very unlikely that if you copy the private key into the public key file the ssh connection will till go through.
    – user30994
    Nov 26, 2018 at 15:53
  • Did you have BOTH public and private in there? That's how it might have worked for you - ie matching on the right one, ignoring the wrong one?
    – KolonUK
    Dec 7, 2018 at 9:27
  • 1
    that actually was the case. Incredible!
    – Mario
    Feb 26, 2019 at 16:16
  • 1
    I had a similar case. My local ~/.ssh/id_rsa.pub file was empty. I overwritten it while messing around with them. Problem is gone after I corrected it.
    – Asocia
    May 10, 2021 at 18:18
2

I was having this warning msg with scp and ssh when I used the -i option. I found that cause was extra in public key file. my pub key file had 2 lines with 'wc -l'; i deleted the extra and now it only has 1 line with 'wc -l' and there are no warning messages. I should clarify that ssh and scp worked correctly with and without the warning message.

1
  • 1
    I had a similar situation. It was caused by using the -i id_rsa flag, when id_rsa.pub also existed and had options (like "no-pty") at the beginning of the line. Either removing those options, or removing the entire file made the warning go away. In any case, the file was never needed to login. In short, it appears that the thing that looks for a *.pub file adjacent to the file you specify with the -i flag does not know how to handle options.
    – Archie
    Feb 6, 2020 at 22:02
1

I finally succeeded by being sure to copy and paste EXACTLY the contents of private RSA key, e.g.

-----BEGIN RSA PRIVATE KEY-----
<content>.....
-----END RSA PRIVATE KEY-----

including all the EOL tabs or whatever was there.

1
  • There is no EOL after the -----END RSA PRIVATE KEY-----
    – user30994
    Nov 26, 2018 at 15:53
0

I had the same problem and I found the solution. My keys were created by puttygen. This tool (or kittygen) has a tab called conversion where you can save in three different formats. I saved in "Export OpenSSH key" format and it gave me the error: load pubkey "/home/user/.ssh/id_rsa": invalid format then I saved and used the key saved in format: "Export OpenSSH key (force new file format)" and the warning is removed. So the key is this new format.

0

In Docker, but also applicable to manual steps.

Using echo, the line format breaks which then causes the error "/root/.ssh/id_rsa": invalid format, see Using SSH keys inside docker container.

Thus, do not echo the private key into the container folder like:

RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa &&     chmod 600 /root/.ssh/id_rsa

Instead, use COPY or ADD:

COPY /.ssh/id_ed25519 /root/.ssh/id_ed25519

This supports the answer of @AndrewRoe in this thread.

See also this.

What is more, you will need to add the server to the known hosts to get rid of the key_load_public error. In my case,

the error

#15 0.589 debug1: identity file /root/.ssh/id_rsa type -1, 
#15 0.589 debug1: key_load_public: No such file or directory

disappeared using

echo "Host *\n User git\n HostName gitlab.com\n AddKeysToAgent yes\n IdentityFile /root/.ssh/id_rsa" >> /etc/ssh/ssh_config

which adds the needed known host to the ssh_config. See:

What does “key_load_public: no such file or directory” mean?

key_load_public: No such file or directory even though file exists

“Permission denied (publickey)” with “key_load_public: No such file or directory” upon SSH attempt

-1

This happened to me since I had RSA & DSA keys into my .ssh folder. The DSA key is no longer accepted on the system, so I just removed it and the message disapperared.

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.