Regarding backups (escrows) of GPG (OpenPGP compliant) keys, I seem to understand that (E)ncryption keys need to be backed up, to prevent data loss, and that (S)igning keys should not be backed up, because it is crucial that the owner is absolutely certain that they are the only one who can use the signing key at any moment.

Is there a good protocol regarding backing up (A)uthentication keys? I could imagine no backups because only you want to be able to authenticate yourself, but on the other hand if you lose your authentication key and you need to ssh into a VPS with it, you're out of luck (but with a server at home you could just wait to get physical access to replace the public ssh key).

So does it depend on your situation? I'm asking this question because I am using a Master (C) key with separate Encryption, Signing, and Authentication subkeys. I could conceive of making a Master (CA) key, and then put two public authentication keys on your VPS-- one tied to your (CA) Master key and the other to your (A) Subkey-- so in case you lose your (A) subkey, you can dig up your basement, get your (CA) Master key, and ssh into the VPS to remove the old (A) Subkey public key and add a new (A) Subkey public key.

Thanks in advance.

3 Answers 3


In general, you should back up data you think is valuable and don't want to lose, especially data that you cannot easily recreate. Whether that applies in this case, since you can create a new signing key (assuming you have a revocation certificate for the old one) is up to you. There is no single right answer for this case.

Note that backups need not be done insecurely. I use Tarsnap for backups, which is a service that implements client-side encryption and deduplication, so all the server sees is just chunks of encrypted data. Therefore, I feel comfortable backing up things like secret keys since only I can get at the data.

  • This does not answer the OP question, he's asking about the keys and very specific cases.
    – nethero
    May 30, 2021 at 19:29
  • It does definitely answer the question. There is no difference in the appropriate situations to back up keys and other data.
    – bk2204
    May 30, 2021 at 19:51
  • This is simply not true as some keys can't be backed up even if you want to (eg. keys generated on the smart card). I'm yet to work with an organization that would treat key material in the same way as the data.
    – nethero
    May 30, 2021 at 19:59

After doing some more research, it seems that backing up your (A)uthentication key is necessary in most situations. For example, if you ssh into a VPS, storing your (A) public key on the VPS, and you lose your (A) private key-- or worse, it's stolen-- then you will not be able to ssh into the VPS (assuming password login in disabled). You can't physically access the VPS, so you'd be stuck.

If you made a (AC) Master key, and put its respective public key on your VPS, then you could always retrieve your (AC) key if your (A) subkey got lost or stolen, as described above. Your (AC) key would allow you access to the VPS and you could add the public key of a new (A) Subkey. Using your (AC) Master key in this way, however, involves putting it on a computer with at least ssh network connectivity, which might be too risky for certain threat models. As such, backing up your (A) Subkey instead of using an (AC) Master key as a failsafe could be more secure.


I do not see a reason for backing up or archiving authentication keys (even if it is possible). The authentication should be based on the certificate and not the public key itself. In case you lose the key, you may revoke the old certificate and Issue a new one and you still be able to log in to your service. The CA's registration officer would be responsible for validating your identity. The certificate can be issued with DN information that the server can validate against it's LDAP directory.

You must log in to answer this question.

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