Hetzner: Load key “/root/.ssh/id_rsa.pub”: invalid format

I try SSH key authentification for Hetzner backup spaces. First, I generate public and private keys in my machine, then use this command:

server> cat .ssh/id_rsa.pub >> storagebox_authorized_keys 

After this command

echo -e "mkdir .ssh \n chmod 700 .ssh \n put storagebox_authorized_keys .ssh/authorized_keys \n chmod 600 .ssh/authorized_keys" | sftp <username>@<username>.your-storagebox.de 

I have an error after logging sftp:

Load key "/root/.ssh/id_rsa.pub": invalid format 

Debug:

OpenSSH_7.6p1 Ubuntu-4ubuntu0.2, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: /etc/ssh/ssh_config line 53: Applying options for user.your-backup.de debug1: Connecting to user.your-backup.de [2a01:4f8:b19:3000::14] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa.pub type 0 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa.pub-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.2 debug1: Remote protocol version 2.0, remote software version mod_sftp debug1: no match: mod_sftp debug1: Authenticating to user.your-backup.de:22 as 'user' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: ecdh-sha2-nistp256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: compression: none debug1: kex: client->server cipher: aes128-ctr MAC: compression: none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:EXMPL debug1: Host 'user.your-backup.de' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:EXMPL /root/.ssh/id_rsa.pub debug1: Server accepts key: pkalg ssh-rsa blen 279 Load key "/root/.ssh/id_rsa.pub": invalid format debug1: Next authentication method: password 

What can I do to resolve this problem?

UPD: content of id_rsa.pub: ssh-rsa string with slash and symbols

Command line that generates that debug output: ssh -v . Content of both files identical.

UPD2: After deleting next lines in /etc/ssh/ssh_config

Host user.your-backup.de User u198752 IdentityFile ~/.ssh/id_rsa.pub 

I generate new ssh-key without passphrase for key and got new error:

debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to user.your-backup.de [2a01:4f8:b19:3000::14] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 0 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.2 debug1: Remote protocol version 2.0, remote software version mod_sftp debug1: no match: mod_sftp debug1: Authenticating to user.your-backup.de:22 as 'u198752' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: ecdh-sha2-nistp256 debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: compression: none debug1: kex: client->server cipher: aes128-ctr MAC: compression: none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:exmpl debug1: Host 'user.your-backup.de' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:2 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:lexmpl /root/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentications that can continue: publickey,password debug1: Trying private key: /root/.ssh/id_dsa debug1: Trying private key: /root/.ssh/id_ecdsa debug1: Trying private key: /root/.ssh/id_ed25519 debug1: Next authentication method: password 

UPD3: I did all the steps from the beginning: created a new key pair, moved the public key to authorized_keys, returned ssh_config to its original state. Now the last line of debug output is:

debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:EXMPL /root/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentications that can continue: publickey,password debug1: Trying private key: /root/.ssh/id_dsa debug1: Trying private key: /root/.ssh/id_ecdsa debug1: Trying private key: /root/.ssh/id_ed25519 debug1: Next authentication method: password 
5

2 Answers

The problem is on your local computer, not on the Hetzner backup space.

If you don't specify an identity file when invoking ssh, there has to be a wrong name in one of your configuration files. It tries to load the public key as a private key.

Try

ssh -v -F /dev/null 

For reference, compare to this command:

$ ssh -v -i /etc/issue OpenSSH_7.6p1 Ubuntu-4ubuntu0.2, OpenSSL 1.0.2n 7 Dec 2017 ... Load key "/etc/issue": invalid format 

The option -i is used to specify the private key, so somewhere in your configuration there has to be something that tries to load the private key from /root/.ssh/id_rsa.pub, but the file contains a public key.

Edit

To address some of the confusion in your comments:

  • You can create a key pair with ssh-keygen. This saves the public key in id_rsa.pub and the private key in id_rsa (unless you specify otherwise).
  • The private key is meant to stay private and never leaves your system.
  • The public part is copied to the authorized_keys file on the target system, not the private key.
  • You should not change the common part of ssh_config, Host *, unless you know what you are doing.
  • The suggestion with -F /dev/null was just meant to avoid loading your faulty configuration, not for real use.
9

Thanks for the help, but I decided to use the information from this lesson and it helped.

Edit: Use this bash script and keychain:

#!/bin/bash # Remote Server Rsync backup Replication Shell Script # Local dir location LOCALBAKPOINT=/iscsi LOCALBAKDIR=/backups/ # Remote ssh server setup SSHUER=root SSHSERVER=server1.nixcraft.net.in SSHBACKUPROOT=/wwwroot # Make sure you can log in to remote server without a password source $HOME/.keychain/$HOSTNAME-sh # Make sure local backup dir exists [ ! -d ${LOCALBAKPOINT}${LOCALBAKDIR} ] && mkdir -p ${LOCALBAKPOINT}${LOCALBAKDIR} # Start backup /usr/bin/rsync --exclude '*access.log*' --exclude '*error.log*' -avz -e 'ssh ' ${SSHUER}@${SSHSERVER}:${SSHBACKUPROOT} ${LOCALBAKPOINT}${LOCALBAKDIR} # See if backup failed or not to /var/log/messages file [ $? -eq 0 ] && logger 'RSYNC BACKUP : Done' || logger 'RSYNC BACKUP : FAILED!' 
0

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

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

You Might Also Like