Theory

When you set up SSH key-based authentication, you typically add your SSH public key to the authorized_keys file on the remote server. This allows you to authenticate without entering a password every time you connect to the server.

Using two authorized keys files, one main file and one backup file, helps ensure that you always have a working copy available. If you accidentally modify or delete the main authorized_keys file, you can use the backup file for recovery.

Protecting the backup file from accidental modification or deletion is also important. This can be done by setting the immutable flag on the backup authorized keys file.

User allowed method

AuthorizedKeysFile can define more than one authorized keys file in sshd_config, allowing a user to keep a backup key file in their home directory.
Protecting the backup file from changes helps protect the backup key from being modified or removed.
You can also keep your normal operational SSH key in the primary authorized keys file.

This needs to be defined in the sshd_config file as:

AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_backup

Protect the backup key file

Set the execute permission on the authorized_keys_backup file:

chmod +x authorized_keys_backup

Set the immutable flag on the authorized_keys_backup file using the chattr command:

sudo chattr +i authorized_keys_backup

Note: You may need to use sudo to run the chattr command, depending on your system configuration.

Verify that the authorized_keys_backup file is protected by trying to delete or modify it:

rm authorized_keys_backup

You should see an error message indicating that the file is protected.

Usage Purpose

Users should have two keys: one key for normal operations, and a second key for backup or recovery purposes.
Example: You use hardware keys, but one day the hardware key stops working. For this reason, you keep a normal plain RSA 4096-bit key on an offline USB stick.
See coldstorage for proper backup storage.
This helps bypass issues you may run into if the hardware key stops working.

Theory

SSH key files that are meant to be static and rarely changed, such as backup keys, are suitable to be managed by root.
This helps prevent user mistakes.

sshd_config syntax

# AuthorizedKeysFile /etc/ssh/%u tells sshd to look for each user’s allowed SSH public keys in /etc/ssh/ 
# (e.g., /etc/ssh/user1) instead of ~/.ssh/authorized_keys.
# touch /etc/ssh/user1
# chmod 0644 /etc/ssh/user1
# chown root:root /etc/ssh/user1
AuthorizedKeysFile /etc/ssh/%u .ssh/authorized_keys

By combining both AuthorizedKeysFile /etc/ssh/%u and AuthorizedKeysFile .ssh/authorized_keys, it gives 1 key file in /etc/ssh/user1 that is only accessible to root.
%u = username

Protect the backup key file

Set the execute permission on the /etc/ssh/user1 file:

chmod +x /etc/ssh/user1

Set the immutable flag on the /etc/ssh/user1 file using the chattr command:

sudo chattr +i /etc/ssh/user1

Note: You may need to use sudo to run the chattr command, depending on your system configuration.

Verify that the /etc/ssh/user1 file is protected by trying to delete or modify it:

rm /etc/ssh/user1

You should see an error message indicating that the file is protected.

Use Case

More suited for backup keys for administrators, or removing any capability from users to change them later on.