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 – ganz ohne physischen Konsolenzugang. Diese Anleitung richtet sich an KMU-Admins und Selfhoster, die ihren netcup VPS oder Root-Server eigenständig aus kritischen Situationen retten wollen.

Voraussetzungen

• netcup VPS oder Root-Server (KVM-basiert)
• Zugang zum Server Control Panel (SCP): servercontrolpanel.de
• SSH-Client (Windows Terminal, PuTTY, macOS/Linux Terminal)
• IP-Adresse des betroffenen Servers (im SCP unter „Network" einsehbar)
• Ca. 20 Minuten Zeit

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. Öffne das SCP, wähle deinen Server und klicke unter Control auf ACPI Shutdown. Warte, bis der Status „Powered off" anzeigt – das kann 30 bis 60 Sekunden dauern. Erst dann ist der nächste Schritt möglich.

Navigiere im SCP zu Media → Rescue System → Activate und bestätige mit OK. Das SCP zeigt dir jetzt ein einmaliges Passwort an. Dieses Passwort gilt ausschließlich für diese Rescue-Session – notiere es sofort, es wird kein zweites Mal angezeigt.

SCP-Aktion	Beschreibung	Empfehlung
ACPI Shutdown	Sauberes Herunterfahren per Signal	Vor Rescue-Aktivierung verwenden
Power Off	Harter Abschalter (Datenverlust möglich)	Nur wenn ACPI nicht reagiert
Rescue Activate	Startet Grml, zeigt Einmalpasswort	Server muss AUS sein
VNC-Konsole	Browser-Konsolenzugang zu Grml	Fallback wenn SSH-Passwort abgelehnt
Rescue Deactivate	Fährt herunter, stellt normalen Boot wieder her	Danach Start klicken
Set Root Password	Setzt neues Root-PW direkt (ohne Rescue)	Nur Linux + unverschlüsselt + Server AUS

Schritt 2: Per SSH ins Rescue-System einloggen

Grml startet automatisch mit Netzwerk-Konnektivität (IPv4 und IPv6). Verbinde dich mit deiner Server-IP und dem im SCP notierten Einmalpasswort:

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

Beim ersten Verbinden erscheint eine Host-Key-Warnung – das ist normal, da Grml bei jedem Start neue SSH-Schlüssel erzeugt. Bestätige mit yes.

Verifizieren: Nach dem Login siehst du den Grml-Prompt, z. B. root@grml:~#. Ein uname -a sollte „Linux grml …" ausgeben.

Fallback: VNC-Konsole und SSH manuell starten

Es gibt einen bekannten Community-Bug: Das vom SCP generierte Einmalpasswort wird von Grml gelegentlich abgelehnt. In diesem Fall öffne im SCP die VNC-Konsole (kein separates Passwort nötig – direkter Browser-Zugang). Im Grml-Terminal gibst du folgendes ein:

# Im Grml-Terminal der VNC-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, nutze den eingebauten Netzwerk-Wizard:

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)

Merke dir die Partitionsnummer der Root-Partition – in aller Regel /dev/vda3. Falsche Partitionsnummern beim Mounten führen zu unbrauchbaren chroot-Umgebungen, also die Ausgabe genau lesen.

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 bereits gemounteten Partition kann das Dateisystem irreparabel beschädigen – also diesen Schritt unbedingt vor dem Mounten erledigen.

# 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 müssen die virtuellen Dateisysteme des Kernels eingebunden werden. Die Reihenfolge ist dabei wichtig:

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

Die Änderung ist nach dem nächsten Neustart aktiv. Das neue Passwort wird in /etc/shadow des installierten Systems gespeichert – das Grml-System selbst wird nicht verändert.

Schritt 7: Bootloader reparieren (bei Bedarf)

Wenn der Server nicht mehr bootet und der Verdacht auf einen beschädigten GRUB-Bootloader besteht, kann dieser ebenfalls aus dem chroot heraus repariert werden:

