SSH-Schlüsselauthentifizierung einrichten: Ed25519, ssh-agent und sichere Server

EdwardMoon

SSH-Schlüsselauthentifizierung bedeutet mehr, als ein Passwort einzusparen. Sie verbindet die Prüfung der Serveridentität, den Schutz des privaten Schlüssels, die Verteilung des öffentlichen Schlüssels, einen Anmeldetest in einer neuen Sitzung und die Verschärfung der Anmelderichtlinien. Der private Schlüssel bleibt auf dem Client und wird durch eine Passphrase und ssh-agent geschützt.

Dieser Leitfaden richtet die SSH-Schlüsselauthentifizierung mit Ed25519 ein und behandelt auch RSA als Alternative im FIPS-Modus, die Prüfung von known_hosts, authorized_keys-Berechtigungen, sshd-Konfiguration, Schlüsselwiderruf und Wiederherstellung des Zugangs.

Zwei unterschiedliche Prüfungen auseinanderhalten

Eine funktionierende Benutzerauthentifizierung mit öffentlichen Schlüsseln allein genügt nicht. Bestätigen Sie den Fingerabdruck des Server-Hostschlüssels über eine vertrauenswürdige Konsole, die Inventarverwaltung oder einen unabhängigen Kanal. So lassen sich Angriffe erkennen, bei denen der Zielserver ausgetauscht wird.

Auf dem Client einen Schlüssel mit Passphrase erzeugen

Für gewöhnliche Umgebungen ist Ed25519 eine kompakte und sichere Standardwahl. Im FIPS-Modus ist Ed25519 jedoch möglicherweise nicht zulässig. Verwenden Sie unter einer solchen Richtlinie einen ausreichend langen RSA-Schlüssel. Wählen Sie pro Einsatzzweck einen eigenen Dateinamen, damit vorhandene Schlüssel nicht überschrieben werden.

install -d -m 0700 ~/.ssh
ssh-keygen -t ed25519 -a 100   -f ~/.ssh/id_ed25519_ops   -C 'ops-admin@client'
chmod 0600 ~/.ssh/id_ed25519_ops
chmod 0644 ~/.ssh/id_ed25519_ops.pub

RSA als Alternative bei FIPS-Vorgaben

ssh-keygen -t rsa -b 3072 -o -a 100   -f ~/.ssh/id_rsa_ops   -C 'ops-admin@client'

Entsperrte Schlüssel mit ssh-agent verwalten

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_ops
ssh-add -l

Den Fingerabdruck des Server-Hostschlüssels unabhängig bestätigen

Geben Sie an der Serverkonsole den Fingerabdruck des öffentlichen Hostschlüssels aus und vergleichen Sie ihn mit dem Wert, den der Client beim ersten Verbindungsaufbau anzeigt. ssh-keyscan sammelt Schlüssel, bestätigt aber nicht, dass sie zum richtigen Server gehören. Vertrauen Sie seinem Ergebnis daher nicht ohne zusätzliche Prüfung.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

ssh-keyscan -t ed25519 server.example.com > /tmp/server.hostkey
ssh-keygen -lf /tmp/server.hostkey
install -m 0600 /tmp/server.hostkey ~/.ssh/known_hosts.ops
rm -f /tmp/server.hostkey

Den öffentlichen Schlüssel in authorized_keys hinterlegen

Melden Sie sich zur Ersteinrichtung einmal mit dem bislang erlaubten Passwort oder über die Konsole an und ergänzen Sie den öffentlichen Schlüssel. Falls verfügbar, vereinfacht ssh-copy-id die Behandlung von Duplikaten und Berechtigungen.

ssh-copy-id -i ~/.ssh/id_ed25519_ops.pub ops@server.example.com

Manuelle Verteilung ohne ssh-copy-id

cat ~/.ssh/id_ed25519_ops.pub   | ssh ops@server.example.com     'umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys'

# Ab hier in einer Sitzung des Benutzers ops auf dem Server ausführen.
chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys
restorecon -RFv ~/.ssh

Auf RHEL-basierten Systemen mit aktivem SELinux müssen neben den Dateiberechtigungen auch die Sicherheitskontexte stimmen. Prüfen Sie außerdem, dass andere Benutzer das Home-Verzeichnis nicht beschreiben können.

Client-Alias und ausdrückliche Schlüsselauswahl

Host prod-app-01
    HostName server.example.com
    User ops
    IdentityFile ~/.ssh/id_ed25519_ops
    IdentitiesOnly yes
    UserKnownHostsFile ~/.ssh/known_hosts.ops

chmod 0600 ~/.ssh/config
ssh -v prod-app-01

Vor dem Abschalten der Passwortanmeldung testen

ssh -o PreferredAuthentications=publickey   -o PasswordAuthentication=no   prod-app-01
sudo -v
whoami

sshd-Syntax und tatsächlich wirksame Einstellungen prüfen

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

Trennen Sie die Richtlinien nach erfolgreichem Schlüsselauthentifizierungstest in einer Drop-in-Datei ab. Die tatsächlich wirksamen Werte können von der Include-Reihenfolge der Distribution und von Match-Blöcken abhängen. Prüfen Sie deshalb die Ausgabe von sshd -T und nicht nur den Inhalt einer Konfigurationsdatei.

