PGPKeyserver: Unterschied zwischen den Versionen

Aktuelle Version vom 10. März 2014, 12:54 Uhr

Was?[Bearbeiten]

Ein PGP-Keyserver ist quasi ein elektronisches Telefonbuch. Statt Telefonnummern speichert er allerdings PGP-Schlüssel inklusive Beglaubigungen von Dritten.

Wir haben einen innerhalb des Noklabs erreichbaren PGP-Keyserver ("sks db") laufen: nas2:11371. Im Moment enthält er nur PGP Schlüssel von Mitgliedern und Leuten, die hier öfters aufschlagen. Der Server redet von sich aus auch nicht mit anderen Schlüsselservern (kein "sks recon"). Auf der Kiste ist allerdings cron und anacron installiert, so dass abundzu /etc/cron.daily/pgp-keys-sync ausgeführt wird. Das Script tut mehrere Dinge mit folgenden Effekten:

Falls in der freien Wildbahn (auf öffentlichen Keyservern "draußen") neue Signaturen, Subkeys, Key Revocations von Schlüsseln auftauchen, die unser Keyserver speichert, werden diese auch importiert.

Es wird hier ein Dump der Datenbank erzeugt, welcher sich leicht per gpg --import importieren lässt. Wenn man also zu Besuch ist, kann man so seinen Schlüsselbund mit einem Befehl um ca 19 Schlüssel vergrößern.

Der Datenaustausch der Schlüsselserver läuft also nur in eine Richtung: von "außen" nach "innen".

Warum?[Bearbeiten]

Warum nicht?

Wie benutze ich den Keyserver?[Bearbeiten]

In der Kommandozeile sieht das dann zum Beispiel so aus:

gpg --keyserver nas2 --refresh-keys

Wenn man jetzt einen Schlüssel von jemandem unterschrieben hat, der nicht möchte, dass sein Schlüssel auf den öffentlichen Schlüsselservern auftaucht, dann sollte man diese keyserver-Option bei --send-keys echt nicht vergessen! Aber Bitte keine Schlüssel von Leuten drauf schicken, die aus unserem Dunstkreis sonst keiner kennt. Dafür ist der interne Schlüsselserver nicht gedacht.

Es gibt aber auch das bekannte Webinterface auf Port 11371. Siehe Screenshot rechts.

Internas und Konfigurationsfoo[Bearbeiten]

Folgendes wurde nach Installation angefasst:

/etc/sks/sksconf (Hostnamen eingetragen)
/etc/sks/mailsync (Default-E-Mail-Adresse für "mailsync" auskommentiert)
/etc/init.d/sks (Gossiping Dienst "sks recon" auskommentiert)
/var/lib/sks (Das Home-Verzeichnis des debian-sks Users, wo die DB liegt und das www Verzeichnis mit einer angepassten index.html)
/etc/cron.daily/pgp-keys-sync (Selbstgebasteltes Skript, was Updates von außen holt, einen Dump in //nas2/Public reinlegt und die Updates in die DB einpflegt)

Was man nicht erwarten sollte, ist, dass das Dumpen der Keys funktioniert, während die DB läuft. Die geht dann nämlich kaputt. Deswegen wird vor dem Dumpen der Keys die DB per /etc/init.d/sks stop angehalten und danach mit start wieder gesgartet. Das Einpflegen der Updates passiert über einem temporären GnuPG-KeyRing und einer --send-keys Aktion.

@@ Zeile 1: / Zeile 1: @@
 === Was? ===
+Ein PGP-Keyserver ist quasi ein elektronisches Telefonbuch. Statt Telefonnummern speichert er allerdings [https://de.wikipedia.org/wiki/OpenPGP PGP]-Schlüssel inklusive Beglaubigungen von Dritten.
 Wir haben einen innerhalb des Noklabs erreichbaren PGP-Keyserver ("sks db") laufen: nas2:11371. Im Moment enthält er nur PGP Schlüssel von Mitgliedern und Leuten, die hier öfters aufschlagen. Der Server redet von sich aus auch nicht mit anderen Schlüsselservern (kein "sks recon"). Auf der Kiste ist allerdings cron und anacron installiert, so dass abundzu /etc/cron.daily/pgp-keys-sync ausgeführt wird. Das Script tut mehrere Dinge mit folgenden Effekten:
@@ Zeile 5: / Zeile 7: @@
 * Falls in der freien Wildbahn (auf öffentlichen Keyservern "draußen") neue Signaturen, Subkeys, Key Revocations von Schlüsseln auftauchen, die unser Keyserver speichert, werden diese auch importiert.
-* Es wird [http://nas2.nok.lab/Public/pgp-keys.gpg hier] ein Dump der Datenbank erzeugt, welcher sich leicht per gpg --import importieren lässt. Wenn man also zu Besuch ist, kann man so seinen Schlüsselbund mit einem Befehl um mindestens 18 Schlüssel vergrößern.
+* Es wird [http://nas2.nok.lab/Public/pgp-keys.gpg hier] ein Dump der Datenbank erzeugt, welcher sich leicht per gpg --import importieren lässt. Wenn man also zu Besuch ist, kann man so seinen Schlüsselbund mit einem Befehl um ca 19 Schlüssel vergrößern.
 Der Datenaustausch der Schlüsselserver läuft also nur in eine Richtung: von "außen" nach "innen".
@@ Zeile 14: / Zeile 16: @@
 === Wie benutze ich den Keyserver? ===
+[[Datei:nas2sks2.png|thumb|Screenshot der Web-Schnittstelle]]
 In der Kommandozeile sieht das dann zum Beispiel so aus:
@@ Zeile 21: / Zeile 25: @@
 Wenn man jetzt einen Schlüssel von jemandem unterschrieben hat, der nicht möchte, dass sein Schlüssel auf den öffentlichen Schlüsselservern auftaucht, dann sollte man diese keyserver-Option bei --send-keys echt nicht vergessen! Aber Bitte keine Schlüssel von Leuten drauf schicken, die aus unserem Dunstkreis sonst keiner kennt. Dafür ist der ''interne'' Schlüsselserver nicht gedacht.
-Es gibt aber auch das bekannte [http://nas2.nok.lab:11371/ Webinterface] auf Port 11371. Und das sieht im Moment so aus:
+Es gibt aber auch das bekannte [http://nas2.nok.lab:11371/ Webinterface] auf Port 11371. Siehe Screenshot rechts.
+=== Internas und Konfigurationsfoo ===
+Folgendes wurde nach Installation angefasst:
+* /etc/sks/sksconf (Hostnamen eingetragen)
+* /etc/sks/mailsync (Default-E-Mail-Adresse für "mailsync" auskommentiert)
+* /etc/init.d/sks (Gossiping Dienst "sks recon" auskommentiert)
+* /var/lib/sks (Das Home-Verzeichnis des debian-sks Users, wo die DB liegt und das www Verzeichnis mit einer angepassten index.html)
+* /etc/cron.daily/pgp-keys-sync (Selbstgebasteltes Skript, was Updates von außen holt, einen Dump in //nas2/Public reinlegt und die Updates in die DB einpflegt)
-[[Datei:nas2sks2.png]]
+Was man nicht erwarten sollte, ist, dass das Dumpen der Keys funktioniert, während die DB läuft. Die geht dann nämlich kaputt. Deswegen wird vor dem Dumpen der Keys die DB per /etc/init.d/sks stop angehalten und danach mit start wieder gesgartet. Das Einpflegen der Updates passiert über einem temporären GnuPG-KeyRing und einer --send-keys Aktion.