WardtermSSH-Client
DE
Herunterladen

SSH-Schlüssel sperren, wenn jemand das Team verlässt

Ermitteln Sie den Fingerprint des Schlüssels, suchen Sie ihn in jeder authorized_keys auf jedem Server und löschen Sie diese Zeilen. Um den Schlüssel überall zu blockieren, wo er sich noch verstecken könnte, tragen Sie ihn zusätzlich in die Datei ein, die RevokedKeys in der sshd_config nennt. Bereits offene Sitzungen bleiben offen, beenden Sie diese also auch. Ändern Sie danach alle gemeinsamen Geheimnisse, die die Person kannte, denn das Entfernen eines Schlüssels deckt diese nicht ab.

Keine Lust auf eine Schleife über alle Hosts? Wardterm führt die Suche auf allen Servern auf einmal aus. Zeigen

Aktualisiert am . Fingerprint-Suche, Entfernen, RevokedKeys mit einfacher Datei und KRL, Sperren und Ablauf von Zertifikaten sowie die Wirkung von passwd -l, nologin und chage liefen mit OpenSSH 10.0 unter Debian 13 in einem Wegwerf-Container.

Den Schlüssel per Fingerprint finden

Ein Kommentar wie alice@laptop lässt sich ändern und beweist nichts, suchen Sie also nach dem Fingerprint. Wenn Sie den öffentlichen Schlüssel haben:

ssh-keygen -lf alice.pub
256 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg alice@laptop (ED25519)

Wenn Sie ihn nicht haben, zeigt das Server-Log, welchen Schlüssel jede Anmeldung benutzt hat:

Accepted publickey for deploy from 203.0.113.10 port 33998 ssh2: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg

Wo dieses Log liegt, steht in SSH-Anmeldungen prüfen.

Auf einem Server suchen

Führen Sie dies als root aus, weil jedes ~/.ssh nur seinem Besitzer gehört:

