So konfigurieren Sie den Root-SSH-Login auf Rocky Linux sicher

Sie können den SSH-Zugang für das Root-Konto auf Rocky Linux erlauben, aber es ist sicherer und einfacher zu überprüfen, ein reguläres Administratorkonto mit sudo zu verwenden. Wenn direkter Root-Zugang absolut notwendig ist, aktivieren Sie kein Passwortlogin und erlauben Sie nur die Authentifizierung mit öffentlichem Schlüssel, und wenden Sie es dann nach Überprüfung der Einstellungen und einem separaten Sitzungstest an.

Überprüfen Sie zunächst die empfohlene Methode

Die Anmeldung als regulärer Benutzer und die Ausführung nur der notwendigen Befehle mit sudo reduziert die direkte Exposition der Root-Zugangsdaten und ermöglicht die Führung benutzerspezifischer Aktivitätsprotokolle.

sudo useradd adminuser
sudo usermod -aG wheel adminuser

Nachdem Sie das Konto erstellt haben, registrieren Sie den öffentlichen Schlüssel und überprüfen Sie, dass sudo -v in einer neuen Sitzung funktioniert. Sie sollten dies testen, bevor Sie Ihre bestehende SSH-Verbindung schließen, um eine Sperrung aufgrund einer Fehlkonfiguration zu vermeiden.

Die Vorbereitung des Public-Key-Logins legt kein sudo-Passwort für ein neues Konto fest. Wenn die normale Wheel-Richtlinie das Passwort dieses Benutzers verlangt, bereiten Sie es mit sudo passwd adminuser vor und testen Sie sudo -v in einer neuen Sitzung unter der vorgesehenen Richtlinie. Gewähren Sie NOPASSWD nicht pauschal als Umgehung. Wenn adminuser bereits existiert, überprüfen Sie ihn, anstatt useradd erneut auszuführen.

Überprüfen Sie die aktuellen SSH- und Root-Login-Einstellungen

Es ist genauer, die endgültige effektive Konfiguration mit sshd -T zu überprüfen, das Include-Dateien und Standardeinstellungen kombiniert, anstatt nur eine Zeile in der Konfigurationsdatei anzusehen.

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo grep -RinE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Einstellungen unter Match-Bedingungen können je nach verbindendem Benutzer und Quelladresse unterschiedliche Ergebnisse liefern. In komplexen Umgebungen überprüfen Sie sie, indem Sie die tatsächlichen Bedingungen mit sshd -T -C angeben.

Bereiten Sie den Root-öffentlichen Schlüssel vor

Schlüsseldateien und Berechtigungseinstellungen

Registrieren Sie den öffentlichen Schlüssel eines vertrauenswürdigen Administrators im authorized_keys von Root. Ersetzen Sie die öffentliche Schlüsselzeichenfolge im folgenden Befehl durch den tatsächlichen öffentlichen Schlüssel in einer einzigen Zeile.

sudo install -d -m 700 -o root -g root /root/.ssh
echo 'ssh-ed25519 public_key_string administrator_identifier' | sudo tee -a /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo restorecon -Rv /root/.ssh

Laden Sie den privaten Schlüssel nicht auf den Server hoch. Achten Sie beim Hinzufügen des öffentlichen Schlüssels darauf, dass Zeilenumbrüche nicht unterbrochen werden und dass der Schlüssel nicht bereits registriert ist.

Einschränkungen für öffentliche Schlüssel

Wenn der Schlüssel ausschließlich für die Automatisierung bestimmt ist, können Sie mit authorized_keys-Optionen wie from=, command= und restrict die Verbindungsquelle und ausführbare Funktionen beschränken. Falsche Einschränkungen können Abläufe unterbrechen; testen Sie sie daher zuerst mit einem separaten Schlüssel.

Erfordern Sie die Authentifizierung mit öffentlichem Schlüssel in der effektiven Root-Richtlinie

Sichern Sie die Konfiguration und überprüfen Sie die Include- und Match-Struktur der Hauptdatei. OpenSSH verwendet für viele Einstellungen den zuerst erhaltenen Wert; ein Dateiname, der mit 90 beginnt, überschreibt nicht automatisch frühere Werte. Folgendes ist ein nur für root gültiger Block am Ende von /etc/ssh/sshd_config. Bearbeiten Sie einen vorhandenen wirksamen root-Match-Block, anstatt ihn zu duplizieren. Setzen Sie Match nicht ungeachtet in eine früh inkludierte Datei und ändern dadurch die Interpretation späterer globaler Einstellungen.

Match User root
    PermitRootLogin prohibit-password
    PubkeyAuthentication yes
    AuthenticationMethods publickey

prohibit-password deaktiviert das Root-Passwort und die Keyboard-Interaktive-Authentifizierung, schließt jedoch nicht jede andere Methode ohne Passwort aus. AuthenticationMethods publickey erfordert hier explizit einen öffentlichen Schlüssel. Ersetzen Sie eine von der Organisation vorgeschriebene Multifaktor-Richtlinie nicht durch dieses Beispiel mit nur einem Schlüssel.

sudo sshd -t
sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10 | grep -E "^(permitrootlogin|pubkeyauthentication|passwordauthentication|authenticationmethods) "

Ersetzen Sie den Host und die Adresse durch reale Verbindungsbedingungen. Laden Sie nur neu, nachdem die Syntax sowie die effektiven Root- und Normal-Administrator-Richtlinien korrekt sind. Halten Sie die bestehende Verbindung aufrecht, während Sie akzeptierte und abgelehnte Authentifizierungen sowie sudo in neuen Sitzungen testen.

Syntax prüfen, Konfiguration neu laden und getrennte Sitzungen testen

1. Halten Sie die aktuelle Administrator-Sitzung geöffnet.
2. Überprüfen Sie die Syntax mit sshd -t. Es sollte keine Ausgabe geben und der Exit-Status sollte 0 sein.
3. Laden Sie den SSH-Dienst neu.
4. Testen Sie die Root-Public-Key-Anmeldung in einem neuen Terminal.
5. Überprüfen Sie, dass die Passwort-Anmeldung verweigert wird und dass das bestehende Administratorkonto ordnungsgemäß funktioniert.

sudo sshd -t
sudo systemctl reload sshd
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

Wenn die Syntaxprüfung fehlschlägt, laden Sie den Dienst nicht neu. Beheben Sie den Fehler an der angegebenen Datei und Zeile. Ein Neuladen der Konfiguration ist einem Neustart vorzuziehen, um bestehende Verbindungen möglichst zu erhalten. Lassen Sie die aktuelle Sitzung dennoch geöffnet, bis eine neue Verbindung erfolgreich getestet wurde.

Möglichkeiten, den Zugriff weiter einzuschränken

Nur das Management-Netzwerk in der Firewall zulassen

Den SSH-Port nicht für das gesamte Internet öffnen; nur die ursprünglichen Adressen des VPN oder des Management-Netzwerks zulassen. Die nachstehenden Adressen sind Beispiele zu Dokumentationszwecken und sollten durch das tatsächliche Management-Netzwerk ersetzt werden.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'

Ersetzen Sie public und das Dokumentations-Subnetz durch die reale Zone und das Verwaltungsnetzwerk, und testen Sie dann die Laufzeitzulassung. Nach der Überprüfung einer neuen Verbindung fügen Sie dieselbe Rich-Regel mit --permanent hinzu. Entfernen Sie eine bestehende breite SSH-Zulassung erst, nachdem Sie die Quelle und den Konsolen-Wiederherstellungspfad bestätigt haben; speichern oder entfernen Sie keine nicht verwandten Regeln.

Auf dem Remote-Server entfernen Sie keine bestehenden Regeln, bevor Sie überprüft haben, dass die neue Zulassungsregel mit der tatsächlichen Quelle der Verbindungen übereinstimmt. Es ist sicherer, zuerst mit Laufzeitregeln zu testen und eine Konsolen-Wiederherstellungsmethode abzusichern.

Trennen Sie Benutzer und Schlüssel

• Geben Sie jedem Benutzer unterschiedliche Schlüssel aus und machen Sie nur diesen Schlüssel ungültig, wenn jemand das Unternehmen verlässt oder seine Rolle ändert.
• Unterscheiden Sie zwischen Automatisierungsschlüsseln und interaktiven Verwaltungsschlüsseln für Menschen.
• Setzen Sie ein Kennwort auf Schlüssel und verwenden Sie Agent-Weiterleitung nur, wenn es notwendig ist.
• Sammeln Sie SSH-Protokolle und abnormale Authentifizierungsversuche zentral und senden Sie Warnungen.

Fälle, in denen Sie unbedingt die Anmeldung mit Root-Passwort aktivieren müssen

Wenn Sie PermitRootLogin yes zusammen mit der Passwortauthentifizierung aktivieren, können Brute-Force-Angriffe und Credential-Leaks sofort zu vollem administrativem Zugriff führen. Wenn es unvermeidbare Gründe gibt, wie alte Geräte, verwenden Sie es ohne direkte Exposition zum Internet und kombinieren Sie ein VPN/Management-Netzwerk, kurze Anwendungszeiten, starke temporäre Passwörter und intensive Überwachung.

PermitRootLogin yes
PasswordAuthentication yes
AuthenticationMethods any

Diese Ausnahme ersetzt Werte im selben root-Match-Block, der oben verwendet wurde. Das Hinzufügen von yes, während AuthenticationMethods publickey weiterhin wirksam ist, ermöglicht keinen reinen Passwort-Login. Konto-Sperren, PAM und Firewall-Regeln gelten weiterhin. Stellen Sie die ursprüngliche Authentifizierungsrichtlinie sofort nach Ende der Ausnahme wieder her.

Dieser Wert ist nur ein Beispiel für eine Konfiguration und wird nicht empfohlen. Sobald die Arbeit abgeschlossen ist, kehren Sie sofort zu key-only oder zur Deaktivierung des Root-Logins zurück und verwerfen Sie alle verwendeten Passwörter.

Direktes Root-Login erneut deaktivieren

Überprüfen Sie zunächst einen frischen Public-Key-Login und sudo für den normalen Administrator. Setzen Sie PermitRootLogin auf no im selben effektiven root-Match-Block, der zuvor bearbeitet wurde. Versuchen Sie nicht, die Richtlinie wiederherzustellen, indem Sie einen konkurrierenden Wert in einem anderen Drop-in hinzufügen.

PermitRootLogin no

Überprüfen Sie die Syntax mit sshd -t und die effektiven Werte mit sshd -T -C für die tatsächliche Root-Verbindung, und wenden Sie dann die Konfiguration des laufenden Dienstes an. Halten Sie die aktuelle Sitzung geöffnet, während Sie überprüfen, dass eine neue Root-Anmeldung abgelehnt wird und der normale Administrator sich weiterhin verbinden kann.

Punkte zur Überprüfung, falls Probleme auftreten

Referenzdokumente

Die genaue Bedeutung von PermitRootLogin, Match und authentication-bezogenen Einstellungen finden Sie im offiziellen OpenSSH sshd_config-Handbuch.