Signieren von pub-Keys in der Konsole per caff

Aus Siduction Wiki DE
Wechseln zu: Navigation, Suche

So, wir wollten uns heute Abend mit "caff" beschäftigen, was das ist, was es macht, wozu wir es brauchen. Gut, es ist eine Sammlung von Skripten, die es uns einfacher macht viele schlüssel zu unterzeichnen z.b. nach der Teilnahme an einer keysign-Party. Da kommen dann mal schnell an die 100 schlüssel auf einen zu und die alle einzeln zu zeichnen und dem Gegner ne Mail zu schicken, ist heftig Arbeit.

Wo bekommen wir nun "caff" her? Es versteckt sich im Paket signing-party. Sind wir also mutig und installieren uns das Ding.

apt-get update && apt-get install signing-party

Nach dem ersten Aufruf finden wir ein neues Verzeichnis in unserem /home und zwar ./caff. Dort verwaltet caff die Schlüssel: Es greift also nicht auf unser Standard gnupg zu. Und dies ist gut so, denn wir möchten ja nicht immer wieder alle uns bekannten Key zeichnen, dazu aber später mehr.

In unserem /home finden wir jetzt auch eine Datei .caffrc, die schauen wir uns bitte mal genauer an. Hier gilt es Parameter zu setzen.

$CONFIG{'owner'} = 'Name Vorname'
dto email erklärt sich von selbst
replay-to nicht notwendig
dto keyid - hier kommt die ID der Key(s) rein, mit denen wir die anderen keys signieren wollen, bei Verwendung von  mehrer ID's werden die mittels Leerzeichen getrennt. 

weiter unten in der Datei können wir den text, der dem "Gegner" geschickt wird anpassen So hätten wir jetzt die Grundlage geschaffen.

Einen kleinen Nachteil hat caff. Es benötigt einen MTA (Mailserver), caff kann nicht aus eigener Kraft auf einen SMTP eines ISP zugreifen und nicht jeder hat zu Hause einen vollwertigen SMTP. Also brauchen wir eine Krücke, als Beispiel lege ich hier !exim4 vor. Natürlich ist auch postfix, ssmtp, masqmail & co möglich. Einzige Voraussetzung für die Sache, der MTA muss mit smarthost arbeiten können Also, in die Hände gespuckt, ein Bier geschluckt und !exim4 installiert

apt-get update && apt-get install exim4

Nun müssen wir !exim4 unseren Willen aufzwingen. Dazu nutzen wir, als root:

dpkg-reconfigure exim4-config

und die Fragestunde geht los:

erste Frage geben wir ok, gibt ja keine Alternative;
bei der zweiten haben wir schon mehr Auswahl und wir nehmen die goldene Mitte - also 3. von oben, oder auch 3. von unten;
Versand über Sendezentrale (Smarthost); keine lokale ... und geben erneut Ok
nächste Frage: hier geben wir an wie unser Mailsystem sich nennen soll, also was an den Sendernamen angehangen werden soll, könnte also sein sidux-ev.de. Dann macht !exim4 beim Versand daraus <user>@sidux-ev.de. Wir bestätigen mit Ok
Die nächste Frage, in Ermanglung von Alternativen bestätigen wir auch mit Ok. 
Nun fragt er uns nach einer IP-Adresse. Da setzen wir (wir arbeiten ja letztlich lokal) 127.0.0.1 und geben erneut ein freundliches Ok ein.
In der folgenden Abfrage können wir z.b. sidux-ev.de geben, die spielt in unserem Anwendungsfall keine wirkliche Rolle, da wir !exim4 nur für den Versand benutzen, und das Teil auf keinen Incoming lauscht, also weiter mit Ok.
Auch die nächste Abfrage ist nicht wichtig für uns, da !exim4 keine lokale Verteilung vornehmen soll. Damit dort was steht, schreiben wir erneut sidux-ev.de rein. Und wieder ein Ok. Und schon wieder keine Auswahl, also nochmal OK.
Nun kommt ein wichtiger Punkt: IP-Adresse Sendezentrale: hier kommt die SMTP-Adresse des zu verwendenden SMTP's rein, also z.b. der SMTP von Eurem Provider oder der SMTP von sidux-ev.de
Bitte genau darauf achten das alle Buchstaben dort sind, wo sie hingehören und wieder ein nettes Ok.
Und nochmal Ok.
Die Frage DNS-Anfragen ... beantworten wir mit Nein und, wir kennen es schon, mangels Alternative beantworten wir die Folge Fragen mit OK. Wir nähern uns dem Ende.
Einstellungen auf kleine ... das wollen wir nicht, also Nein.

