IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 38 von 46)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

GPG-Schlüssel per PKA im DNS veröffentlichen

Hinweis: PKA (Public Key Association) wird von GnuPG seit Version 2.1 (2014) nicht mehr unterstützt. Der Nachfolger ist der OPENPGPKEY Resource Record, der den kompletten Schlüssel direkt im DNS speichert. Dieser Beitrag beschreibt das ältere PKA-Verfahren — historisch interessant, aber für neue Setups nicht mehr empfehlenswert.


Die Idee hinter PKA

GnuPG konnte über DNS nach GPG-Schlüsseln fragen. Der Vorteil: Ich muss meinen öffentlichen Schlüssel nicht auf Keyservern verteilen, sondern veröffentliche ihn über meinen eigenen DNS-Server. Ist die Zone per DNSSEC geschützt, kann der Schlüssel nicht gefälscht werden — deutlich vertrauenswürdiger als Keyserver, auf denen jeder beliebige Schlüssel hochladen kann.

PKA funktioniert mit einem TXT-Record, der den Fingerprint des Schlüssels und eine URL zum Download enthält. GnuPG prüft den Fingerprint gegen den heruntergeladenen Schlüssel — stimmt beides überein, wird der Schlüssel importiert.

Schlüssel exportieren

Zuerst den öffentlichen Schlüssel exportieren und auf dem Webserver ablegen:

gpg --list-keys --fingerprint kernel-error@kernel-error.com
gpg --export --armor 0F9874D8 > kernel-error.asc

Die exportierte Datei muss per HTTP erreichbar sein — HTTPS ist nicht zwingend nötig, da der Schlüssel am Ende gegen den Fingerprint aus dem DNS geprüft wird.

PKA-Record erstellen

Der PKA-Record ist ein TXT-Record unter localpart._pka.domain. Er enthält den Fingerprint und die URL zum Schlüssel:

kernel-error._pka.kernel-error.com. IN TXT "v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

Aufbau: Das @ in der E-Mail-Adresse wird durch ._pka. ersetzt. Der Record enthält die PKA-Version (v=pka1), den vollständigen Fingerprint (fpr=...) und die Download-URL (uri=...). Für jede E-Mail-Adresse, unter der man erreichbar ist, braucht man einen eigenen Record — auch über verschiedene Zonen hinweg.

Prüfen

Mit dig testen, ob der Record im DNS angekommen ist:

dig +short kernel-error._pka.kernel-error.com TXT
"v=pka1;fpr=80CF90446B5867DA3A55854AF01C3E040F9874D8;uri=http://www.kernel-error.de/kernel-error.pubkey.txt"

GnuPG (bis Version 2.0) konnte den Schlüssel dann automatisch finden und importieren:

echo "test" | gpg --auto-key-locate pka --keyring /tmp/test.gpg \
  --encrypt --armor -r kernel-error@kernel-error.com

GnuPG fragt den PKA-Record ab, lädt den Schlüssel von der angegebenen URL herunter, prüft den Fingerprint und importiert den Schlüssel in den Keyring.

Warum OPENPGPKEY besser ist

PKA hatte zwei Schwächen: Der Schlüssel lag nicht im DNS selbst, sondern musste per HTTP heruntergeladen werden — ein zusätzlicher Angriffsvektor. Und der TXT-Record war auf 255 Bytes pro String begrenzt, was bei langen URLs und Fingerprints knapp wurde.

Der OPENPGPKEY Resource Record (RFC 7929) löst beides: Der komplette Schlüssel steckt direkt im DNS, kein HTTP-Download nötig. Mit DNSSEC ist die gesamte Kette vom DNS-Lookup bis zum Schlüssel kryptographisch abgesichert.

Siehe auch: OPENPGPKEY im DNS

Fragen? Einfach melden.

SSH Host Keys per SSHFP im DNS veröffentlichen

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.

Client konfigurieren

Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:

VerifyHostKeyDNS yes

Oder nur für die aktuelle Sitzung:

ssh -o "VerifyHostKeyDNS=yes" server.example.de

SSHFP-Records erzeugen

Am einfachsten direkt auf dem Server mit ssh-keygen — das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:

ssh-keygen -r server.example.de.

Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):

server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148
server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3...
server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62
server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1...
server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6...
server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...

Aufbau des SSHFP-Records

Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:

hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]

Algorithmus:

  • 1 — RSA
  • 3 — ECDSA
  • 4 — Ed25519 (empfohlen, ab OpenSSH 6.7)

DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.

Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden — ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.

Prüfen

Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:

dig +short server.example.de SSHFP
1 1 47890EECC9A2893061734B07B8F60CAA1A856148
1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3...
3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62
4 2 D4E5F6A7B8C9...

Wichtig: Bei der DNSSEC-validierten Abfrage muss das ad-Flag (Authenticated Data) gesetzt sein — sonst ist die Antwort nicht vertrauenswürdig:

