netcup Rescue-System nutzen: VPS retten, Passwort zurücksetzen, Dateisystem reparieren

Ein gesperrter SSH-Zugang, ein vergessenes Root-Passwort oder ein beschädigtes Dateisystem – solche Situationen können jeden VPS-Betreiber treffen. netcup bietet dafür das Rescue-System auf Basis von Grml, einer schlanken Debian-Live-Distribution speziell für Systemadministratoren. Das Besondere: Die Aktivierung erfolgt vollständig über das Server Control Panel (SCP), SSH-Zugang gibt es mit einem einmaligen Passwort, ohne physischen Konsolenzugang. Diese Anleitung richtet sich an Administratoren, die ihren netcup VPS oder Root-Server selbst wieder lauffähig machen.

Voraussetzungen

1. netcup VPS oder Root-Server (KVM-basiert)
2. Zugang zum Server Control Panel (SCP): servercontrolpanel.de
3. SSH-Client (Windows Terminal, PuTTY, macOS/Linux Terminal)
4. IP-Adresse des betroffenen Servers (im SCP unter „Network“ einsehbar)
5. Etwa 20 Minuten Zeit; zusätzliche Hardware oder Ressourcen brauchen Sie nicht, Grml läuft im RAM des vorhandenen Servers

Schritt 1: Server sauber herunterfahren und Rescue-System aktivieren

Das Rescue-System lässt sich nur aktivieren, wenn der Server vollständig ausgeschaltet ist. Ein laufender Server blockiert die Aktivierung. Öffnen Sie das SCP, wählen Sie Ihren Server und klicken Sie unter Control auf ACPI Shutdown. Warten Sie, bis der Status „Powered off“ anzeigt; das kann 30 bis 60 Sekunden dauern.

Wählen Sie im SCP Media → Rescue System → Activate und bestätigen Sie mit OK. Das SCP zeigt jetzt ein einmaliges Passwort an. Es gilt nur für diese Rescue-Sitzung; notieren Sie es sofort.

Verifizieren: Im SCP steht unter Media → Rescue System der Status aktiv, und das Einmalpasswort ist notiert. Die netcup-Firewall ist in diesem Zustand abgeschaltet und lässt sich nicht aktivieren.

Schritt 2: Per SSH ins Rescue-System einloggen

Grml startet automatisch mit Netzwerk-Konnektivität (IPv4 und IPv6). Verbinden Sie sich mit Ihrer Server-IP und dem im SCP notierten Einmalpasswort:

ssh root@<server-ip>
# Passwort: das im SCP angezeigte Einmalpasswort

Beim Verbinden erscheint eine Host-Key-Warnung, weil Grml andere SSH-Schlüssel nutzt als Ihr installiertes System. Entfernen Sie den alten Eintrag mit ssh-keygen -R <server-ip> und bestätigen Sie den neuen Schlüssel mit yes. Denken Sie daran, den Eintrag nach der Rettung erneut zu entfernen.

Verifizieren: Nach dem Login erscheint der Grml-Prompt, z. B. root@grml:~#, und uname -a gibt „Linux grml …“ aus.

Fallback: VNC-Konsole und SSH manuell starten

Wird das Einmalpasswort abgelehnt, öffnen Sie im SCP die Bildschirmkonsole (Screen, direkter Browser-Zugang ohne eigenes Passwort). Im Grml-Terminal geben Sie Folgendes ein:

# Im Grml-Terminal der SCP-Konsole:
passwd root
# Neues Passwort zweimal eingeben
systemctl start ssh
# Jetzt per SSH mit dem selbst gesetzten Passwort verbinden

Netzwerk manuell konfigurieren (falls keine automatische IP)

Erhält Grml beim Start keine automatische IP-Adresse, nutzen Sie den eingebauten Netzwerk-Assistenten:

grml-network
# Im Dialog: netcardconfig auswählen
# VLAN-Konfiguration: No
# Auto-enable at boot: Yes

Schritt 3: Partitionslayout ermitteln

Die Festplatte des installierten Systems wird im Rescue-Betrieb nicht automatisch gemountet. Der erste Schritt ist immer, das Partitionslayout zu verstehen:

lsblk

Eine typische Ausgabe bei einem netcup VPS sieht so aus:

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    252:0    0   50G  0 disk
├─vda1 252:1    0    1G  0 part   # EFI/Boot
├─vda2 252:2    0    2G  0 part   # /boot
└─vda3 252:3    0   47G  0 part   # / (Root-Partition)

Das Layout unterscheidet sich je nach Image. Ermitteln Sie die Root-Partition deshalb nicht nach Nummer, sondern nach Größe und Dateisystem: lsblk -f zeigt zusätzlich Typ (ext4, xfs, crypto_LUKS) und Label.

Verifizieren: Sie haben die Root-Partition (größte Partition mit ext4 oder xfs) und eine eventuelle /boot-Partition notiert; die Spalte MOUNTPOINTS ist für beide leer.