sudo install -d -m 0755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/20-key-auth.conf >/dev/null <<'CONF'
PubkeyAuthentication yes
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
CONF

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

ssh -o PreferredAuthentications=publickey prod-app-01
sudo journalctl -u sshd --since '-10 minutes' --no-pager

Schlüssel auf ihren Einsatzzweck beschränken und widerrufen

Verwenden Sie für Automatisierung eigene Schlüssel, getrennt von allgemeinen Administrationsschlüsseln persönlicher Konten. Beschränken Sie bei Bedarf Herkunft oder Funktionen mit authorized_keys-Optionen. Solche Einschränkungen können benötigtes Tunneling oder PTY-Verhalten unterbinden und müssen deshalb zuerst in einer Testumgebung geprüft werden.

from="198.51.100.0/24",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... deploy-key

Entfernen Sie bei einem Schlüsselverlust oder beim Ausscheiden eines Benutzers die betreffende öffentliche Schlüsselzeile. Für einen zentralen Widerruf lässt sich eine OpenSSH-KRL erstellen und über RevokedKeys in sshd einbinden. Aktualisieren Sie eine vorhandene KRL mit -u, damit bisherige Widerrufe erhalten bleiben. Erstellen Sie die neue Fassung in einer temporären Datei auf demselben Dateisystem und ersetzen Sie die Zieldatei atomar. Kann sshd die KRL nicht lesen, kann jede Authentifizierung mit öffentlichen Schlüsseln abgewiesen werden. Halten Sie deshalb die bestehende Administrationssitzung und eine Wiederherstellungskonsole bereit. Geben Sie bei Servern mit Match-Blöcken auch die tatsächlichen Verbindungsbedingungen an, beispielsweise mit sshd -T -C user=ops,host=client.example.com,addr=198.51.100.10.

KRL_STAGE_DIR=$(sudo mktemp -d /etc/ssh/krl-stage.XXXXXX)
if sudo test -f /etc/ssh/revoked.krl; then
  sudo cp -p /etc/ssh/revoked.krl "$KRL_STAGE_DIR/revoked.krl"
  sudo ssh-keygen -k -u -f "$KRL_STAGE_DIR/revoked.krl" compromised_key.pub
else
  sudo ssh-keygen -k -f "$KRL_STAGE_DIR/revoked.krl" compromised_key.pub
fi
sudo chown root:root "$KRL_STAGE_DIR/revoked.krl"
sudo chmod 0644 "$KRL_STAGE_DIR/revoked.krl"
sudo mv "$KRL_STAGE_DIR/revoked.krl" /etc/ssh/revoked.krl
sudo rmdir "$KRL_STAGE_DIR"
sudo restorecon /etc/ssh/revoked.krl
sudoedit /etc/ssh/sshd_config.d/20-key-auth.conf
# Die folgende Zeile im globalen Abschnitt der oben genannten Datei ergänzen.
# RevokedKeys /etc/ssh/revoked.krl
sudo sshd -t
sudo sshd -T | grep "^revokedkeys "
sudo systemctl reload sshd

Fehlerbehebung

ssh -vvv prod-app-01
ssh-add -l
ssh-keygen -lf ~/.ssh/id_ed25519_ops.pub
sudo journalctl -u sshd -b --no-pager
sudo namei -l /home/ops/.ssh/authorized_keys
sudo ls -ldZ /home/ops /home/ops/.ssh /home/ops/.ssh/authorized_keys
sudo sshd -T

• Wird der Schlüssel nach Offering public key abgewiesen, Benutzer, öffentliche Schlüsselzeile, Berechtigungen und SELinux-Kontext prüfen.
• Bei Too many authentication failures IdentitiesOnly und IdentityFile ausdrücklich setzen.
• Bei REMOTE HOST IDENTIFICATION HAS CHANGED den gespeicherten Schlüssel nicht ungeprüft löschen, sondern eine mögliche Server-Neuinstallation oder DNS-Änderung bestätigen.
• Ist nach einer Konfigurationsänderung keine Anmeldung mehr möglich, die Drop-in-Datei über die bestehende Sitzung oder Konsole zurücksetzen und sshd -t ausführen.

Offizielle Dokumentation und Betriebsanleitungen

• Red Hat: sichere Kommunikation mit OpenSSH einrichten
• OpenSSH-Handbuch zu sshd_config
• OpenSSH-Handbuch zu ssh-keygen
• Ansible-Playbooks und sichere SSH-Automatisierung
• Administrationskonten und Hostschlüsselprüfung für Kubespray

Bei SSH-Schlüsselauthentifizierung ist die Verwaltung über den gesamten Lebenszyklus wichtiger als die Schlüsselerzeugung allein. Private Schlüssel müssen auf dem Client bleiben, Serverfingerabdrücke geprüft und neue Sitzungen getestet werden, bevor strengere Richtlinien greifen. Erst mit einem Verfahren zum sofortigen Widerruf kompromittierter Schlüssel wird die passwortlose Anmeldung zu einer tatsächlichen Sicherheitsverbesserung.