Die SSH-Datei authorized_keys erklärt

Das Format

# Deploy key, added for the release job
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINH9eelf0P7eT5ue6SualUXFrh1c9p3Maaem93iZtC2Q you@laptop
from="203.0.113.10",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINxDNsPpUAbI52nc1OduztL+ backup-job

Eine Zeile von links nach rechts gelesen:

Optionen, optional. Durch Kommas getrennt, ohne Leerzeichen, außer innerhalb von doppelten Anführungszeichen.
Schlüsseltyp, etwa ssh-ed25519 oder ssh-rsa.
Der Schlüssel, ein langer Base64-String.
Ein Kommentar, optional. Er dient nur Ihnen.

Leerzeilen und Zeilen, die mit # beginnen, werden ignoriert. Eine unsinnige Zeile wird übersprungen, die Zeilen danach funktionieren weiter.

Diese Fehler kosten Sie unbemerkt den Schlüssel, und Sie sehen nur Permission denied:

Ein Schlüssel, der auf zwei Zeilen umbrochen wurde, meist durch Einfügen in einen Editor, der Text umbricht. Jeder Schlüssel muss in einer Zeile stehen.
Ein Schlüssel ohne Typ am Anfang.
Ein Leerzeichen nach einem Komma in den Optionen, wie in from="203.0.113.10", restrict.

Sie brauchen erst einen Schlüssel? Siehe einen Ed25519-SSH-Schlüssel erzeugen.

Nützliche Optionen

Option	Wirkung
`restrict`	Schaltet Port-, Agent- und X11-Weiterleitung, Terminals und `~/.ssh/rc` aus.
`command="..."`	Führt diesen Befehl aus, was auch immer der Client verlangt hat.
`from="..."`	Die Anmeldung muss von einer dieser Adressen oder Namen kommen. CIDR und Muster funktionieren.
`permitopen="host:port"`	Beschränkt `ssh -L` auf dieses Ziel.
`expiry-time="20991231"`	Der Schlüssel funktioniert nach diesem Datum nicht mehr.
`cert-authority`	Die Zeile ist eine Zertifizierungsstelle, kein Benutzerschlüssel. Siehe SSH-Zertifikate.
`verify-required`	Für FIDO-Schlüssel: Jede Signatur muss eine PIN oder eine ähnliche Prüfung enthalten.

Funktionierende Beispiele finden Sie unter Schlüssel auf einen Befehl beschränken.

Rechte

Die sicheren Einstellungen, als Benutzer auf dem Server ausgeführt:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Wenn Sie die Dateien als Root angelegt haben, korrigieren Sie auch den Besitzer:

sudo chown -R user:user /home/user/.ssh

Das geschah in unseren Tests, und das sagte das Server-Log:

Einstellung	Ergebnis
`authorized_keys` Modus 600 oder 644	Funktioniert
`authorized_keys` Modus 666	Abgelehnt: `Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys`
`~/.ssh` Modus 700 oder 755	Funktioniert
`~/.ssh` Modus 777	Abgelehnt: `Authentication refused: bad ownership or modes for directory /home/user/.ssh`
Datei gehört Root, Modus 644	Funktioniert, weil der Benutzer sie lesen kann
Datei gehört Root, Modus 600	Abgelehnt: `Could not open user 'user' authorized keys '/home/user/.ssh/authorized_keys': Permission denied`

Die Prüfung heißt StrictModes und ist standardmäßig an. Lassen Sie sie an. Ein Home-Verzeichnis mit Modus 775 bestand die Prüfung auf unserem Debian-System, wo die Gruppe nur diesen Benutzer enthält, aber das ist eine Debian-Änderung, andere Systeme können es ablehnen. Der Client sieht nur Permission denied, lesen Sie deshalb immer das Server-Log. Siehe SSH-Verbindung debuggen.

Welche Zeile gewinnt

Kommt ein Schlüssel mehrfach vor, liest sshd von oben nach unten und nimmt die erste Zeile, die die Anmeldung durchlässt. Nur die Optionen dieser Zeile gelten. Daraus folgen zwei Dinge, die man wissen sollte:

Eine einfache Zeile über einer eingeschränkten hebelt sie aus. Steht der Schlüssel zuerst ohne Optionen und danach mit command="...", bekommt die Anmeldung eine normale, uneingeschränkte Sitzung.
Eine Zeile, deren Bedingung nicht erfüllt ist, beendet die Suche nicht. Hat die erste Zeile ein from=, das nicht passt, oder ein expiry-time in der Vergangenheit, kann die nächste Zeile mit demselben Schlüssel die Anmeldung trotzdem durchlassen. Um einen Schlüssel zu sperren, löschen Sie alle seine Zeilen.

Den Speicherort der Datei ändern

Die Server-Einstellung AuthorizedKeysFile sagt, wo gesucht wird. Den aktuellen Wert sehen Sie mit:

sudo sshd -T | grep -i authorizedkeysfile

Der Standard ist .ssh/authorized_keys .ssh/authorized_keys2, ein Schlüssel in einer vergessenen authorized_keys2 funktioniert also auch. Suchen Sie danach, wenn Sie Zugang entziehen.

Eine häufige Änderung ist, die Dateien außerhalb der Home-Verzeichnisse zu halten, wo nur Root sie bearbeiten kann:

# /etc/ssh/sshd_config.d/10-keys.conf
AuthorizedKeysFile /etc/ssh/authorized_keys/%u

%u ist der Benutzername und %h das Home-Verzeichnis. Relative Pfade beginnen im Home-Verzeichnis. Jeder Benutzer muss seine eigene Datei lesen können, zum Beispiel mit Modus 644 und Root als Besitzer. Legen Sie diese Dateien an, bevor Sie sshd neu laden, und lassen Sie beim Testen eine Sitzung offen.

Um Schlüssel von anderswo zu holen, etwa aus einem Verzeichnisdienst, nutzen Sie AuthorizedKeysCommand. Siehe sshd_config(5).

Sehen, was in der Datei steht

ssh-keygen -lf ~/.ssh/authorized_keys

Das gibt für jeden Schlüssel einen Fingerabdruck aus. Bei einer Zeile mit Optionen erscheint der Optionstext dort, wo man den Kommentar erwartet, zum Beispiel 256 SHA256:NxFS... restrict,command="/usr/local/bin/ssh-allow" (ED25519). Der Fingerabdruck stimmt trotzdem.

Fragen

Wo liegt die Datei authorized_keys?

Standardmäßig in ~/.ssh/authorized_keys im Home-Verzeichnis des Kontos, mit dem Sie sich anmelden. Die Servereinstellung AuthorizedKeysFile kann auf einen anderen Ort zeigen; prüfen Sie sie mit sudo sshd -T | grep -i authorizedkeysfile.

Muss ich sshd nach einer Änderung an authorized_keys neu starten?

Nein. sshd liest die Datei bei jeder Anmeldung, die Änderung gilt also ab der nächsten Verbindung.

Warum fragt SSH nach dem Hinzufügen meines Schlüssels weiter nach dem Passwort?

Meist sind die Rechte zu offen, der Schlüssel ist auf zwei Zeilen umbrochen oder steht im falschen Konto. Das Serverlog nennt den Grund; der Client zeigt nur die Passwortabfrage oder Permission denied.

Quellen

Mehr zu Schlüssel und Anmeldung

Alle Anleitungen