SSH StrictModes, Agent Forwarding (ssh -A) und ssh -a erklärt

Kurz gesagt: `StrictModes yes` (der OpenSSH-Standard) lässt sshd Eigentümer und Rechte Ihres Home-Verzeichnisses, von `~/.ssh` und `~/.ssh/authorized_keys` prüfen, bevor ein Schlüssel akzeptiert wird, und verweigert den Login mit „Authentication refused: bad ownership or modes“, wenn eines davon für Gruppe oder andere beschreibbar ist oder einem anderen Benutzer gehört. Korrigieren Sie die Rechte, statt die Prüfung abzuschalten. Agent Forwarding mit `ssh -A` erlaubt dem entfernten Host, Ihre lokalen Schlüssel zu nutzen, solange Sie verbunden sind — meiden Sie es also auf Hosts, denen Sie nicht voll vertrauen, und nutzen Sie stattdessen `ssh -J` (ProxyJump); das kleine `ssh -a` deaktiviert Agent Forwarding ausdrücklich.

Diese Anleitung ergänzt die Anleitung zur SSH-Härtung und gilt für Debian 12/13, Ubuntu 24.04 und Systeme der RHEL-Familie wie AlmaLinux 9 und Rocky 9.

Was SSH StrictModes prüft

StrictModes ist eine serverseitige Einstellung in `/etc/ssh/sshd_config`. Der Zweck ist einfach: Könnte ein anderer Benutzer in Ihre `authorized_keys` schreiben, könnte er seinen eigenen Schlüssel hinzufügen und sich als Sie einloggen. Deshalb vertraut sshd der Datei nur, wenn der gesamte Pfad geschützt ist. Geprüft werden die Datei und die darüberliegenden Verzeichnisse, einschließlich des Home-Verzeichnisses.

Den tatsächlich wirksamen Wert prüfen Sie mit `sshd -T | grep -i strictmodes`. Unter Ubuntu 24.04 und Debian 13 sehen Sie auch in die Drop-in-Dateien in `/etc/ssh/sshd_config.d/`.

„Authentication refused: bad ownership or modes“ beheben

Der Client zeigt nur ein allgemeines `Permission denied (publickey)`. Der wahre Grund steht im Server-Log, das den genauen Pfad nennt, zum Beispiel `Authentication refused: bad ownership or modes for directory /home/alice` oder `... for file /home/alice/.ssh/authorized_keys`. Beheben Sie es über die VPS-Konsole oder eine andere Sitzung.

1. 01.Lesen Sie das Log: `journalctl -u ssh -n 50` unter Debian und Ubuntu bzw. `journalctl -u sshd -n 50` unter AlmaLinux und Rocky.
2. 02.Korrigieren Sie den Eigentümer des SSH-Verzeichnisses: `chown -R alice:alice /home/alice/.ssh`.
3. 03.Korrigieren Sie die Rechte: `chmod 700 /home/alice/.ssh` und `chmod 600 /home/alice/.ssh/authorized_keys`.
4. 04.Entziehen Sie Gruppe und allen das Schreibrecht auf das Home-Verzeichnis: `chmod go-w /home/alice`.
5. 05.Auf SELinux-Systemen (AlmaLinux, Rocky, Fedora) stellen Sie die Labels wieder her: `restorecon -Rv /home/alice/.ssh`.
6. 06.Testen Sie aus einem neuen Terminal mit `ssh -v alice@server` und lassen Sie die funktionierende Sitzung offen.

# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys   # shows owner and mode of every path component

Note · Setzen Sie nicht `StrictModes no`, nur damit der Fehler verschwindet. Das entfernt einen echten Schutz und verdeckt die Fehlkonfiguration, statt sie zu beheben.

StrictModes vs. StrictHostKeyChecking

