Enable rescue mode in Hetzner Cloud

Open your project, then complete the following steps to enable rescue mode in Hetzner Cloud

1. Select the server you want to use to activate Rescue.
2. On the server’s upper menu bar, select Rescue.
3. Choose an option to activate Rescue

-There are two ways to initiate rescue:

i) ENABLE RESCUE

• When you choose ENABLE RESCUE, the rescue system is active, and at the next restart, your server will automatically boot over the rescue system’s network. You must manually restart the server because it does not do so automatically.
• The rescue will be active for 60 minutes.
• If you restart your server within those 60 minutes, it will start up over the network of the rescue system. 
• After those 60 minutes, if you restart your server, it will once more boot from the local disc. Automatically, Rescue will be turned off once more.
• You can disable Rescue where it was active if you decide to stop using it but you need to restart your server within those 60 minutes.

ii) POWER CYCLE & ENABLE RESCUE

•  Once you choose ENABLE RESCUE & POWER CYCLE, your server will reboot and boot over the rescue system’s network automatically.
• The rescue will continue operational until the server is restarted after it has booted across the network of the rescue system.

4. Activate Rescue

• A tiny window will appear once you have picked one of the two options from Step 3. You can select linux64 as your rescue OS. You can also select an SSH key that will be used to connect to the server.
• On your Cloud Console, you will receive a root password as soon as you choose ENABLE RESCUE. After the server restarts, you can log in to it using this password if you haven’t chosen an SSH key.

5. Link up with your server,

Connect to your server as the root user using SSH.

ssh root@<203.0.113.1>

[Please change <203.0.113.1> to the actual IP address of your own server.]

CLI warning

If you have connected to your server before, without the rescue system, there will already be a fingerprint in your local known_hosts file. You can think of this fingerprint as a unique identifier of the server. Usually, the fingerprint is automatically recognized when you try to connect to this IP address. With the rescue system, however, this fingerprint is not valid.
Therefore, when you are connecting to your server via the rescue system, you might get a warning like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

...
...
...

Offending ECDSA key in /home/user/.ssh/known_hosts:2
  remove with:
  ssh-keygen -f "/home/user/.ssh/known_hosts" -R "<203.0.113.1>"

...
...

 If you receive this warning, you must remove the old fingerprint from the known_hosts file as described in the following step.

You can move on to step 7 if you do not receive a warning like this.

6. Remove the current fingerprint

• The known_hosts file’s fingerprint is solely invalid for the rescue system. The fingerprint will become valid once Rescue is turned off.

• Since you can use the fingerprint again, all you need to do for now is add a hash sign and leave the fingerprint in the file as a note. Once the server has restarted from its local disc, you can delete the hash sign. If necessary, you can choose to remove the fingerprint and generate a new one later.

Submit a comment

• For the duration that you are using Rescue, you can leave the fingerprint as a remark. The line Offending ECDSA key in /home/user/.ssh/known_hosts:2 in the warning tells you the line in the known_hosts file where your fingerprint is saved. In this instance, line 2 has the fingerprint.

Your local device’s known_hosts the file should be edited.

nano ~/.ssh/known_hosts

Add # to your fingerprint in the warning line

|1|lPqnDMjklla23lPqnDMjkllPq9=|lPqnDMjklla233lPqnDMjklla...
#|1|vlQvhfjekla23lPqnDMjklop5E=|343Pfd964BZxg3kfdIEYKLue4...

When finished, you can use CTRL + X to save the file, Y to approve, and ENTER to dismiss it.

• When rescue is complete, the hash sign can be removed again. Additionally, you must delete the new rescue fingerprint.

Delete the fingerprint

• Alternatively, you can delete the fingerprint from the known_hosts file using the command in the caution.

ssh-keygen -f "/home/user/.ssh/known_hosts" -R "<203.0.113.1>"

• Now that the fingerprint has been removed, you can connect to your server using ssh [email protected]>. This time, only a warning about host authenticity should be issued. You can select yes to save the new fingerprint to the local known_hosts file.
• After you have restarted your server without Rescue, you can remove the Rescue fingerprint from the known_hosts file. The fingerprint should have been included at the conclusion of the file.

7. End rescue

• If you press CTRL+D to disconnect from your server, for instance, Rescue will keep running in the background. Therefore, when you initiate a new connection, you will remain on the rescue system
• The only method to deactivate Rescue is to reset the server. Then the system will start up again from its local disc.