Wir prüfen unsere Einstellungen mit

nano /etc/exim4/update-exim4.conf.conf

und vergleichen alles mit unserem Muster-File:

dc_eximconfig_configtype='satellite'
dc_other_hostnames='provider.de'
dc_local_interfaces='127.0.0.1'
dc_readhost='provider.de'
dc_relay_domains=
dc_minimaldns='false'
dc_relay_nets=
dc_smarthost='smtp.provider.de'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

So jetzt sollte !exim4 neu gestartet werden und wer jetzt glaubt wir hätten !exim4 schon fertig angepasst, der irrt, denn irgendwas müssten wir ihm noch sagen.

So sammeln wir uns wieder: Im Verzeichnis /etc/!exim4/ finden wir die Datei passwd.client. Die stellt die zur Anmeldung am fernen SMTP erforderlichen Werte zur Verfügung. Der Eintrag hat folgendes Format:

smtp_den_wir_benutzen_wollen:benutzername:passwort

speichern, fertisch !!! Jetzt testen wir, ob alles auch wirklich funktioniert. Also verschicken wir mal ne Mail an uns selbst. Nein, dazu brauchen wir keinen Mail-Client. Gut wir könnten mailx installieren, aber dazu sind wir zu faul und da wir bekanntermaßen Helden sind, machen wir's mit den normalen Bordmitteln:

echo "Inhalt" | mail -s Betreff deineEmail@sidux-ev.de

und ab soll er gehen. Und nun sollte eine entsprechende Mail im Posteingang Deines user@sidux-ev.de zu finden sein. Schön, damit haben wir unseren MTA im Griff, wenden wir uns also wieder caff zu. Wie schon eingangs aufgezeigt, verwendet caff nicht unserer Standard-GPG-Infrastruktur, sondern hat eine eigene. Dies aus gutem Grund, denn wir wollen nicht jedes mal alle Keys verhackstücken, sondern gezielt nur neue, die wir z.b. nach einer keysign-Party als keyring bekommen.

Wenn wir einen Blick in das Verzeichnis ~./caff werfen, sehen wir dort u.a. /gnupghome. Dort verwaltet caff "seinen" keyring. Also bringen wir die Keys, die wir zeichnen wollen nach dort. Der Parameter --homedir macht uns hier glücklich. Mit dem steuern wir nach, wohin GPG den Import machen soll, denn, wir erinnern uns --import nutzt immer die GPG-Standard-Umgebung, also ~./gnupg und wir hätten es gerne im anderen Verzeichnis. Im Verzeichnis ~./caff/keys merkt sich caff, welche Schlüssel wann unterzeichnet wurden. Dadurch wird mehrfaches Unterzeichnen verhindert.

Wie wir schon ahnen, werden wir später beim Aufruf von caff irgendwie sagen müssen, welche schlüssel wir unterzeichnen wollen.

Dazu brauchen wir die UID's der Schlüssel. Wo bekommen wir die her?

Gut wir könnten alle einzeln ansehen, aufschreiben, tralala ... wir aber sind Helden ... wir nehmen etwas gpg, etwas awk und basteln daraus:

gpg --no-default-keyring --keyring /pfad/zum/ring/ausdemwir/die/uids/haben/wollen/datei.gpg --with-colons --list-keys | awk -F: '/^pub/ { print $5}' > uids.txt

und ab dafür. Schon haben wir die Liste in der uids.txt stehen. Nun könnten wir caff anwerfen und dazu hilfreiche Parameter:

caff -m yes 

damit er uns nicht immer fragt, ob er Mail schicken soll, wenn wir mehrere eigene Keys in der config eingetragen haben, aber nur mit einem unterschreiben wollen. -u UID sonst wird, hätten wir z.b. 3 Keys in der config mit den dreien unterschrieben und ganz zum Schluss hängen wir die UID's der Keys an. die wir zeichnen wollen. Dazu haben wir z.b. so eine uids.txt.

Daran hängen wir dann `

cat /pfad/zur/uids.txt`

Ich weiß schon, bald wird die Frage kommen: so ein Mist, dauernd muss ich das Passwort eingeben. Da ist gpg-agent Dein Freund: es befindet sich im gnupg-agent Paket. Damit kann man das Haltbarkeitsdatum, Cache des Passworts setzen. Dazu jedoch ein andermal mehr, muss jetzt erst mal was trinken, ganz trockene kehle vom vielen reden... [Anm. des Adju's: ... und ich vom vielen Mitschreiben]

Dank an vedawalter vom sidux e.V.