You can regain access to your Hetzner server by using the Rescue System. Boot into this mode via the Robot interface, mount your root filesystem, and edit the authorized_keys file directly from the command line. This method bypasses standard SSH authentication entirely, allowing you to inject a new public key and restore remote shell access without needing the original credentials.
Accessing the Hetzner Robot Interface
The first step in recovering a lost SSH key is gaining administrative control over the server hardware through Hetzner’s online management portal. You must log in to the Hetzner Robot web interface using your account credentials. Once logged in, navigate to the Servers menu and select the specific server that has become inaccessible due to the missing key. On the server details page, locate the Reset or Change Password section. Look for the option labeled Rescue System. Click on this option to initiate the rescue boot process. You will be presented with a form where you need to select an operating system version. It is highly recommended to choose a stable Linux distribution such as Debian 11 or Ubuntu 20.04 LTS, as these environments are well-supported and contain all necessary utilities for file manipulation. After selecting the OS, click Activate Rescue System. The system will generate a temporary root password. Copy this password immediately, as it will only be displayed once. Save it securely, as you will need it to log into the rescue environment via SSH. Note that activating the rescue system requires a short downtime, typically between one to three minutes, during which the server reboots.Connecting to the Rescue Environment
Once the server has rebooted, you can connect to it using the temporary root password provided by the Robot interface. Open your local terminal application and establish an SSH connection to the server’s IP address. Use the usernameroot and the temporary password generated earlier. For example, run:
ssh root@your_server_iplsblk command to list all block devices. Identify the partition that corresponds to your main root filesystem. In most standard Hetzner setups, this will be something like /dev/sda1 or /dev/nvme0n1p1. Do not guess the device name; incorrect mounting can lead to data loss or failure to find the correct user directories.
Mounting the Root Filesystem
With the rescue system active and connected, the next critical step is to mount your actual server’s root filesystem. This allows you to read and write files on your persistent storage. Create a temporary directory to serve as the mount point:mkdir /mnt/root/dev/sda1, execute:
mount /dev/sda1 /mnt/rootvgs and lvs commands to identify the correct logical volume. However, for standard installations, direct partition mounting is sufficient. Verify the mount was successful by running df -h /mnt/root. You should see your root partition listed with available space.
Injecting the New SSH Key
Now that your root filesystem is mounted at/mnt/root, you can modify the SSH configuration. The SSH daemon checks the ~/.ssh/authorized_keys file for each user to determine who is allowed to log in. You need to append your new public key to this file for the user account you wish to access.
First, identify the home directory of the target user. If you want to add the key for the root user, the path is /mnt/root/root/.ssh/authorized_keys. If you are adding it for a different user, such as admin, the path would be /mnt/root/home/admin/.ssh/authorized_keys.
Generate a new SSH key pair on your local machine if you haven’t already:
ssh-keygen -t ed25519~/.ssh/id_ed25519.pub) to your clipboard. Then, append it to the authorized keys file on the server. You can use the echo command with redirection:
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... [email protected]" >> /mnt/root/home/username/.ssh/authorized_keys.ssh directory does not exist, create it using mkdir -p /mnt/root/home/username/.ssh before appending the key.
After writing the key, set the correct permissions to ensure SSH accepts the file:
chmod 700 /mnt/root/home/username/.ssh
chmod 600 /mnt/root/home/username/.ssh/authorized_keysTroubleshooting Common Issues
If you still cannot connect after following these steps, check the ownership of the .ssh directory. It must match the user ID of the account you are trying to access. Incorrect ownership will cause SSH to reject the key silently. You can fix this with:chown -R username:username /mnt/root/home/username/.sshFrequently Asked Questions
Can I recover my SSH key if I forgot the passphrase?
No, SSH keys are encrypted locally on your machine. If you lost the private key file itself, you cannot recover it. You must generate a new key pair and add the new public key to the server, which is what this guide explains how to do via the rescue system.Does activating the rescue system delete my data?
No, activating the rescue system only boots a temporary OS from Hetzner’s infrastructure. Your existing data on the hard drive remains intact. You are merely mounting your existing drive to make it accessible for editing.What if my server uses LVM instead of standard partitions?
If your server uses LVM, you will need to activate the volume groups in the rescue environment before mounting. Use commands likevgchange -ay to activate volumes, then mount the logical volume path (e.g., /dev/mapper/vg-root) to /mnt/root.
Why did my SSH connection fail after adding the key?
This is usually caused by incorrect permissions or ownership. The.ssh directory must be owned by the user and have permissions set to 700. The authorized_keys file must be owned by the user and have permissions set to 600. Any deviation will cause SSH to ignore the key for security reasons.
Is it safe to edit files in the rescue system?
Yes, it is safe as long as you mount the correct partition. Always verify your mount point withlsblk and df before making changes. Accidentally formatting or overwriting the wrong partition is the primary risk, so double-check device names carefully.