Schritt 4: Dateisystem prüfen und reparieren (fsck)

Ist das Dateisystem beschädigt, muss fsck auf der ungemounteten Partition ausgeführt werden. Ein fsck auf einer gemounteten Partition kann das Dateisystem irreparabel beschädigen; erledigen Sie diesen Schritt deshalb vor dem Mounten.

# Für ext4 (häufigste Variante bei netcup-Images):
fsck -fy /dev/vda3

# Für XFS-Partitionen:
xfs_repair /dev/vda3

Die Option -f erzwingt die Prüfung auch wenn das Dateisystem sauber markiert ist, -y beantwortet alle Reparaturfragen automatisch mit „Ja“. Bei schwerwiegenden Fehlern kann der Vorgang mehrere Minuten dauern.

Verifizieren: fsck endet mit Exit-Code 0 (kein Fehler) oder 1 (Fehler wurden repariert). Ein Exit-Code von 4 oder höher weist auf ernste Probleme hin, die manuelle Eingriffe erfordern können.

Schritt 5: Root-Partition mounten und chroot einrichten

Jetzt wird die Root-Partition ins Rescue-System eingehängt. Falls eine separate /boot-Partition vorhanden ist (typisch: /dev/vda2), wird diese ebenfalls gemountet:

mount /dev/vda3 /mnt

# Separate /boot-Partition, falls vorhanden:
mount /dev/vda2 /mnt/boot

Für eine funktionsfähige chroot-Umgebung binden Sie die virtuellen Dateisysteme des Kernels ein:

mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev

# Optional für systemd-basierte Systeme (z. B. Ubuntu, Debian, Alma, Rocky):
mount -o bind /run /mnt/run

Ohne den /run-Bind-Mount funktionieren manche systemctl-Aufrufe im chroot nicht korrekt. Anschließend in das installierte System wechseln:

chroot /mnt /bin/bash

Verifizieren: Der Prompt wechselt, und cat /etc/os-release zeigt das installierte Betriebssystem (nicht Grml) an.

Schritt 6: Root-Passwort zurücksetzen

Im chroot lässt sich das Root-Passwort des installierten Systems direkt setzen:

# Innerhalb des chroot:
passwd root
# Neues Passwort zweimal eingeben

Das neue Passwort steht in /etc/shadow des installierten Systems und gilt ab dem nächsten Start; Grml selbst bleibt unverändert. Erlaubt Ihr System keinen Root-Login per SSH, setzen Sie stattdessen das Passwort Ihres Admin-Benutzers mit passwd BENUTZERNAME.

Verifizieren: passwd meldet „password updated successfully“, und passwd -S root zeigt den Status P mit heutigem Datum.

Schritt 7: Bootloader reparieren (bei Bedarf)

Bootet der Server nicht mehr und ist GRUB beschädigt, reparieren Sie den Bootloader aus dem chroot heraus:

# Innerhalb des chroot, Debian/Ubuntu:
grub-install /dev/vda
update-grub

# Innerhalb des chroot, AlmaLinux/Rocky Linux (BIOS-Boot):
grub2-install /dev/vda
grub2-mkconfig -o /boot/grub2/grub.cfg

Hierbei ist /dev/vda die gesamte Festplatte (ohne Partitionsnummer), nicht eine einzelne Partition.

Verifizieren: grub-install meldet „Installation finished. No error reported.“, und die Konfigurationserzeugung listet mindestens einen gefundenen Kernel (Found linux image).

Schritt 8: chroot beenden und Partitionen aushängen

Verlassen Sie nach allen Änderungen das chroot und hängen Sie alle Mounts in umgekehrter Reihenfolge aus:

exit
# Zurück im Grml-Rescue-System

umount /mnt/run    # falls gemountet
umount /mnt/proc
umount /mnt/sys
umount /mnt/dev
umount /mnt/boot   # falls separate Boot-Partition
umount /mnt

Verifizieren: lsblk zeigt für keine vda-Partition mehr einen Mountpoint. Meldet umount „target is busy“, prüfen Sie mit fuser -vm /mnt, welcher Prozess noch zugreift.

Schritt 9: Rescue-System deaktivieren und Server neu starten

Zurück im SCP: Media → Rescue System → Deactivate → OK. Der Server fährt automatisch herunter. Starten Sie ihn danach manuell mit Start im SCP. Der Server bootet jetzt wieder vom installierten System.

Wichtig: Ohne Deaktivierung bootet der Server beim nächsten Start erneut in Grml statt in Ihr installiertes System.

Verifizieren: Die SSH-Anmeldung mit dem neuen Passwort gelingt, und cat /etc/os-release zeigt Ihr installiertes System. Aktivieren Sie die netcup-Firewall bei Bedarf wieder.

Alternative: Passwort direkt über SCP setzen (ohne Rescue)

