PGPKeyserver: Unterschied zwischen den Versionen

Aus Wiki CCC Göttingen
Wechseln zu: Navigation, Suche
K (Was?)
(+Konfigurationsfoo)
Zeile 26: Zeile 26:
  
 
[[Datei:nas2sks2.png]]
 
[[Datei:nas2sks2.png]]
 +
 +
=== 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)
 +
 +
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.

Version vom 7. März 2014, 22:18 Uhr

Was?

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 mindestens 18 Schlüssel vergrößern.

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

Warum?

Warum nicht?

Wie benutze ich den Keyserver?

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. Und das sieht im Moment so aus:

Nas2sks2.png

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)

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.