Ubuntu 22.04 Server / Als root lokal und per SSH anmelden

Unter Ubuntu 22.04 Server arbeiten Sie üblicherweise mit Root-Rechten, indem Sie sich mit einem normalen Konto anmelden und sudo -i ausführen. Für die direkte Root-Anmeldung sind Passwort und Anmelderichtlinie getrennt zu prüfen; bei SSH müssen außerdem PermitRootLogin und die Authentifizierungsmethoden passen.

Root-Rechte und direkte Anmeldung unterscheiden

Root verwaltet das gesamte System. Ubuntu sperrt das Root-Passwort standardmäßig und lässt berechtigte normale Benutzer sudo mit ihren eigenen Zugangsdaten verwenden. Das Root-Konto existiert weiterhin. Dies beschreibt die Ubuntu-Dokumentation zur Benutzerverwaltung.

Benötigen Sie nur eine Administrations-Shell, verwenden Sie die folgenden Befehle. Üblicherweise authentifizieren Sie sich mit dem Passwort des normalen Kontos; maßgeblich ist die sudo-Richtlinie. Prüfen Sie, ob whoami den Wert root ausgibt, und kehren Sie danach mit exit zurück. Das aktiviert weder das Root-Passwort noch ändert es SSH.

sudo -i
whoami
exit

Setzen Sie ein Root-Passwort nur separat, wenn Sie eine Passwortanmeldung an der Konsole oder einen Wechsel mit su - benötigen. Die erste sudo-Abfrage betrifft Ihr normales Konto, die nächsten beiden Eingaben legen das neue Root-Passwort fest. Eingaben werden nicht angezeigt.

sudo passwd root
su -
whoami
exit

su - verwendet das eben gesetzte Root-Passwort. Dadurch werden nicht automatisch alle Anmeldewege erlaubt: PAM (Pluggable Authentication Modules, austauschbare Authentifizierungsmodule) sowie Konsolen- und Fernzugriffsrichtlinien können sie beschränken. sudo -i erläutert das sudo-Handbuch für Ubuntu 22.04.

Zugriff und bestehende SSH-Richtlinie prüfen

Die Anleitung betrifft OpenSSH auf einem Ubuntu-22.04-Server, den Sie verwalten. Lassen Sie die bestehende SSH-Sitzung des normalen Kontos offen und bereiten Sie eine physische oder Cloud-Rettungskonsole vor. Ziehen Sie im Produktivbetrieb zuerst ein normales Konto mit anschließendem sudo vor. Ist direkter Root-Zugriff erforderlich, legen Sie auch Schlüsselverfahren und erlaubtes Verwaltungsnetz fest.

Fehlt der SSH-Server, führen Sie sudo apt update und danach sudo apt install openssh-server aus. Prüfen Sie den Dienst mit sudo systemctl status ssh.service. Sie benötigen die tatsächliche Serveradresse und den SSH-Port; Firewall und Cloud-Regeln müssen den Verwaltungszugang erlauben.