dig +dnssec server.example.de SSHFP | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

Verbindungsaufbau mit SSHFP

Ohne SSHFP-Records im DNS meldet OpenSSH:

DNS lookup error: data does not exist
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Mit SSHFP-Records und DNSSEC:

debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

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.

Strenge Prüfung erzwingen

Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:

Host *
    VerifyHostKeyDNS yes
    StrictHostKeyChecking yes

Damit 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.

Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.

ZFS Scrub: Integritätsprüfung starten, stoppen und überwachen

Ein Scrub ist die Integritätsprüfung von ZFS — jeder Block im Pool wird gelesen und seine Checksumme verifiziert. Beschädigte Blöcke werden automatisch aus der Redundanz repariert (Mirror oder RAID-Z). Ohne Redundanz erkennt ZFS den Fehler immerhin, kann ihn aber nicht korrigieren.

Empfehlung: Einmal pro Woche oder mindestens einmal im Monat. Auf Produktivsystemen am besten per Cronjob.

Scrub starten

zpool scrub backup

Fortschritt prüfen

zpool status backup
  pool: backup
 state: ONLINE
  scan: scrub in progress since Sun May 27 11:11:00 2012
        4.20G scanned out of 74.5G at 102M/s, 0h11m to go
        0 repaired, 5.64% done

Scrub abbrechen

Braucht man die I/O-Leistung gerade für etwas anderes:

zpool scrub -s backup

Im Status sieht man dann den Unterschied — stopped statt completed:

# Abgebrochen
scan: scrub stopped after 0h7m with 0 errors on Sun May 27 11:18:52 2012

# Normal beendet
scan: scrub completed after 0h7m with 0 errors on Sun May 26 10:52:13 2012

Ein abgebrochener Scrub setzt beim nächsten Start nicht dort fort, sondern beginnt von vorne.

Scrub per Cronjob

# Jeden Sonntag um 02:00 alle Pools scrubben
0 2 * * 0 /sbin/zpool scrub backup

Unter FreeBSD läuft der Scrub standardmäßig über periodic daily — dort muss man nichts extra einrichten. Unter Linux gibt es je nach Distribution einen systemd-Timer (zfs-scrub-weekly.timer) oder man legt den Cronjob selbst an.

Mehr zu ZFS: ZFS RAID: Mirror und RAID-Z und ZFS Snapshots. Fragen? Einfach melden.

Dunning-Kruger-Effekt

OK, ist ein alter Hut…. http://de.wikipedia.org/wiki/Dunning-Kruger-Effekt denn noch haben die beiden absolut recht. Immer wenn es mir selbst passiert, muss ich sofort wieder daran denken. Dumm nur dass man oft erst nachher merkt wie unfähig ich mal wieder bin/war… Glücklicherweise kann man sich ja verbessern und somit immer etwas besser werden.

Ist es schon ein guter Anfang verstanden zu haben dass man eigentlich keine Ahnung hat?

Fragen? Einfach melden.

DNS konfigurieren um die XMPP Information zu verteilen

Warum vergessen nur immer alle die DNS Informationen zu ihrem neuen Jabber-Server zu setzten? Ich bin heute sicher zum 12 mal nach einem Problem gefragt worden welches damit zusammen hing. Die Info fehlt aber auch in _fast_ jedem Howto. Kopieren denn wirklich alle nur noch Zeile für Zeile? Als Wikipedia mal einen Tag ausgesetzt hat, konnten tausende keine Hausaufgaben abgeben. Irgendwie habe ich dass Gefühl, wenn Google mal einen Tag aussetzten würde könnten tausende „Admins“ nichts installieren oder Probleme lösen ;-P

Also um es noch mal in Google zu werfen:

Damit die Kommunikation zwischen den Jabber-Server sauber läuft müssen die nötigen DNS Records vorhanden sein. Für meinen Bind schaut es so aus wie im folgenden Beispiel:

_jabber._tcp.jabber.kernel-error.de.       IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-server._tcp.jabber.kernel-error.de.  IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-client._tcp.jabber.kernel-error.de.  IN SRV   0 0 5222   jabber.kernel-error.de.

Testen lässt sich dieses am Ende natürlich mit dig:

$ dig SRV _xmpp-server._tcp.jabber.kernel-error.de +short
0 0 5269 jabber.kernel-error.de.

$ dig SRV _xmpp-client._tcp.jabber.kernel-error.de +short
0 0 5222 jabber.kernel-error.de.

Fragen? Einfach melden.

Firefox Addon Instanfox

Veraltet: Das Firefox-Addon Instantfox ist nicht mehr verfügbar. Firefox hat inzwischen eigene Adressleisten-Suchkürzel (keyword bookmarks), die dasselbe leisten.

