authorized_keys ist die OpenSSH-Datei, die die öffentlichen Schlüssel auflistet, mit denen man sich an einem Konto anmelden darf. Damit sshd sie akzeptiert, muss ~/.ssh die Rechte 700 und authorized_keys die Rechte 600 haben, ohne Schreibzugriff für Gruppe oder andere. Jede Zeile kann Optionen wie from=, command= und no-pty enthalten, die festlegen, von wo aus sich ein Schlüssel verbinden und was er ausführen darf.
Rechte von authorized_keys: 700 für ~/.ssh und 600 für die Datei
sshd ignoriert authorized_keys, wenn ~/.ssh oder die Datei selbst offener sind als erwartet: 700 für ~/.ssh und 600 für authorized_keys und private Schlüssel. Die Prüfung stammt von der Direktive StrictModes in sshd_config, die standardmäßig aktiviert ist und außerdem kontrolliert, dass Ihr Home-Verzeichnis nicht für Gruppe oder andere schreibbar ist.
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$(id -un)":"$(id -gn)" ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keysWenn etwas nicht stimmt, sagt das Server-Log es deutlich: Suchen Sie nach Zeilen wie Authentication refused: bad ownership or modes. Unter Debian und Ubuntu lesen Sie sie mit journalctl -u ssh; bei anderen Distributionen heißt die Unit sshd. StrictModes abzuschalten, um weiterzukommen, ist ein schlechter Tausch: Es verdeckt das Problem und erlaubt einem anderen Benutzer mit Schreibzugriff auf Ihr Home-Verzeichnis, seinen eigenen Schlüssel einzuschleusen.
Optionen in authorized_keys: from=, command= und no-pty an Beispielen
Jede Zeile in authorized_keys folgt dem Format [options] keytype key comment, wobei die Optionen durch Kommas ohne Leerzeichen getrennt und vor den Schlüsseltyp gesetzt werden. Die vollständige Liste steht im Abschnitt AUTHORIZED_KEYS der offiziellen Manpage von sshd.
from="203.0.113.0/24,198.51.100.7",no-pty,no-port-forwarding ssh-ed25519 AAAAC3Nza... admin@phone
command="/usr/local/bin/backup.sh",restrict ssh-ed25519 AAAAC3Nza... backup@nas
restrict,pty ssh-ed25519 AAAAC3Nza... support@laptop- from="patterns": Der Schlüssel wird nur akzeptiert, wenn sich der Client von diesen Adressen oder Hostnamen aus verbindet. Wildcards, CIDR-Notation und Negation mit
!sind erlaubt. - command="…": erzwingt diesen Befehl, unabhängig davon, was der Client anfordert. Der angeforderte Befehl bleibt in
SSH_ORIGINAL_COMMANDerhalten, damit ein Skript ihn prüfen kann. - no-pty: Es wird kein Terminal zugewiesen. Nützlich für rsync-, Backup- oder Deploy-Schlüssel.
- no-port-forwarding, no-agent-forwarding, no-X11-forwarding: schalten jede Art von Weiterleitung einzeln ab.
- restrict: deaktiviert alles oben Genannte auf einmal; anschließend aktivieren Sie wieder, was Sie brauchen, zum Beispiel mit
pty.
command= mit restrict zu kombinieren ist das Standardmuster für Backup-Schlüssel: Selbst wenn der Schlüssel durchsickert, kann er nur dieses eine Skript ausführen. from= fügt eine zweite Barriere hinzu, doch ein Smartphone im Mobilfunknetz hat selten eine feste Quell-IP. In diesem Fall lohnt es sich, über ein privates Mesh-Netzwerk wie Prialo oder Tailscale hereinzukommen und from= auf die Adressen dieses Netzwerks festzulegen.
5 häufige Fehler in authorized_keys und wie Sie sie erkennen
Der erste Diagnoseschritt ist immer ssh -v user@server: Er zeigt, welche Schlüssel der Client anbietet und wo der Server sie ablehnt.
- Falsche Rechte oder falscher Eigentümer. Wird die Datei als root kopiert, gehört sie root, und sshd überspringt sie. Der chmod- und chown-Block oben behebt das.
- Schlüssel auf mehrere Zeilen verteilt. Einfügen aus einem Editor mit Zeilenumbruch zerstört den Schlüssel. Jeder Schlüssel muss auf genau einer Zeile stehen.
- Optionen mit Leerzeichen oder nicht geschlossenen Anführungszeichen. Ein Leerzeichen nach einem Komma oder ein fehlendes schließendes Anführungszeichen macht die ganze Zeile ungültig, und sshd verwirft sie, ohne den Client zu informieren.
- RSA-Schlüssel wegen des Algorithmus abgelehnt. Seit OpenSSH 8.8 ist die
ssh-rsa-Signatur mit SHA-1 standardmäßig deaktiviert, sodass ältere Clients nicht mehr hineinkommen. Die Lösung ist der Umstieg auf Ed25519, das seit OpenSSH 6.5 unterstützt wird. - command= macht Mosh, SFTP oder scp kaputt. Mosh startet
mosh-serverüber eine erste SSH-Verbindung, und SFTP fordert sein Subsystem an; ein festes command= ersetzt beides. Seit OpenSSH 9.0 nutzt scp standardmäßig SFTP und schlägt daher ebenfalls fehl. Verwenden Sie getrennte Schlüssel für interaktive Sitzungen und für Automatisierung.
authorized_keys auf iOS und Android im Vergleich zum Desktop verwalten
Der private Schlüssel kann direkt auf dem Smartphone erzeugt und im sicheren Speicher des Systems abgelegt werden, sodass der Server nur die öffentliche Zeile benötigt, die an authorized_keys angehängt wird.
| Aufgabe | iOS/Android mit termi1 | Desktop mit OpenSSH |
|---|---|---|
| Schlüssel erzeugen | Auf dem Smartphone; im sicheren Speicher abgelegt | ssh-keygen -t ed25519 |
| Öffentlichen Schlüssel installieren | In authorized_keys einfügen oder einen Mac über Companion koppeln | ssh-copy-id user@server |
| Datei prüfen | Integriertes SFTP, ohne die Sitzung zu verlassen | Lokaler Editor oder sftp-Client |
| Mit vim oder nano bearbeiten | Eigene Tastatur mit Esc, Ctrl, Tab und Pfeiltasten | Physische Tastatur |
| Netzabbruch mitten in der Arbeit | Mosh und tmux halten die Sitzung am Leben | Die SSH-Sitzung bricht ab |
Im SSH- und Mosh-Terminal termi1 verlässt der private Schlüssel nie das Gerät und gelangt nie auf die Server von Sinergia, und termi1 Companion (macOS 14 oder neuer) installiert den öffentlichen Schlüssel mit einem sechsstelligen Code auf einem Mac. Bitten Sie die KI, „repariere meine SSH-Rechte“, und sie tippt chmod 600 ~/.ssh/authorized_keys in die Eingabezeile, ohne Enter zu drücken; bei als Produktion markierten Verbindungen hält Production Guard alles zurück, was den Zustand verändert. Das Terminal ist kostenlos, funktioniert ohne Konto und ist im App Store und bei Google Play erhältlich.
Häufig gestellte Fragen
Welche Rechte sollte authorized_keys haben?
authorized_keys sollte die Rechte 600 haben, also nur für den Eigentümer lesbar und schreibbar sein, und das Verzeichnis ~/.ssh die Rechte 700. Mit aktiviertem StrictModes, dem Standard, ignoriert sshd die Datei, wenn Gruppe oder andere in sie, in ~/.ssh oder ins Home-Verzeichnis schreiben können.
Was bewirkt command= in authorized_keys?
command= in authorized_keys erzwingt bei jeder Authentifizierung mit diesem Schlüssel einen bestimmten Befehl, unabhängig davon, was der Client anfordert. Der angeforderte Befehl wird in der Variable SSH_ORIGINAL_COMMAND gespeichert. Typischerweise wird es für Backup- und Deploy-Schlüssel eingesetzt, kombiniert mit restrict oder no-pty.
Warum fragt SSH nach dem Hinzufügen meines Schlüssels trotzdem nach einem Passwort?
SSH fällt auf ein Passwort zurück, wenn sshd keinen Schlüssel aus authorized_keys akzeptiert. Die üblichen Ursachen sind zu offene Rechte, der falsche Eigentümer, ein über mehrere Zeilen verteilter Schlüssel oder eine falsch geschriebene Option. ssh -v auf dem Client und das sshd-Log auf dem Server zeigen, welche es ist.
Funktioniert Mosh mit einem eingeschränkten Schlüssel in authorized_keys?
Mosh funktioniert mit eingeschränkten Schlüsseln, solange sie kein command= enthalten, weil es mosh-server über eine erste SSH-Verbindung startet. Danach läuft die Sitzung über UDP, standardmäßig auf den Ports 60000-61000, die in der Firewall des Servers offen sein müssen.