sudo bash -c '
FP="SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg"
for f in /root/.ssh/authorized_keys* /home/*/.ssh/authorized_keys*; do
  [ -f "$f" ] && ssh-keygen -lf "$f" | grep -F "$FP" && echo "  found in $f"
done'

Prüfen Sie auch Dienstkonten, deren Home-Verzeichnis woanders liegt, und ein abweichendes AuthorizedKeysFile:

sudo sshd -T | grep -i authorizedkeysfile
getent passwd | cut -d: -f1,6

Auf allen Servern suchen

Speichern Sie die obige Suche als Skript auf jedem Server, oder lassen Sie sie von Ihrem eigenen Rechner aus in einer Schleife laufen. Die Liste der Hosts liefern Sie selbst, und sudo darf hier nicht nach einem Passwort fragen:

while read -r host; do
  echo "== $host"
  ssh -n "$host" sudo /usr/local/bin/find-ssh-key
done < hosts.txt

Vergessen Sie keine Rechner, die keine Server im üblichen Sinn sind: Git-Hosting, Netzwerkgeräte, Jump-Hosts, CI-Runner und Backup-Ziele.

Warum -n in dieser Schleife nötig ist, erklärt Befehle über SSH ausführen.

Den Schlüssel entfernen

Suchen Sie nach dem Schlüssel selbst, nicht nach dem Kommentar, und legen Sie eine Sicherung an:

KEY=$(cut -d' ' -f2 alice.pub)
f=/home/deploy/.ssh/authorized_keys
sudo cp -p "$f" "$f.bak"
sudo grep -vF "$KEY" "$f.bak" | sudo tee "$f" > /dev/null

Löschen Sie die Sicherung, sobald Sie geprüft haben, dass die anderen sich weiterhin anmelden können. Derselbe Schlüssel kann in mehr als einer Zeile stehen, und dieser Befehl entfernt alle.

Mit RevokedKeys blockieren

Das Entfernen der Zeilen behebt, was Sie gefunden haben. RevokedKeys blockiert den Schlüssel zusätzlich in jedem Konto, in dem Sie ihn nicht gefunden haben oder in dem er wieder eingetragen wird. Die einfachste Form ist eine Datei mit öffentlichen Schlüsseln:

sudo cp alice.pub /etc/ssh/revoked_keys
sudo chmod 644 /etc/ssh/revoked_keys
# /etc/ssh/sshd_config.d/10-revoked.conf
RevokedKeys /etc/ssh/revoked_keys
sudo sshd -t && sudo systemctl reload ssh

Auf Red-Hat- und Fedora-Systemen heißt der Dienst sshd. Eine Anmeldung mit diesem Schlüssel schlägt jetzt fehl, und das Log sagt:

Authentication key ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg revoked by file /etc/ssh/revoked_keys

Legen Sie die Datei an, bevor Sie die Einstellung eintragen. Fehlt sie oder ist sie nicht lesbar, verweigert sshd allen Benutzern die Anmeldung per öffentlichem Schlüssel. In unserem Test stand im Log Error checking authentication key ... in revoked keys file. Eine leere Datei ist in Ordnung.

Eine KRL für viele Schlüssel

Eine Key Revocation List ist die kompakte Binärform derselben Datei, und die Einstellung ist dieselbe. Erstellen Sie eine und ergänzen Sie sie mit -u. Ohne -u ersetzt der Befehl den bisherigen Inhalt:

sudo ssh-keygen -k -f /etc/ssh/revoked_keys alice.pub
sudo ssh-keygen -k -u -f /etc/ssh/revoked_keys bob.pub

Prüfen Sie einen Schlüssel gegen die Liste:

ssh-keygen -Q -f /etc/ssh/revoked_keys alice.pub
alice.pub (alice@laptop): REVOKED

Ein Schlüssel, der nicht auf der Liste steht, zeigt ok. Der Exit-Code ist 1, wenn ein Schlüssel gesperrt ist, und 0, wenn nicht, was in Skripten praktisch ist. Den Inhalt einer KRL listen Sie mit ssh-keygen -Q -l -f /etc/ssh/revoked_keys auf.

Bereits offene Sitzungen beenden

Ein gesperrter Schlüssel verhindert nur neue Anmeldungen. In unserem Test lief eine Sitzung, die vor dem Entfernen des Schlüssels geöffnet wurde, weiter und endete normal. Suchen Sie offene Sitzungen mit who, und wenn es das eigene Konto der Person ist, beenden Sie sie:

sudo pkill -KILL -u alice

Das beendet alles, was dieses Konto ausführt, verwenden Sie es also nicht ungeprüft bei einem gemeinsam genutzten Konto.

Das Konto schließen

Manche gängigen Befehle tun weniger, als man erwartet. Wir haben jeden mit einem funktionierenden Schlüssel getestet:

BefehlKann sich der Schlüssel noch anmelden?
passwd -l aliceJa. Es sperrt nur das Passwort.
usermod -s /usr/sbin/nologin aliceEs gibt keine Shell, aber ssh -L-Tunnel funktionieren weiterhin.
chage -E 0 aliceNein. Das Log sagt Access denied for user alice by PAM account configuration.

Mit chage -E 0 sperren Sie das Konto sofort, und löschen es später mit userdel, sobald nichts mehr davon abhängt.

Alles andere, was die Person wusste

Hatte die Person Zugriff auf ein gemeinsames Konto oder auf root eines Servers, ist ein Schlüssel vielleicht nur ein Teil davon. Prüfen Sie:

  • Gemeinsame Konten: Ersetzen Sie deren Schlüssel und Passwörter.
  • Private Schlüssel, die sie lesen konnte, etwa Deploy-Keys: Ersetzen Sie diese und sperren Sie die alten.
  • Crontabs und sudoers-Dateien, die sie erwähnen.
  • Schlüssel, die unter anderen Konten hinzugefügt wurden. Vergleichen Sie den Inhalt jeder authorized_keys mit dem, was dort stehen sollte.

Für das nächste Mal einfacher: kurzlebige Zertifikate

Mit SSH-Zertifikaten gibt es auf den Servern keine Liste von Schlüsseln. Der Server vertraut einer Zertifizierungsstelle (CA), und jedes Zertifikat läuft von selbst ab. Dieser Befehl signiert einen Schlüssel für acht Stunden für das Konto deploy:

ssh-keygen -s user_ca -I alice@example.com -n deploy -V +8h -z 1001 alice.pub

Verlässt jemand das Team, signieren Sie nichts mehr für diese Person. Das letzte Zertifikat läuft von allein ab, und das Log sagt Certificate invalid: expired. Um ein Zertifikat früher zu sperren, sperren Sie es nach Identität oder Seriennummer. Schreiben Sie eine kleine Datei namens spec:

id: alice@example.com
serial: 1001
sudo ssh-keygen -k -u -f /etc/ssh/revoked_keys -s user_ca.pub spec

Die Einrichtung steht in SSH-Zertifikate erklärt.

Fragen

Entfernt das Löschen eines Linux-Benutzers seinen SSH-Zugang?

Wenn Sie das Konto mit userdel löschen, sind Anmeldungen daran nicht mehr möglich. Nur das Passwort mit passwd -l zu sperren reicht nicht: Ein Schlüssel meldet sich weiter an. Der Schlüssel kann auch in anderen Konten stehen, suchen Sie also per Fingerabdruck.

Enden offene SSH-Sitzungen, wenn ein Schlüssel entfernt wird?

Nein. Entfernen oder Widerrufen stoppt nur neue Anmeldungen. Beenden Sie offene Sitzungen, zum Beispiel mit pkill auf dem eigenen Konto der Person.

Was ist eine OpenSSH-KRL?

Eine Key Revocation List: eine kompakte Binärdatei mit widerrufenen Schlüsseln und Zertifikaten, erstellt mit ssh-keygen -k und in sshd_config über RevokedKeys eingebunden.

Quellen

Mehr zu Server absichern

Alle Anleitungen