Boar ist das geil. Ich kann mich daran erinnern ähnliches früher im Konqueror genutzt zu haben. Na ja in sehr abgespeckter Version.

g: suchbegriff in der Konqueroradresszeile suchte für mich direkt in google.

OK ok… Google. Chrome Benutzer sind es eh schon gewöhnt alles in die Adresszeile zu tippen und dann das Googleergebnis als gottgegeben hinzunehmen.

Ich möchte jetzt nicht Google schlecht machen oder gar verteufeln, keine Sorge. Ich halte es nur für gefährlich sich ausschließlich auf eine Meinung zu verlassen! In der letzten Zeit scheint ja Google und Facebook _DAS_ Internet für viele zu sein. Ich schweife ab….

Dieses Firefox Addon (Instantfox) erweitert die Adresszeile so dass man direkt in verschiedenen Diensten suchen kann. Glücklicherweise kann man sogar selbst bestimmen wo man sucht. Alles natürlich mit der bekannten Autovervollständigung.

Als kleines Beispiel, gibt man in die Firefox Adresszeile ein:

g Wurstsuppe

Schon sucht er bei Google nach Wurstsuppe.

m Hattingen, NRW

Schon sucht er bei Google Maps nach Hattingen in NRW.

a 250GB SSD

Schon sucht er bei Amazon nach einer 250GB SSD.

Mehr und besser bebilderte Beispiele finden sich auf der Webseite vom Instantfox.

Leider gewöhnt man sich schnell daran und wundert sich dann über „wirre“ Fehlermeldungen an Systemen ohne ein solches Addon. Mir macht es die Arbeit leichter und schneller. Ich denke mir, einen Blick ist es wert!

 

 

Das beste Öl der Welt

Habe ich überhaupt schon mal vom besten Öl der Welt erzählt? Nein… böse böse.. Hier also nun mal etwas „Werbung“. Ballistol Ich benutze es seit Jahren und.. Bla bla.. Nein, jetzt im Ernst. Das Zeug ist wirklich geil. Schaut es euch einfach mal an! Manche sagen es riecht etwas komisch, ich finde den Geruch aber recht angenehm. Davon mal abgesehen verfliegt er recht schnell. Das Zeug flutscht einfach in jede kleinste Ritze. Ok, es schmeckt echt schlecht. Sonst kann ich wirklich nichts schlechtes an diesem Öl finden. Ballistol Öl Oel

Fragen? Einfach melden.

Club Mate macht Ärger

Es gibt Dinge, die dürfen einem Nerd nicht passieren. Die Festplatte darf nicht sterben, der Kaffee darf nicht alle sein und vor allem darf die Club Mate nicht ausgehen. Genau das ist mir passiert.

MATE IST ALLE

Wer kennt es nicht: Nachtschicht, Code oder Configs vor der Nase und das letzte was einen am Leben hält ist die Flasche Club Mate neben der Tastatur. Dann greifst du in den Kasten und da ist… nichts. Leere Flaschen. Alle. Panik.

Also direkt los zum Matedealer meines Vertrauens. Kaum komme ich mit dem neuen Kasten Club Mate die Treppe hoch, bekomme ich auch schon einen von meiner Frau drüber. Ich solle doch bitte die leeren Kästen erst mal wegbringen. Immer diese Details. Man sollte hier einen Club Mate Lieferservice einführen.

Stapel leerer Club Mate Kaesten, Beweisstück A

Das Bild zeigt übrigens nur einen Bruchteil der Beweislast. Es gab Zeiten, da hatte ich mehr leere Mate-Kästen als manche Leute Bücher im Regal. Irgendwann hat meine Frau angefangen sie zu zählen. Ich habe irgendwann aufgehört zuzuhören.

Club Mate ist halt die Hackerbrause. Auf jeder LAN-Party, auf jeder Konferenz, im Hackerspace, am Schreibtisch. Wer Kaffee trinkt, arbeitet. Wer Mate trinkt, hackt. Oder tut zumindest so. Inzwischen gibt es ja auch tausend andere Mate-Getränke, aber das Original bleibt das Original.

Falls jemand ähnliche Versorgungsprobleme hat oder einfach mal über die wichtigen Dinge im Leben reden will, kann man mich gerne fragen.

RSS-Feed Reader für Openindiana / Solaris 11

Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. Unter Linux gibt es zahlreiche RSS-Reader (Thunderbird, Liferea, Newsboat).

Ich habe gerade meinen lieblings RSS-Feed Reader Liferea auf der Solariskiste kompiliert. Ich finde es gibt einfach keinen besseren! Spannenderweise konnte ich auch keinen „fertigen“ finden. Na bis auf Thunderbird…. Aber Thunderbird? So gefällt es mir besser *hüpf*.

Liferea auf Solaris 11 Opensolaris
« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