{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie6yyqyy5vdv4evlnycsb5ubaihm3hzktniezm4ggagmf3ryj43py",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmlvsh3k24z2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicslsg26wqeoe7q54mu2egjbx5txk5u6e4ieaavt5dqqwjsruqvry"
    },
    "mimeType": "image/png",
    "size": 989803
  },
  "description": "SSH sollte Hostkeys via DNSSEC-gesicherten SSHFP-Records verifizieren. Fehler: systemd-resolved filterte das AD-Flag raus. Loesung: systemd-resolved weg, NetworkManager mit trust-ad Option. Jetzt funktioniert DNSSEC korrekt.",
  "path": "/2024/03/29/linux-mint-ubuntu-und-dnssec/",
  "publishedAt": "2026-05-24T11:55:29.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "DNSSEC",
    "InfoSec",
    "Linux",
    "Networking",
    "Security",
    "SSH",
    "SSHFP",
    "Sysadmin",
    "Ubuntu",
    "SSHFP-Records",
    "systemd-resolved",
    "SSH-Quellcode",
    "ldns",
    "dns.kernel-error.de",
    "Schreibt mir",
    "SSH Host Keys per SSHFP",
    "@8.8.8.8",
    "@server"
  ],
  "textContent": "Heute habe ich versucht, mich von meiner neuen Linux Mint Installation aus mit einem meiner SSH-Server zu verbinden. Mein SSH-Client hat mich direkt gefragt, ob ich dem Hostkey vertrauen möchte:\n\n\n    ssh username@hostname.kernel-error.org\n    The authenticity of host 'hostname.kernel-error.org (2a01:5a8:362:4416::32)' can't be established.\n    ED25519 key fingerprint is SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu.\n    This key is not known by any other names\n    Are you sure you want to continue connecting (yes/no/[fingerprint])?\n\nFür viele ist das normal — man tippt „yes“ und sieht die Meldung nie wieder. Aber diese Meldung hat ihren Grund. Beim ersten Verbindungsaufbau zeigt SSH den Fingerprint des Server-Hostkeys an, damit man prüfen kann, ob man wirklich mit dem richtigen Server spricht und nicht mit einem Angreifer. Wer eh immer „yes“ sagt, könnte den Check auch gleich in seiner **~/.ssh/config** abschalten:\n\n\n    Host *\n        StrictHostKeyChecking no\n\n### SSHFP — Hostkeys per DNS verifizieren\n\nEs gibt einen besseren Weg: SSHFP-Records (RFC 4255). Man hinterlegt die Fingerprints der erwarteten Hostkeys als DNS-Einträge. Der SSH-Client prüft diese automatisch — vorausgesetzt die DNS-Antwort ist per DNSSEC abgesichert. In der **~/.ssh/config** :\n\n\n    Host *\n       VerifyHostKeyDNS yes\n\nMeine DNS-Server unterstützen alle DNSSEC, mein lokaler Resolver auf dem Router auch, die SSH-Config stimmt — und trotzdem erscheint die Meldung. Also mit `ssh -vvv` debuggen:\n\n\n    debug1: found 2 insecure fingerprints in DNS\n\n _Insecure._ SSH findet die SSHFP-Records, vertraut ihnen aber nicht, weil die DNS-Antwort nicht als DNSSEC-validiert markiert ist.\n\n### Das Problem: systemd-resolved\n\nSchneller Test mit `dig +dnssec` gegen Google DNS:\n\n\n    dig +dnssec hostname.kernel-error.org @8.8.8.8\n    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1\n\nDas **ad** -Flag (Authenticated Data) ist gesetzt — meine DNS-Server liefern DNSSEC korrekt aus. Auch der lokale Router-Resolver liefert `ad`. Aber ohne expliziten `@server`:\n\n\n    dig +dnssec hostname.kernel-error.org\n    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1\n\nKein `ad`. Was steht in **/etc/resolv.conf**? `127.0.0.53` — systemd-resolved. Der Stub-Resolver von systemd schluckt das AD-Flag.\n\nMan könnte in **/etc/systemd/resolved.conf** einfach `DNSSEC=yes` setzen — bei mir ging danach aber gar keine DNS-Auflösung mehr. Das liegt am Stub-Resolver, den man ebenfalls umkonfigurieren müsste. Nennt mich oldschool, aber für meine Zwecke reicht der klassische Weg über die vom NetworkManager gepflegte resolv.conf.\n\n### Lösung: systemd-resolved abschalten\n\n\n    sudo systemctl disable systemd-resolved\n    sudo systemctl stop systemd-resolved\n    sudo rm /etc/resolv.conf\n\nIn **/etc/NetworkManager/NetworkManager.conf** in der **[main]** -Sektion:\n\n\n    dns=default\n\nNetworkManager neu starten:\n\n\n    sudo systemctl restart NetworkManager\n    cat /etc/resolv.conf\n    # Generated by NetworkManager\n    search kernel-error.local\n    nameserver 10.10.88.1\n    nameserver fd00:424e:6eff:f525:454e:6eff:f525:4241\n\nDNS-Auflösung geht. Aber SSH sagt weiterhin „insecure“. Es fehlen noch zwei Optionen in der resolv.conf.\n\n### edns0 und trust-ad\n\nErste Erkenntnis — `edns0` muss aktiviert sein, damit DNSSEC-Daten überhaupt transportiert werden. In **/etc/resolv.conf** :\n\n\n    options edns0\n\nJetzt zeigt `dig` das `ad`-Flag. Aber SSH sagt immer noch „insecure“. Warum? Ein Blick in den SSH-Quellcode — die ldns-Bibliothek macht die DNSSEC-Validierung:\n\n\n            /* Check for authenticated data */\n            if (ldns_pkt_ad(pkt)) {\n                    rrset->rri_flags |= RRSET_VALIDATED;\n            } else { /* AD is not set, try autonomous validation */\n                    ldns_rr_list * trusted_keys = ldns_rr_list_new();\n                    /* ... */\n                    if ((err = ldns_verify_trusted(ldns_res, rrdata, rrsigs,\n                         trusted_keys)) == LDNS_STATUS_OK) {\n                            rrset->rri_flags |= RRSET_VALIDATED;\n                    }\n            }\n\nldns prüft das AD-Flag im DNS-Paket. Aber die glibc setzt das AD-Flag in der Antwort nur dann, wenn `trust-ad` in der resolv.conf steht — sonst wird es aus Sicherheitsgründen herausgefiltert. Die vollständige Option:\n\n\n    options edns0 trust-ad\n\nUnd jetzt:\n\n\n    ssh username@hostname.kernel-error.org -vvv\n    [...]\n    debug1: found 2 secure fingerprints in DNS\n    debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1\n    debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1\n    debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2\n    debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2\n    debug1: matching host key fingerprint found in DNS\n\n**secure** statt insecure. SSH verifiziert den Hostkey automatisch per DNSSEC — keine manuelle Fingerprint-Prüfung mehr nötig.\n\n### Rebootfest machen\n\nDie manuell eingetragenen Optionen in der resolv.conf überleben keinen Reboot — der NetworkManager überschreibt die Datei. Per `nmcli` die Optionen dauerhaft im Netzwerkprofil setzen, für IPv4 und IPv6:\n\n\n    nmcli conn modify DEINE-PROFIL-UUID ipv4.dns-options edns0,trust-ad\n    nmcli conn modify DEINE-PROFIL-UUID ipv6.dns-options edns0,trust-ad\n\nDie UUID des aktiven Profils findet man mit `nmcli conn show`. Beide Zeilen sind nötig — fehlt eine, greift es nicht.\n\n* * *\n\n**Zusammenfassung:** systemd-resolved unter Linux Mint und Ubuntu filtert das DNSSEC-AD-Flag heraus. Ohne AD-Flag kann SSH die SSHFP-Records nicht als vertrauenswürdig einstufen. Lösung: systemd-resolved abschalten, NetworkManager mit `dns=default` nutzen, `edns0,trust-ad` per `nmcli` setzen.\n\nWer einen DNSSEC-validierenden Resolver sucht — dns.kernel-error.de ist ein öffentlicher DNS-Resolver mit DNSSEC, DNS over TLS und DNS over HTTPS.\n\nUnd die offene Frage: Ich bin mit meinem FreeBSD-Wissen an das Thema gegangen. Wie macht man das als Linux-User _mit_ systemd-resolved richtig? Schreibt mir, wenn ihr es wisst.\n\nSiehe auch: SSH Host Keys per SSHFP",
  "title": "DNSSEC und SSHFP unter Linux Mint und Ubuntu zum Laufen bringen"
}