Wenn das installierte Linux auf einer unverschlüsselten Festplatte läuft und Sie nur das Root-Passwort zurücksetzen möchten, gibt es einen schnelleren Weg ohne Rescue-System: Im SCP unter Access → Set Root Password ein neues Passwort eingeben und mit Set Password bestätigen. Der Server muss dafür ausgeschaltet sein. Bei verschlüsselten Festplatten (z. B. LUKS) oder Windows-Systemen ist dieser Weg nicht geeignet; hier brauchen Sie das Rescue-System.

Troubleshooting / Typische Fehler

Rescue-Aktivierung funktioniert nicht

Der häufigste Grund: Der Server läuft noch. Prüfen Sie im SCP den Server-Status. Reagiert ACPI Shutdown nicht, nutzen Sie als letzten Ausweg Power Off; dabei können Daten laufender Prozesse verloren gehen. Warten Sie danach kurz, bevor Sie Rescue aktivieren.

SSH-Login mit SCP-Passwort schlägt fehl

Lösung: Bildschirmkonsole (Screen) im SCP öffnen, dort passwd root und systemctl start ssh ausführen, dann mit selbst gewähltem Passwort per SSH verbinden.

fsck meldet schwerwiegende Fehler

Bei sehr schwerer Dateisystem-Beschädigung kann fsck nicht alle Fehler automatisch reparieren. In diesem Fall empfiehlt sich ein Backup der noch lesbaren Daten (rsync aus dem chroot heraus), bevor weitere Reparaturversuche unternommen werden.

Verschlüsselte Festplatten (LUKS)

Das Rescue-System kann LUKS-verschlüsselte Partitionen ohne den Encryption-Key nicht mounten. Der Standard-Workflow gilt ausschließlich für unverschlüsselte Setups. Bei LUKS sind zusätzliche Schritte (cryptsetup luksOpen) erforderlich.

systemctl-Fehler im chroot

Scheitern systemctl-Befehle im chroot mit „Failed to connect to bus“, fehlt meist der /run-Bind-Mount. Verlassen Sie das chroot kurz, führen Sie mount -o bind /run /mnt/run aus und wechseln Sie erneut per chroot /mnt /bin/bash hinein.

Sicherheitshinweis: Firewall während des Rescue-Betriebs

Die netcup-Firewall ist im Rescue-Betrieb deaktiviert und kann nicht eingeschaltet werden. Der Server ist in diesem Zeitraum ohne Firewall-Schutz erreichbar. Halten Sie die Rescue-Sitzung so kurz wie möglich und verwenden Sie ein starkes, einzigartiges Passwort, wenn Sie eines über die Konsole selbst setzen.

Häufige Fragen

Können Sie das Rescue-System auch für Windows-Server nutzen?

Ja. Grml kann auch die Windows-Systempartition mounten. Für ein Windows-Passwort-Reset wird allerdings ein zusätzliches Tool wie chntpw benötigt, das nachinstalliert werden muss (apt-get install chntpw).

Wie lange dauert der Boot von Grml?

In der Regel 30 bis 90 Sekunden. Warten Sie nach der Rescue-Aktivierung kurz, bevor Sie sich per SSH verbinden; der SSH-Dienst startet automatisch, sobald Grml vollständig geladen ist.

Welche Grml-Version verwendet netcup?

netcup nennt keine feste Version. Im laufenden Rescue-System zeigt cat /etc/grml_version die tatsächlich genutzte Version; die aktuelle stabile Grml-Version ist 2026.09 (Stand September 2026).

Was passiert, wenn Sie vergessen, das Rescue-System zu deaktivieren?

Der Server bootet beim nächsten Start wieder in Grml. Das installierte System ist davon nicht beschädigt. Deaktivieren Sie Rescue im SCP und klicken Sie dann auf Start.

Können Sie fsck auch auf einer gemounteten Partition ausführen?

Nein, das ist gefährlich und kann das Dateisystem irreparabel beschädigen. fsck immer auf der ungemounteten Partition ausführen, bevor mount aufgerufen wird.

Fazit

Das netcup Rescue-System lässt sich vollständig über das SCP steuern. Der typische Einsatz, ein Passwort-Reset per chroot, ist in unter 20 Minuten erledigt. Wer die Reihenfolge kennt (erst fsck auf ungemounteter Partition, dann mounten, dann chroot), vermeidet die häufigsten Fallstricke. Vorbeugend empfiehlt sich SSH-Key-Authentifizierung, damit Passwort-Probleme gar nicht erst entstehen. Für die grundsätzliche Absicherung siehe VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban.

Weiterführende Anleitungen und Quellen

1. Das netcup SCP erklärt: Alle Funktionen im Überblick
2. Betriebssystem-Image bei netcup wechseln: Reinstall über das SCP
3. VPS absichern und härten: UFW, SSH-Keys und Fail2Ban
4. SSH-Key-Authentifizierung einrichten – Linux & Windows
5. netcup Helpcenter: Rescue System (offiziell)
6. grml.org – Grml Live-Linux Projektseite