# Innerhalb des chroot (Debian/Ubuntu/AlmaLinux mit GRUB2):
update-grub
grub-install /dev/vda

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

Schritt 8: chroot beenden und Partitionen aushängen

Nach allen Änderungen das chroot verlassen und alle Mounts sauber aushängen – in umgekehrter Reihenfolge:

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

Schritt 9: Rescue-System deaktivieren und Server neu starten

Zurück im SCP: Media → Rescue System → Deactivate → OK. Der Server fährt automatisch herunter. Danach muss er manuell gestartet werden – klicke im SCP auf Start. Der Server bootet jetzt wieder vom installierten System.

Wichtig: Vergisst du die Deaktivierung, bootet der Server beim nächsten Start erneut in Grml statt in dein installiertes System.

Szenario	Befehl im Rescue-System	Hinweis
Partitionslayout ermitteln	lsblk	Immer erster Schritt
Dateisystem prüfen (ext4)	fsck -fy /dev/vdaX	Nur auf ungemounteter Partition
Dateisystem prüfen (XFS)	xfs_repair /dev/vdaX	Nur auf ungemounteter Partition
Partition mounten	mount /dev/vdaX /mnt	X = Partitionsnummer aus lsblk
chroot einrichten	proc/sysfs/dev mounten + chroot /mnt /bin/bash	Reihenfolge beachten
Root-Passwort reset	passwd root (im chroot)	Wirkt nach Neustart
Bootloader reparieren	grub-install /dev/vda + update-grub	Im chroot ausführen
Netzwerk konfigurieren	grml-network → netcardconfig	Falls keine Auto-IP

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

Wenn das installierte Linux auf einer unverschlüsselten Festplatte läuft und du nur das Root-Passwort zurücksetzen willst, 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 ist das Rescue-System zwingend.

Troubleshooting / Typische Fehler

Rescue-Aktivierung funktioniert nicht

Der häufigste Grund: Der Server läuft noch. Prüfe im SCP den Server-Status. Falls ACPI Shutdown nicht reagiert, kannst du als letzten Ausweg Power Off nutzen – dabei besteht jedoch Datenverlustrisiko für laufende Prozesse. Warte nach Power Off kurz, bevor du Rescue aktivierst.

SSH-Login mit SCP-Passwort schlägt fehl

Dies ist ein bekannter, gelegentlich auftretender Bug. Lösung: VNC-Konsole 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

Falls systemctl-Befehle im chroot mit „Failed to connect to bus" scheitern, fehlt der /run-Bind-Mount. Verlasse das chroot kurz, führe mount -o bind /run /mnt/run aus und wechsle 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. Halte die Rescue-Session so kurz wie möglich und verwende ein starkes, einzigartiges Passwort, wenn du eines über die VNC-Konsole selbst setzt.

Häufige Fragen

Kann ich 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. Warte nach der Rescue-Aktivierung kurz, bevor du dich per SSH verbindest – der SSH-Dienst startet automatisch, sobald Grml vollständig geladen ist.

Welche Grml-Version verwendet netcup?

netcup setzt auf die jeweils aktuelle stabile Grml-Version ein – aktuell Grml 2026.04 (veröffentlicht 30. April 2026). netcup ist offizieller Sponsor des Grml-Projekts.

Was passiert, wenn ich vergesse, das Rescue-System zu deaktivieren?

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

Kann ich 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 ist ein mächtiges Werkzeug, das sich dank der vollständigen SCP-Integration auch ohne physischen Serverkontakt ferngesteuert nutzen lässt. Der typische Einsatz – 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. Für regelmäßige Wartung empfiehlt sich trotzdem der vorausschauende Einsatz von SSH-Key-Authentifizierung, damit Passwort-Probleme gar nicht erst entstehen. Und wer seinen VPS grundsätzlich absichern will, findet in der Anleitung VPS absichern und härten mit UFW, SSH-Keys und Fail2Ban einen guten Einstieg.

Weiterführende Anleitungen und Quellen

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