~/.ssh/known_hosts (kurz known_hosts) speichert die Host-Schlüssel aller SSH-Server, mit denen sich der Client bereits verbunden hat. Beim ersten Kontakt merkt sich OpenSSH den Fingerabdruck; bei späteren Verbindungen vergleicht es ihn — weicht er ab, bricht die Verbindung mit HOST KEY VERIFICATION FAILED ab (Schutz vor Man-in-the-Middle-Angriffen).

Warum Host-Key-Prüfung?

Jeder SSH-Server besitzt einen eindeutigen Host-Schlüssel. Ohne Prüfung könnte ein Angreifer die Verbindung abfangen und sich als Server ausgeben. known_hosts macht den ersten Kontakt prüfbar: Der Client fragt bei unbekanntem Host nach (Fingerabdruck anzeigen und bestätigen).

Aufbau und Einträge

server.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

Pro Zeile stehen Hostname (oder IP), Schlüsseltyp und der öffentliche Schlüssel. Zusätzlich wird ein @cert-authority-Eintrag für von einer Zertifizierungsstelle signierte Schlüssel unterstützt. Die globale Variante /etc/ssh/ssh_known_hosts gilt für alle Benutzer.

Verwalten

• ssh-keyscan server.example.com >> ~/.ssh/known_hosts — Host-Schlüssel automatisch eintragen.
• ssh-keygen -R server.example.com — bekannten Eintrag entfernen (z.B. nach Neuinstallation des Servers).
• StrictHostKeyChecking no in der ssh-config deaktiviert die Prüfung — nur für Testumgebungen, in Produktion ein Sicherheitsrisiko.

Sicherheit

Beim ersten Verbinden den angezeigten Fingerabdruck über einen vertrauenswürdigen Kanal verifizieren. ssh-keyscan sammelt die Schlüssel zwar automatisch, doch der erste Abruf selbst ist nicht gegen Manipulation geschützt — die erhaltenen Schlüssel sollten vor dem Vertrauen geprüft werden.

Verwandte Grundlagen: SSH, ssh-keygen, ssh-keyscan, authorized_keys und sshd.

ssh-keyscan sammelt die öffentlichen Host-Schlüssel eines SSH-Servers, ohne sich anzumelden — die Grundlage, um known_hosts automatisch zu befüllen. Es gehört zum OpenSSH-Paket und wird häufig in Skripten und Automatisierungen genutzt.

Grundbefehl

ssh-keyscan server.example.com

Der Befehl verbindet sich zum SSH-Port (Standard 22) und gibt die gefundenen Schlüssel im known_hosts-Format aus. Mehrere Hosts sind möglich: ssh-keyscan host1 host2. Mit -p 2222 lässt sich ein abweichender Port angeben.

Typische Verwendung

ssh-keyscan server.example.com >> ~/.ssh/known_hosts

So lässt sich die Host-Key-Abfrage beim ersten Verbinden überspringen — praktisch für Skripte, CI-Pipelines und die Einrichtung vieler Rechner. Mit -H werden Einträge gehasht gespeichert (Standard bei neueren OpenSSH-Versionen).

Sicherheit

• TOFU-Problem: Beim allerersten Abruf kennt der Client den Server noch nicht — ein Angreifer könnte sich einschleichen. Die gesammelten Schlüssel daher über einen vertrauenswürdigen Kanal verifizieren, bevor man ihnen vertraut.
• Mit StrictHostKeyChecking lässt sich steuern, wie der Client mit unbekannten oder geänderten Schlüsseln umgeht — in Produktion immer yes (bzw. accept-new nur für neue Einträge).
• Alternativ zu known_hosts werden die authorized_keys des Servers gepflegt — dort stehen die Schlüssel der Benutzer, nicht die des Servers.

Verwandte Grundlagen: SSH, ssh-keygen, known_hosts und authorized_keys.

~/.ssh/authorized_keys (kurz authorized_keys) ist die Datei auf dem SSH-Server, die die öffentlichen SSH-Schlüssel der erlaubten Benutzer auflistet. Besitzt der Client den passenden privaten Schlüssel, erlaubt der Server die Anmeldung ohne Passwort — die Grundlage der Public-Key-Authentifizierung.

Aufbau

Jede Zeile enthält genau einen öffentlichen Schlüssel: Schlüsseltyp, Base64-kodierter Schlüssel und optional ein Kommentar (meist benutzer@rechner). Mehrere Benutzer oder Rechner stehen einfach in mehreren Zeilen.

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... benutzer@rechner

Berechtigungen

Die Datei und das Verzeichnis ~/.ssh müssen nur dem eigenen Benutzer gehören. OpenSSH lehnt zu lockere Rechte ab: ~/.ssh mit 700, authorized_keys mit 600. Der Client-Schlüssel (privat) gehört ebenfalls dem Benutzer (600).

Befüllen und verwalten

Am einfachsten hinterlegt ssh-copy-id den Schlüssel automatisch. Manuell wird angehängt: cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys. Änderungen sind sofort wirksam — ein Neustart des sshd ist nicht nötig. In /etc/ssh/sshd_config steuert AuthorizedKeysFile den Pfad.

Sicherheit

• Nur die öffentlichen Schlüssel eintragen — private Schlüssel gehören nie auf den Server.
• Zusätzliche Optionen am Zeilenanfang erlauben Einschränkungen, z.B. from="192.168.0.0/24" oder command="..." (Forced Command).
• Für Server mit vielen bekannten Hosts lohnt die Ablage aller Server-Schlüssel in known_hosts.

Verwandte Grundlagen: SSH, ssh-keygen, ssh-copy-id, known_hosts und ssh-keyscan.

Eine ssh-Bastion (Sprungserver, Jump Host) ist ein SSH-Server, über den Verbindungen zu weiteren Zielen im internen Netz laufen — ohne dass diese direkt von außen erreichbar sein müssen. Der Zugriff auf den Sprungserver selbst erfolgt per SSH-Key, das Ziel erreicht der SSH-Client automatisch durch den Sprung.

ProxyJump

Die moderne Variante ist ProxyJump. Sie ist seit OpenSSH 7.3 verfügbar und verkettet Verbindungen transparent:

ssh -J Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. benutzer@ziel-server

Der Client baut zuerst eine Verbindung zur Bastion auf und leitet darüber die zweite Verbindung zum Ziel. In der ssh-config lässt sich das dauerhaft eintragen:

Host ziel-server
    HostName ziel-server.intern
    User benutzer
    ProxyJump Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.

Danach genügt ssh ziel-server — die Bastion wird automatisch als Zwischenstation verwendet.

ProxyCommand als Alternative

Für ältere SSH-Versionen oder besondere Fälle dient ProxyCommand: ssh -W %h:%p Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. reicht stdin/stdout der ersten Verbindung an das Ziel durch. ProxyJump ist die einfachere, bevorzugte Schreibweise desselben Prinzips.

Sicherheit

Im Unterschied zum Bastion Host (dem gehärteten Server-Konzept) beschreibt die ssh-Bastion die konkrete SSH-Konfiguration: keine Schlüsselkopie auf den Sprungserver, kein Agent Forwarding nötig — die Verbindung wird durchgereicht statt weitergegeben. Der SSH-Tunnel bleibt die Option, wenn ein einzelner Port statt einer kompletten SSH-Sitzung weitergeleitet werden soll.

Verwandte Grundlagen: SSH, sshd und Teleport.