{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibhvf4seokaw4ohfm5zphnui4yg4i4wr2p67kvsx4lfujurhu7k44",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmoh33xolkn2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifxbzizpi675ilmntxmjkoh2askl4ompdudpizcpuvxrsnyjiqo34"
    },
    "mimeType": "image/png",
    "size": 612169
  },
  "description": "SSH-Host-Keys nicht mehr per Trust-on-First-Use pruefen, sondern aus dem DNS lesen: SSHFP-Records nach RFC 4255 erzeugen, in die Zone eintragen, VerifyHostKeyDNS aktivieren. Plus die DNSSEC-Pflichtkomponente und was zu beachten ist bei alten OpenSSH-Versionen.",
  "path": "/2012/05/27/hinzufuegen-der-ssh-public-keys-zum-dns/",
  "publishedAt": "2026-05-25T12:09:49.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "DNS",
    "DNSSEC",
    "Hardening",
    "InfoSec",
    "SelfHosted",
    "SSH",
    "SSHFP",
    "Sysadmin",
    "RFC 4255",
    "Einfach melden."
  ],
  "textContent": "OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt, ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.\n\n### Client konfigurieren\n\nDamit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss `VerifyHostKeyDNS` aktiviert werden. Global für alle Benutzer in `/etc/ssh/ssh_config`:\n\n\n    VerifyHostKeyDNS yes\n\nOder nur für die aktuelle Sitzung:\n\n\n    ssh -o \"VerifyHostKeyDNS=yes\" server.example.de\n\n### SSHFP-Records erzeugen\n\nAm einfachsten direkt auf dem Server mit `ssh-keygen`, das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:\n\n\n    ssh-keygen -r server.example.de.\n\nAusgabe (Beispiel mit RSA, ECDSA und Ed25519):\n\n\n    server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148\n    server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3...\n    server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62\n    server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1...\n    server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6...\n    server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...\n\n### Aufbau des SSHFP-Records\n\nEin SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:\n\n\n    hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]\n\n**Algorithmus:**\n\n  * **1** , RSA\n  * **3** , ECDSA\n  * **4** , Ed25519 (empfohlen, ab OpenSSH 6.7)\n\n\n\nDSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.\n\n**Hash-Typ:** 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden, ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.\n\n### Prüfen\n\nMit `dig` lässt sich prüfen, ob die Records im DNS angekommen sind:\n\n\n    dig +short server.example.de SSHFP\n    1 1 47890EECC9A2893061734B07B8F60CAA1A856148\n    1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3...\n    3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62\n    4 2 D4E5F6A7B8C9...\n\nWichtig: Bei der DNSSEC-validierten Abfrage muss das `ad`-Flag (Authenticated Data) gesetzt sein, sonst ist die Antwort nicht vertrauenswürdig:\n\n\n    dig +dnssec server.example.de SSHFP | grep flags\n    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1\n\n### Verbindungsaufbau mit SSHFP\n\nOhne SSHFP-Records im DNS meldet OpenSSH:\n\n\n    DNS lookup error: data does not exist\n    No matching host key fingerprint found in DNS.\n    Are you sure you want to continue connecting (yes/no)?\n\nMit SSHFP-Records und DNSSEC:\n\n\n    debug1: found 4 secure fingerprints in DNS\n    debug1: matching host key fingerprint found in DNS\n\n**secure** bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort **insecure** , der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.\n\n### Strenge Prüfung erzwingen\n\nOptional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:\n\n\n    Host *\n        VerifyHostKeyDNS yes\n        StrictHostKeyChecking yes\n\nDamit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung, setzt aber voraus, dass alle Zielserver SSHFP-Records haben.\n\nKleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.",
  "title": "SSH Host Keys per SSHFP im DNS veröffentlichen"
}