Hetzner Rescue-System: Neuen Benutzer im Live-System anlegen

Wer seinen SSH-Zugang aus Sicherheitsgründen so konfiguriert hat, dass der Login ausschließlich per SSH-Key möglich ist, steht bei einem Systemfehler schnell vor einem Problem: Die Hetzner Web-Konsole akzeptiert nur Passwort-Logins – ein SSH-Key lässt sich dort nicht verwenden. Ist das Passwort des einzigen Benutzers unbekannt oder wurde der Passwort-Login in der sshd_config deaktiviert, kommt man über die Konsole schlicht nicht rein.

Die Lösung: Über das Rescue-System direkt in das Live-System einsteigen, einen neuen Benutzer mit Passwort anlegen und ihn mit Root-Rechten ausstatten. Danach ist der Zugang über die Hetzner Konsole wieder möglich – und man kann in Ruhe den eigentlichen Fehler beheben.

Rescue-System aktivieren

Das Rescue-System wird über die Hetzner Console unter console.hetzner.com aktiviert.

Bei Hetzner Cloud

1. Öffne die Hetzner Console unter console.hetzner.com
2. Wähle das gewünschte Projekt und den betroffenen Server aus
3. Navigiere links zu „Rescue“
4. Klicke auf „Rescue aktivieren“ und wähle das System (z. B. linux64)
5. Das angezeigte Root-Passwort notieren – es wird nur einmal angezeigt!
6. Den Server anschließend neu starten, damit das Rescue-System geladen wird

Bei Hetzner Dedicated

1. Öffne die Hetzner Console unter console.hetzner.com
2. Wähle den Dedicated Server aus
3. Navigiere zu „Rescue“, Betriebssystem wählen (z. B. linux64) und aktivieren
4. Root-Passwort notieren
5. Den Server anschließend neu starten, damit das Rescue-System geladen wird

Per SSH ins Rescue-System einloggen

Nach dem Neustart per SSH verbinden:

ssh root@<server-ip>

SSH-Fingerprint-Warnung

Da das Rescue-System einen anderen Fingerprint hat als das eigentliche Betriebssystem, erscheint folgende Warnung:

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Den alten Eintrag aus der known_hosts-Datei entfernen:

ssh-keygen -R <server-ip>

Wer die Datei manuell bearbeiten möchte, findet sie hier:

• Linux/macOS: ~/.ssh/known_hosts
• Windows: C:\Users\<Benutzername>\.ssh\known_hosts

Die Zeile mit der Server-IP vollständig löschen, dann neu verbinden und den Fingerprint einmalig bestätigen.

Volumes mounten

Im Rescue-System liegen die Festplatten des eigentlichen Servers noch nicht eingehängt vor. Zuerst die vorhandenen Partitionen anzeigen:

lsblk -f

Typische Ausgabe:

NAME    FSTYPE  LABEL   SIZE MOUNTPOINT
sda
├─sda1  ext4            39.9G
└─sda15 vfat            100M
sdb     ext4            50G

Mountpunkte anlegen und Volumes einhängen:

mkdir -p /mnt/rootdisk
mkdir -p /mnt/dataspace

mount /dev/sda1 /mnt/rootdisk
mount /dev/sdb  /mnt/dataspace

Bei BTRFS-Dateisystem (neuere Hetzner-Images):

mount -o subvol=@ /dev/sda1 /mnt/rootdisk

Anschließend die virtuellen Systempfade einbinden, damit chroot korrekt funktioniert:

mount --bind /dev  /mnt/rootdisk/dev
mount --bind /proc /mnt/rootdisk/proc
mount --bind /sys  /mnt/rootdisk/sys

In das Live-System wechseln (chroot)

Mit chroot in die Umgebung des eigentlichen Systems einsteigen:

chroot /mnt/rootdisk /bin/bash

Ab jetzt arbeitet man direkt in der Umgebung des Live-Systems – so als wäre man normal eingeloggt.

Neuen Benutzer anlegen

Schritt 1: Benutzer erstellen

useradd -m -s /bin/bash notfalluser

• -m erstellt automatisch ein Home-Verzeichnis unter /home/notfalluser
• -s /bin/bash setzt die Standard-Shell auf Bash

Schritt 2: Passwort setzen

passwd notfalluser

Ein sicheres Passwort eingeben und bestätigen. Dieses Passwort wird später für den Login über die Hetzner Konsole benötigt.

Schritt 3: Benutzer zur sudo-Gruppe hinzufügen

usermod -aG sudo notfalluser

Schritt 4: SSH-Konfiguration anpassen

Da der SSH-Zugang ursprünglich auf Key-Only konfiguriert war, muss die sshd_config so angepasst werden, dass Passwort-Login und Key-Login gleichzeitig funktionieren:

nano /etc/ssh/sshd_config

Folgende Einstellungen suchen und setzen – auskommentierte Zeilen (mit #) dabei freischalten:

# Passwort-Login global erlauben
PasswordAuthentication yes

# Leere Passwörter verbieten (Sicherheit)
PermitEmptyPasswords no

# SSH-Key-Login weiterhin erlauben
PubkeyAuthentication yes

Was diese Einstellungen bewirken:

• PasswordAuthentication yes – erlaubt den Passwort-Login für den neuen Notfall-Benutzer
• PermitEmptyPasswords no – verhindert den Login mit leerem Passwort
• PubkeyAuthentication yes – bestehende Benutzer mit SSH-Key können sich weiterhin normal einloggen, da Key-Login und Passwort-Login gleichzeitig aktiv sein können

Hinweis: PermitRootLogin muss hier nicht geändert werden. Diese Einstellung betrifft ausschließlich den root-Benutzer – der neue notfalluser ist davon nicht betroffen. Der bisherige Wert (prohibit-password oder no) kann unverändert bleiben, sodass Root weiterhin nur per SSH-Key erreichbar ist.

Nach dem Bearbeiten speichern: Strg+O → Enter → Strg+X

Schritt 5: SSH-Dienst neu starten

systemctl restart ssh

chroot verlassen und Server neu starten

exit
reboot

Nach dem Neustart startet der Server wieder mit dem normalen Betriebssystem. Der neue Benutzer notfalluser ist jetzt aktiv und kann sich über die Hetzner Konsole mit Passwort einloggen – oder per SSH mit Passwort, während bestehende Accounts weiterhin per SSH-Key funktionieren.

Nach der Reparatur: Aufräumen

Sobald der eigentliche Fehler behoben und der normale Zugang wiederhergestellt ist, sollte der Notfall-Benutzer wieder entfernt werden:

userdel -r notfalluser

Außerdem PasswordAuthentication in der sshd_config wieder auf no setzen und den SSH-Dienst neu starten – um den ursprünglichen, sicheren Zustand wiederherzustellen:

nano /etc/ssh/sshd_config
# PasswordAuthentication no

systemctl restart ssh