Sichern Sie die Konfiguration und suchen Sie die relevanten Direktiven vor Änderungen. Existiert der Sicherungsname schon, wählen Sie einen anderen. Bewahren Sie Backups wie im Beispiel außerhalb von Verzeichnissen auf, die über *.conf eingelesen werden.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.before-root-login
sudo cp -a /etc/ssh/sshd_config.d /etc/ssh/sshd_config.d.before-root-login
sudo grep -RnsE '^[[:space:]]*(Include|Match|PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|AuthenticationMethods|AllowUsers|DenyUsers|AllowGroups|DenyGroups)' /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Die Serverdatei heißt sshd_config, die Clientdatei dagegen ssh_config. Ubuntu 22.04 lädt gewöhnlich zuerst /etc/ssh/sshd_config.d/*.conf. Für die meisten Direktiven gilt der zuerst ermittelte Wert; ein Eintrag am Dateiende überschreibt daher möglicherweise nichts. Untersuchen Sie Include-Reihenfolge, Match-Bedingungen und Cloud-Dateien und prüfen Sie die wirksamen Werte.

Laut sshd_config-Handbuch für Ubuntu 22.04 erlaubt PermitRootLogin yes Root-Zugriff bei erfüllten weiteren Bedingungen. prohibit-password verbietet Passwort- und Keyboard-Interactive-Authentifizierung für root, kann aber öffentliche Schlüssel zulassen. no verbietet Root-Anmeldung per SSH. Eine auskommentierte Standardzeile beweist nicht die wirksame Richtlinie.

Root-SSH mit Passwort konfigurieren

Diese Methode öffnet die Root-Passwortauthentifizierung; wählen Sie sie nur bei entsprechendem Verwaltungsbedarf. Setzen Sie mit sudo passwd root das Passwort und bearbeiten Sie die tatsächlich vorrangige Konfiguration mit sudoedit /etc/ssh/sshd_config oder die passende Fragmentdatei. Das Folgende ist ein Richtlinienbeispiel, keine Aufforderung zum ungeprüften Anhängen.

PermitRootLogin yes
PasswordAuthentication yes

PermitRootLogin yes allein reicht nicht. Passwortauthentifizierung, AuthenticationMethods, Benutzer- oder Gruppenbeschränkungen, PAM und Kontostatus müssen ebenfalls passen. Ein globales PasswordAuthentication yes kann andere Benutzer betreffen; prüfen Sie eine mögliche Ausweitung der Richtlinie. Deaktivieren Sie dafür weder Firewall noch Mehrfaktorauthentifizierung.

Speichern allein aktiviert die Änderung nicht vollständig. Führen Sie zuerst die unten beschriebene Prüfung und das Neuladen durch. Ersetzen Sie 192.0.2.20 durch die echte Serveradresse. Für einen anderen Port als den Standardport 22 verwenden Sie ssh -p PORT mit der tatsächlichen Nummer.

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@192.0.2.20

Dieser Test wählt Passwort statt öffentlichem Schlüssel. Verlangt der Server weitere Authentifizierung, reicht das Passwort allein nicht. Prüfen Sie den Hostschlüssel-Fingerabdruck über einen vertrauenswürdigen Verwaltungsweg; schalten Sie die Prüfung bei einer Warnung über geänderte Schlüssel nicht ab.

Öffentlichen Schlüssel für Root-SSH verwenden

Der Client behält den privaten Schlüssel; auf dem Server wird nur der zugehörige öffentliche registriert. Ein aktiviertes Root-Passwort ist dafür keine Voraussetzung. Installieren Sie den Schlüssel über eine bestehende Administrationssitzung oder Konsole, ohne vorher Root-SSH per Passwort zu öffnen.

Fehlt ein geeigneter Client-Schlüssel, erzeugen Sie ihn mit ssh-keygen -t ed25519. Wählen Sie einen neuen Dateinamen, überschreiben Sie keinen vorhandenen Schlüssel und schützen Sie den privaten mit einer Passphrase. Registrieren Sie die einzelne Zeile aus ~/.ssh/id_ed25519.pub. Kopieren Sie den privaten Schlüssel ohne .pub niemals auf den Server.

Bereiten Sie in der bestehenden Administrationssitzung des Servers Verzeichnis- und Dateirechte wie unten vor und ergänzen Sie im Editor die öffentliche Schlüsselzeile. Bestehende Schlüssel bleiben erhalten; vermeiden Sie Duplikate. Bei anderem Dateinamen verwenden Sie den zugehörigen öffentlichen Schlüssel.

sudo install -d -m 700 -o root -g root /root/.ssh
sudo touch /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudoedit /root/.ssh/authorized_keys

Dieses Beispiel nutzt den Standardpfad für autorisierte Schlüssel. Prüfen Sie den tatsächlichen Pfad bei abweichendem AuthorizedKeysFile. Wählen Sie die folgende Richtlinie gegen Root-Passwortauthentifizierung, korrigieren Sie frühere widersprüchliche Einträge und validieren Sie anschließend.

PermitRootLogin prohibit-password
PubkeyAuthentication yes

Nach Prüfung und Anwendung auf dem Server verbinden Sie sich wie folgt vom Client. Eine abgefragte Passphrase gehört zum privaten Client-Schlüssel, nicht zum Root-Konto. Auch Schlüsselzugriff muss PAM-, Konto- und Zugriffsrichtlinien erfüllen.

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes root@192.0.2.20

Konfiguration prüfen und neue Sitzung testen

1. Prüfen Sie zuerst Syntax und Hostschlüssel auf dem Server. Ein erfolgreicher -t-Test erzeugt gewöhnlich keine Ausgabe. Bei Fehlern korrigieren Sie Datei und Zeile vor dem Neuladen. -T zeigt die wirksame Konfiguration; mit -C werden Match-Bedingungen für die angegebene Verbindung ausgewertet.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=root,addr=192.0.2.10,host=admin.example | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods|authorizedkeysfile|allowusers|denyusers|allowgroups|denygroups) '

Ersetzen Sie 192.0.2.10 durch die Verwaltungsclient-Adresse aus Sicht des Servers und admin.example durch den zu prüfenden Client-Hostnamen. Bei Match LocalAddress oder LocalPort geben Sie außerdem laddr und lport in -C an. Bei unerwarteten Werten prüfen Sie zuerst Vorrang und Bedingungen. Die Optionen beschreibt das sshd-Handbuch für Ubuntu 22.04.

2. Sind Syntax und wirksame Werte korrekt, laden Sie den Dienst neu. Lassen Sie die Administrationssitzung offen und testen Sie Passwort oder Schlüssel in einem weiteren Clientfenster.

sudo systemctl reload ssh.service
sudo systemctl is-active ssh.service

3. Ein Dienststatus active garantiert keine erfolgreiche neue Anmeldung. Prüfen Sie in der neuen Root-Sitzung whoami auf root und id -u auf 0. Testen Sie auch eine neue normale Anmeldung mit sudo. Benutzer-, Schlüssel-, Netzwerk- und Kontobedingungen können den Zugriff weiterhin verweigern.

Fehler eingrenzen und direkten Root-Zugriff zurücknehmen

Bei Permission denied prüfen Sie Authentifizierung, Konto und Zugriffsrichtlinie. Bei Zeitüberschreitung oder abgelehnter Verbindung untersuchen Sie Adresse, Port, Dienst und Firewall getrennt. Nutzen Sie serverseitig sudo journalctl -u ssh.service -n 50 --no-pager und clientseitig ssh -v root@192.0.2.20. Schwärzen Sie Adressen, Benutzernamen und andere sensible Angaben vor dem Teilen.

Um Root-SSH wieder zu sperren, setzen Sie das wirksame PermitRootLogin auf no, prüfen sshd -t und verbindungsspezifisches sshd -T und führen sudo systemctl reload ssh.service aus. Stellen Sie auch vorübergehend geänderte Passwortrichtlinien wieder her. Ändern Sie nur betroffene Dateien und Einträge zurück; überschreiben Sie nicht pauschal das ganze Fragmentverzeichnis.

Prüfen Sie zunächst SSH und sudo mit einem anderen normalen Konto. Wird das für diese Arbeit aktivierte Root-Passwort nicht mehr benötigt, sperren Sie es wie folgt. Laut passwd-Handbuch sperrt -l nur das Passwort, nicht alle Zugriffsarten wie öffentliche Schlüssel. Prüfen Sie die SSH-Sperre separat über PermitRootLogin no.

sudo passwd -l root

Passwortsperre oder SSH-Änderung beendet bestehende Root-Sitzungen nicht automatisch. Schließen Sie nach der Arbeit selbst geöffnete Root-Shells mit exit. Bei nötiger Wiederherstellung nutzen Sie die offene normale Sitzung oder Rettungskonsole und gehen nach Backups und Änderungsprotokoll vor.