Bei Suchen nach „ssh strictmode“ werden oft zwei voneinander unabhängige Optionen verwechselt. `StrictModes` steht in `sshd_config` auf dem Server und prüft Dateirechte. `StrictHostKeyChecking` steht in `ssh_config` oder `~/.ssh/config` auf dem Client und steuert, was passiert, wenn der Host-Key eines Servers unbekannt ist oder sich geändert hat. Auch der Client hat eine eigene Rechteprüfung: Er verweigert die Nutzung eines privaten Schlüssels, den andere Benutzer lesen können, mit einer Warnung über eine ungeschützte private Schlüsseldatei; `chmod 600 ~/.ssh/id_ed25519` behebt das.

Agent Forwarding mit ssh -A: das Risiko

`ssh -A` (oder `ForwardAgent yes`) erzeugt auf dem entfernten Host einen Socket, referenziert über `$SSH_AUTH_SOCK`, der Signaturanfragen an den ssh-agent auf Ihrem Rechner zurückreicht. Ihr privater Schlüssel verlässt Ihren Rechner nie, aber jeder, der auf diesen Socket zugreifen kann, kann Ihren Schlüssel nutzen, solange Sie verbunden sind. Auf dem entfernten Host gehören dazu root und jeder Prozess, der unter Ihrem Benutzer läuft.

Ist der Server kompromittiert oder wird er von jemand anderem administriert, kann sich ein Angreifer unbemerkt bei jedem anderen Host anmelden, den Ihr Schlüssel öffnet — einschließlich Git-Hosting und Produktivservern. Deshalb ist im OpenSSH-Client standardmäßig `ForwardAgent no` gesetzt.

• ▹Leiten Sie Ihren Agent nie an geteilte, fremde oder frisch neu installierte Hosts weiter, die Sie nicht gehärtet haben.
• ▹Wenn Sie weiterleiten müssen, nutzen Sie `ssh-add -c`, damit jede Nutzung des Schlüssels lokal bestätigt werden muss.
• ▹OpenSSH ab 8.9 unterstützt Zielbeschränkungen mit `ssh-add -h`, die festlegen, für welche Hosts ein weitergeleiteter Schlüssel genutzt werden darf.
• ▹Serverseitig deaktiviert `AllowAgentForwarding no` in `sshd_config` die Funktion, wobei Benutzer mit Shell-Zugang trotzdem eigene Weiterleitungen einrichten können.

ProxyJump (ssh -J) für Bastion-Hosts bevorzugen

Agent Forwarding wird meist genutzt, um über einen Bastion-Host auf eine interne Maschine zu springen. `ssh -J` erledigt das, ohne Ihren Agent offenzulegen: Der Bastion-Host leitet nur einen verschlüsselten TCP-Stream weiter, und die Authentifizierung am internen Host erfolgt Ende-zu-Ende von Ihrem Laptop aus. Für Server, die nur über ein privates Netzwerk erreichbar sind, ist ein WireGuard-Tunnel eine weitere Option; siehe die Anleitung zu WireGuard-VPN oder die Anleitung zum WireGuard-Mesh, und zu Keepalive- und PSK-Einstellungen diese Anleitung zum WireGuard-Tuning.

Auf einem NoctisNode-VPS haben Sie vollen Root-Zugriff per SSH auf einer KVM-Maschine, sodass ein kleiner Wisp-Plan als dedizierter Jump-Host dienen kann, auf dem sonst nichts läuft; siehe VPS-Pläne.

# one-off
ssh -J [email protected] [email protected]

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
    ForwardAgent no

Host db1
    HostName 10.88.0.3
    User alice
    ProxyJump bastion

Was ssh -a (klein) bewirkt

Das kleine `ssh -a` deaktiviert Agent Forwarding für diese Verbindung — das Gegenteil von `-A`. Das ist nützlich, wenn Ihre `~/.ssh/config` `ForwardAgent` für einen Wildcard-Host aktiviert und Sie sicherstellen wollen, dass eine bestimmte Verbindung nicht weiterleitet, zum Beispiel `ssh -a admin@untrusted-host`. Verwechseln Sie es nicht mit `ssh-agent -a`, das den Pfad des Agent-Sockets festlegt, oder mit `ssh-add`, das Schlüssel in den Agent lädt.

FAQ