Skip to content

Instantly share code, notes, and snippets.

@luizomf
Last active January 8, 2026 16:51
Show Gist options
  • Select an option

  • Save luizomf/4d823b8b65cd622fc2dedf59a6187784 to your computer and use it in GitHub Desktop.

Select an option

Save luizomf/4d823b8b65cd622fc2dedf59a6187784 to your computer and use it in GitHub Desktop.
SSH key rotation guide: secure backup of ~/.ssh with 7zip (AES-256, encrypted headers), safe SSH key revocation without lockout, correct order to replace keys, behavior of active SSH sessions, authorized_keys handling, fixing broken ~/.ssh permissions, ed25519 keys, OpenSSH on Linux/macOS, real-world DevOps and server security notes. Otávio Miranda

SSH Keys Rotation

Since I record my screen a lot for videos and courses, I need to take some security measures more frequently than the average person. Because I recently recorded a few videos teaching Linux server security, I ended up showing some SSH private and public keys on screen.

There’s nothing critical here. Those were temporary keys. Still, just to be safe, I’m rotating all my SSH keys.


Backing up my ~/.ssh directory securely

First, I make sure I have a secure backup of my current ~/.ssh directory. If anything goes wrong, I can simply restore it. I use 7zip for this.

7zip allows me to compress the entire directory into a single file, protect it with a strong password, and store it safely offline.

7z a -t7z -m0=lzma2 -mx=9 -mhe=on ~/.ssh-$(date +%Y-%m-%d).7z ~/.ssh -p

This command will prompt you for a password. Choose it wisely and make it strong.

When finished, you’ll end up with a file like .ssh-2026-01-02.7z. I usually test the extraction immediately to make sure all files are present and that the password is correct. At this point, if you forget the password, you will not be able to recover the backup.

To test it safely, move the backup file to a temporary directory that can be deleted afterward.

NOTE: I’ll use the same file name (.ssh-2026-01-02.7z) throughout the examples below. Use your own file name.

mkdir -p ~/DELETEME
mv ~/.ssh-2026-01-02.7z ~/DELETEME
cd ~/DELETEME
7z x .ssh-2026-01-02.7z # Enter your password and verify the files
ls -lah .ssh

# Cleanup
cd ~
rm -rf ~/DELETEME

Revoking SSH Keys — The Strategy

To revoke SSH keys, you need to remove them from your ~/.ssh directory and from the server. The tricky part is the order in which you do this. If you get it wrong, you may lock yourself out of the server.


First, connect to the server

Before deleting anything, choose the SSH key pair you want to revoke and connect to the corresponding server using it. Here, I’m assuming we’re talking about real servers, not platforms where you can change public keys through a nice web UI.

Keep this connection open until you finish creating, authorizing, and testing the new key.

And yes... pray to the connection gods so your SSH session stays open until you're done 😉.


Create a new key

Now create the new key. You'll need to give it a new name (obviously):

# Change the values as you see fit
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/name_your_key -C "your_user@the_host"

Authorize the new public key

By now, you probably see where this is going. We'll create, authorize, and test the new SSH key pair before removing the old one.

First, copy the public key:

# If the key is named `name_your_key`,
# the public key will be `name_your_key.pub`
cat ~/.ssh/name_your_key.pub

Now, on the server you are already connected to, open ~/.ssh/authorized_keys and paste the key at the end of the file.

# THIS COMMAND RUNS ON THE SERVER
vim ~/.ssh/authorized_keys  # paste at EOF, do not remove existing entries
# save and close

Test the new SSH key pair

Do not close the current SSH session.

Open a new terminal and test the new key:

# We'll make this command shorter later using ~/.ssh/config
ssh your_user@the_host -i ~/.ssh/name_your_key

If everything is correct, the connection should work normally.


Now delete the old key

At this point, it's safe to delete the old key from your local machine and remove the corresponding line from ~/.ssh/authorized_keys on the server.

Do not restart the SSH service.

Restarting sshd would drop all active connections, including the one you're using as a safety net.

Instead, let's fix ~/.ssh/config so we don't need to type the full command every time.

On your local machine, open ~/.ssh/config and add:

# Adjust the values to match your setup
Host the_host
  HostName the_host
  User your_user
  Port 22
  IdentityFile ~/.ssh/name_your_key

Now you can connect using the much simpler command:

ssh the_host

All done. Now repeat this process for the other 50 SSH key pairs you still have to rotate.

Good luck 😄


What if you messed up your ~/.ssh permissions?

If you did something crazy like deleting the entire .ssh directory (like I did 🤣), you'll need to fix the permissions manually.

Fortunately, this is simple.

# The ~/.ssh directory
# Permissions: 700
chmod 700 ~/.ssh

# Private keys (without ".pub")
# Permissions: 600
# DO NOT COPY AND PASTE THIS BLINDLY.
# CHECK AND ADJUST THE FILE NAMES AS NEEDED.
chmod 600 ~/.ssh/id_*

# ~/.ssh/authorized_keys, ~/.ssh/config and ~/.ssh/known_hosts
# Permissions: 600
chmod 600 ~/.ssh/{authorized_keys,config,known_hosts}

# Public keys
# Permissions: 644
chmod 644 ~/.ssh/*.pub

Here's a summary of how the permissions should look:

~/.ssh                    700
~/.ssh/authorized_keys    600
~/.ssh/id_*               600
~/.ssh/config             600
~/.ssh/known_hosts        644
~/.ssh/*.pub              644

That's it.


What about the server? Configure openssh-server

Since you're already here, here is my OpenSSH Server Config:

# Configure openssh-server

# Install the server if needed
sudo apt install openssh-server

# Open config file
sudo nano /etc/ssh/sshd_config
# or
sudo vim /etc/ssh/sshd_config

# Uncomment, change or create these lines
# The first time sshd sees an option, it will be set.
# This means, other variables changing the value will be ignored.
# It is better to add those values as soon as possible to sshd_config.
# Normally, there is a "include" line at the top of the file for you to use.
# But I won't cover this here.
PubkeyAuthentication yes # only allow access with ssh keys
PasswordAuthentication no # do not allow no password login
KbdInteractiveAuthentication no # we don't need that (it's a 2FA)
ChallengeResponseAuthentication no # we also don't need that
PermitRootLogin no # never allow root login
PermitEmptyPasswords no # never allow empty password
UsePAM no # this is the authentication method
Port 22 # default
MaxAuthTries 20 # if you have a lot of ssh-keys
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 # default

# If you want even more security, add users and groups allowed to login
# If you do something wrong here, you wont be able to login later.
# ALWAYS TEST BEFORE CLOSING YOUR CURRENT CONNECTION.
AllowUsers user1 user2
AllowGroups group1 group2

# Restart the server
sudo systemctl restart ssh

# Add you public key to authorized_keys file
sudo nano ~/.ssh/authorized_keys

Now I'm done. Bye 👋!


@SetTrend
Copy link

SetTrend commented Jan 3, 2026

Perhaps you may want to record your courses from within a VM with nothing else installed than what you want to show? Then in most cases you can skip these security measures.

@luizomf
Copy link
Author

luizomf commented Jan 4, 2026

@SetTrend exactly. I'm working on it.

@herloncosta
Copy link

Thank you so much for sharing these instructions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment