SSH-Anmeldung verwalten und Zertifikate verwenden

Wenn die Anmeldung per Schlüssel funktioniert, muss der Server keine Passwörter mehr über das Netzwerk akzeptieren. Das verhindert jegliche Versuche, Passwörter zu erraten. In diesem Abschnitt deaktivieren Sie auf sichere Weise die Passwort- und Root-Anmeldung. Abschließend sehen wir, wie SSH-Zertifikate es erleichtern, den Zugriff auf viele Server zu verwalten.

Voraussetzungen

• Schlüsselbasierte Anmeldung funktioniert, siehe SSH Level 2.
• Dein Benutzer hat sudo-Rechte, siehe Gjør serveren klar.
• Die Konsole in Proxmox ist geöffnet. Sie dient als Ausweichweg, falls du dich bei der SSH-Anmeldung aussperrst.

Passwort- und Root-Anmeldung deaktivieren

Der SSH-Dienst liest Einstellungen aus /etc/ssh/sshd_config sowie aus Dateien im Ordner /etc/ssh/sshd_config.d/. Erstellen Sie eine eigene Datei, damit es leicht ist zu sehen, was Sie geändert haben, und Änderungen rückgängig zu machen:

sudo nano /etc/ssh/sshd_config.d/10-sicher.conf

Eingabe:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no deaktiviert die normale Passwortsicherheit. KbdInteractiveAuthentication no deaktiviert auch die interaktive Tastatureingabeauthentifizierung, die andernfalls über PAM Passwörter akzeptieren kann. PermitRootLogin no blockiert die Root-Anmeldung vollständig.

Für die meisten SSH-Einstellungen gilt der erste Wert, den der Dienst liest. Ihre Datei gewinnt daher nicht automatisch gegenüber anderen Dateien: Die Position von Include, frühere Einstellungen und mögliche Match-Blöcke können das Ergebnis beeinflussen. Prüfen Sie die wirksamen Werte, bevor Sie die Änderung anwenden.

Prüfen Sie die Einstellungen, bevor Sie sie übernehmen:

sudo sshd -t

Wenn keine Meldung angezeigt wird, ist die Syntax gültig. Prüfen Sie anschließend, welche Werte die neue Konfiguration ergibt:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) '

Alle drei müssen no anzeigen. Wenn andere Werte zurückgegeben werden, untersuchen Sie vor dem Fortfahren die Datei /etc/ssh/sshd_config sowie die Dateien, die sie einbindet. Mit Match-Regeln überprüfen Sie auch die aktuelle Verbindung mit sudo sshd -T -C user=user,addr=KUNDEN-IP,host=KUNDENAME. Ersetzen Sie die Beispielwerte durch Benutzername, Kundenadresse und Kundennamen der Anmeldung, die Sie testen. Führen Sie dieselbe Überprüfung für die drei Einstellungen durch.

Wenn die Werte korrekt sind, laden Sie die Änderung neu:

The input contains no comments; therefore, the code remains unchanged.

sudo systemctl reload ssh

Schließen Sie nicht das Fenster, in dem Sie angemeldet sind. Öffnen Sie ein neues Terminalfenster und testen Sie:

ssh debian-vm                 # sollte funktionieren
ssh root@SERVER-IP            # sollte abgewiesen werden
ssh -o PubkeyAuthentication=no user@SERVER-IP   # sollte abgewiesen werden, keine Passwortabfrage

Das Passwort des Benutzers wird weiterhin für sudo benötigt. Es wird auf dem Server eingegeben, nicht über das Netzwerk.

Vertiefung: SSH-Zertifikate

Bei zehn Servern und fünf Administratoren muss jeder Schlüssel auf jedem Server vorhanden sein. Das ergibt fünfzig Einträge in der authorized_keys-Datei, und wenn jemand ausscheidet, muss der Schlüssel überall entfernt werden.

Mit Zertifikaten signiert ein Zertifizierungsstelle (CA) Ihren Schlüssel. Die Server vertrauen der CA, nicht dem einzelnen Schlüssel. Das Zertifikat enthält außerdem:

• Principals: die Namen, für die das Zertifikat gilt, zum Beispiel admin
• Gültigkeitsdauer: wann das Zertifikat seine Gültigkeit verliert

Server einrichten

Sie benötigen den öffentlichen Schlüssel der von demjenigen, der die CA betreibt (z. B. dem Lehrer), stammt. Legen Sie ihn auf dem Server ab:

The provided bash command contains no comments (lines starting with #), so there is nothing to translate. The code remains unchanged.

Bestimmen Sie welche Principals sich als Benutzer user anmelden dürfen:

sudo mkdir -p /etc/ssh/auth_principals
echo admin | sudo tee /etc/ssh/auth_principals/user

Informiere den SSH-Dienst über das Zertifikat (CA):

The provided code block contains no comments (lines starting with #) that need translation; it is a single executable command. Therefore, the content remains unchanged per the integrity requirements.

sudo nano /etc/ssh/sshd_config.d/10-lab-ca.conf

TrustedUserCAKeys /etc/ssh/lab_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

%u wird durch den Benutzernamen ersetzt, mit dem angemeldet wird. Prüfen und neu laden mit sudo sshd -t und sudo systemctl reload ssh.

Mit Zertifikat anmelden

Das Zertifikat liegt neben dem privaten Schlüssel und endet auf -cert.pub. Sehen Sie sich dessen Inhalt an:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Suche nach Principals, Valid und Signing CA. Füge das Zertifikat in ~/.ssh/config ein:

Host debian-vm
    HostName SERVER-IP
    User user
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub

Jetzt melden Sie sich mit ssh debian-vm an, obwohl Ihr Schlüssel nicht in der Datei authorized_keys auf dem Server enthalten ist.

Wie die CA signiert (für den Betreiber der CA)

ssh-keygen -t ed25519 -f lab_user_ca                  # Erstelle den CA-Schlüssel einmal und bewahre ihn sicher auf
ssh-keygen -s lab_user_ca -I elev@skolen -n admin -V +52w id_ed25519.pub

-n ist der Principal, -V die Gültigkeitsdauer und -I eine ID, die in den Serverprotokollen angezeigt wird. Der private CA-Schlüssel gewährt Zugriff auf alle Server, denen vertraut wurde, und sollte daher niemals auf einem Server abgelegt oder geteilt werden.

Falls etwas schiefgeht

1. Sie sind ausgesperrt: Melden Sie sich über die Proxmox-Konsole an, löschen Sie die Datei, die Sie unter /etc/ssh/sshd_config.d/ erstellt haben, und führen Sie sudo systemctl reload ssh aus.
2. sshd -t meldet einen Fehler: Die Meldung zeigt die Dateiname und Zeilenzahl an. Korrigieren Sie den Tippfehler, bevor Sie neu laden.
3. Das Zertifikat wird nicht akzeptiert: Stellen Sie sicher, dass der Principal im Zertifikat (ssh-keygen -L) in /etc/ssh/auth_principals/user aufgeführt ist und das Zertifikat abgelaufen ist. Auf dem Server zeigt sudo journalctl -u ssh -n 20 warum die Anmeldung abgelehnt wurde.

Wichtige Begriffe

Kontrollen

• ssh root@SERVER-IP wird abgelehnt.
• Anmeldung per Passwort über SSH wird abgelehnt.
• Sie können erklären, warum Sie vor dem Schließen des alten Fensters ein neues Fenster getestet haben.
• Vertiefung: Sie können erklären, warum eine CA auf vielen Servern einfacher ist als authorized_keys.

Quelle: OpenSSH – sshd_config.