I created a server, and configured SSH to not allow root login and disable password access, so only accepts an SSH key to login.

I have a machine A with a key, and I can access my server from that machine without any problems.

Also have a backup of those keys, just in case.

Let's say my machine A dies tomorrow and I got a new machine B, and of course need to access my server.

Here I don't know how things work. Should I just copy the keys from my backup to machine B and that will allow me to access my server? Or should the keys be imported via some OpenSSH command?

So my first doubt is about the backup import, because I'm afraid to completely lose access to my server.

The second is about the passphrase I set for my keys on machine A. Is that still valid for my copied keys? Or through the import I need to set a new passphrase on the new machine.


4 Answers 4


SSH key has two parts:

  • the private key that should be secured by strong password
  • the public key (usually ending with .pub suffix) that should be copied to the server

You can move both parts freely as you wish, although I wouldn't recommend you to place the private part publicly (even encrypted).

The private part is placed on any of your local machines in ~/.ssh/ directory. The expected key names are

  • id_rsa
  • id_rsa-cert
  • id_dsa
  • id_dsa-cert
  • id_ecdsa
  • id_ecdsa-cert
  • id_ed25519
  • id_ed25519-cert

If your key has one of the respective names you are good to go. If you need to use some specific key you have to use parameter -i

/usr/bin/ssh -i <path_to_key_file>

The same is for the public - server - part. In the users home directory must exist a file ~/.ssh/authorized_keys. This file contains all publc keys, that are allowed to login as the user - one per line. The comment part can be omitted.

That said on any server you would like to use any of your SSH keys, copy the public part on a new line in authorized_keys file.

I'd advise you to study the manual page of SSHD (man sshd), especially part "AUTHORIZED_KEYS FILE FORMAT".

Also i think that I also should warn you that there are some rules for filesystem permissions for the home directory, ~/.ssh directory and the ~/.ssh/authorized_keys file as stated in the sshd manual page, in short it canot be writable by others.

         Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.  The format of this file is described
         above.  The content of the file is not highly sensitive, but the recommended permissions are read/write for the user, and
         not accessible by others.
         If this file, the ~/.ssh directory, or the user's home directory are writable by other users, then the file could be modi‐
         fied or replaced by unauthorized users.  In this case, sshd will not allow it to be used unless the StrictModes option has
         been set to “no”.
  • 3
    This Q is about changing (replacing) the client not going to a new server. Commented Jul 10, 2018 at 9:37
  • Sorry, you are right. I've edited the answer and extended it with the private key description. Hope it will be useful for someone.
    – cernyl
    Commented Jul 10, 2018 at 11:43
  • This is a useful answer, why was voted down? Commented Aug 30, 2018 at 15:51

Copying the backed-up keys into place will work fine. No specific import command is required. A passphrase is a property of a key file (specifically, it is the input to a key-derivation function to generate an encryption key for the private key data).


Just copy private key (from machine A) to another machine(B). and you can login server with command

ssh -i private_keyfile.key [email protected] 

Note : Assumed you already copied public key form machine A to authorized_key on server.


All you need is pair of two keys. Public and private. Feel free to copy it to another environment (especially private which lying only on the guest machine) and try to check . Passphrase is generated to that pair so you need it always.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .