Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- nitrokey:arch:start [04.06.2024 18:54. ] – [Anwendungsfälle - Software] django
+++ nitrokey:arch:start [09.07.2025 12:05. ] (aktuell) – [Nitrokey Start und Thunderbird] django
@@ Zeile 43: / Zeile 43: @@
 /0/100/1f.6              generic        Wildcat Point-LP Thermal Management Controller</code>
-Mit Hilfe des Befehls ''lsusb'' aus dem RPM-Paket **usbutils** können wir auch die **Produkt-** und **Hersteller**-Identifikationsnummer des Nitrokey-Sticks ermitteln.
+Mit Hilfe des Befehls ''lsusb'' aus dem Arch-Linux-Paket **usbutils** können wir auch die **Produkt-** und **Hersteller**-Identifikationsnummer des Nitrokey-Sticks ermitteln.
    # lsusb | grep Nitrokey
   Bus 002 Device 020: ID 20a0:4211 Clay Logic Nitrokey Start
@@ Zeile 128: / Zeile 128: @@
 ++++
-Die erforderliche udev-Regel findet sich also in der Datei **''/usr/lib/udev/rules.d/41-nitrokey.rules''***.
+Die erforderliche udev-Regel findet sich also in der Datei **''/usr/lib/udev/rules.d/41-nitrokey.rules''**.
 ==== erster Test ====
@@ Zeile 273: / Zeile 273: @@
 Wir wollen uns nun einen neuen PGP-Schlüssel in der SmartCard erzeugen und rufen hierzu den Befehl **generate** auf. Der **Nitrokey Start** unterstützt **__RSA__-Schlüssellängen** von **1024** und maximal von **2048**!
-<WRAP center round important 80%>
+<WRAP center round important 90%>
 Mit Hinblick auf die möglichen Unsicherheiten im Bezug auf die [[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf|RSA-Schlüssellänge]] werden wir uns später noch eingehend mit der Erstellung eines [[start#ed25519-schluessel_generieren|ED25519]] beschäftigen!
@@ Zeile 308: / Zeile 308: @@
 Real name: Django aka [BOfH]
-Email address: secmail@mailserver.guru
+Email address: secmail@nausch.org
 Comment: Bastard Operator from Hell
 You selected this USER-ID:
-    "Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru>"
+    "Django aka [BOfH] (Bastard Operator from Hell) <secmail@nausch.org>"
 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
@@ Zeile 318: / Zeile 318: @@
 Nun wird auf der Karte der gewählte Schlüssel erzeugt.
-<WRAP center round tip 95%>
+<WRAP center round tip 90%>
 Die Erzeugung eines Schlüssels mit einer Länge von **2048** dauert ca. 5 Minuten, also keinesfalls den Nitrokey Start abziehen oder die Generierung abbrechen! Während der Erzeugung der Schlüssel leuchtet die rote LED im Stick.
 </WRAP>
@@ Zeile 329: / Zeile 329: @@
 pub   rsa2048 2020-08-04 [SC]
       E65B2BDF79A2E2E4C28F6E062E22436430385B49
-uid                      Django aka [BOfH] (Bastard Operator from Hell) <secmail@mailserver.guru>
+uid                      Django aka [BOfH] (Bastard Operator from Hell) <secmail@nausch.org>
 sub   rsa2048 2020-08-04 [A]
 sub   rsa2048 2020-08-04 [E]</code>
@@ Zeile 482: / Zeile 482: @@
 Real name: Django aka [BOfH]
-Email address: secmail@mailserver.guru
+Email address: secmail@nausch.org
 Comment: Bastard Operator from Hell
 You selected this USER-ID:
@@ Zeile 548: / Zeile 548: @@
 === Öffentlichen Schlüssel ausgeben ===
 Damit wir später unseren öffentlichen Schlüssel auch weitergeben oder zu einem [[https://keys.openpgp.org/|Keyserver]] hoch laden, exportieren wir diesen in eine Datei.
-  $ gpg --export --armor django@nausch.org > ~/.gnupg/secmail@mailserver.guru.pubkey
+  $ gpg --export --armor django@nausch.org > ~/.gnupg/django@nausch.org.pubkey
 Diese Datei enthält unseren Schlüssel in ASCII-lesbarer Form.
-  $ cat ~/.gnupg/secmail@mailserver.guru.pubkey
+  $ cat ~/.gnupg/django@nausch.org.pubkey
-<file key secmail@mailserver.guru.pubkey>-----BEGIN PGP PUBLIC KEY BLOCK-----
+<file key secmail@nausch.org.pubkey>-----BEGIN PGP PUBLIC KEY BLOCK-----
 mDMEZZXO7BYJKwYBBAHaRw8BAQdA++J6Astvcm2DsHDnzXGHKujQiokCxG+F3qPy
@@ Zeile 677: / Zeile 677: @@
 === change-pin ===
-<WRAP center round alert 95%>
+<WRAP center round alert 90%>
 **WICHTIG**:
 Unbedingt vor dem ersten Ändern der PINs ist es notwendig, erst einmal Schlüssel zu generieren bzw. zu importieren! Denn sonst schlägt das Ändern der Benutzer-PIN fehl, bzw. wird die Benutzer-PIN beim Überschreiben von Schlüsseln auf den Default-Wert von **123456** zurückgesetzt. Die Default-PIN für den Admin lautet **12345678**.
@@ Zeile 690: / Zeile 690: @@
 Die Admin-PIN (Menüpunkt **3**) wird für die Karten-/Token-Verwaltung verwendet, so z.B. für das Laden von Schlüsseln auf den Krypto-Stick, das Erzeugen von Schlüsseln oder das Ändern von Informationen wie die Inhaberdaten auf der Karte. Die Mindestlänge für die Admin-PIN beträgt 8 Zeichen.
-<WRAP center round important 95%>
+<WRAP center round important 90%>
 Wird die Benutzer-PIN 3x falsch eingeben, wird die Karte gesperrt und kann dann nur mit der Admin-PIN oder dem Reset-Code zurückgesetzt werden. Wenn Sie den falschen Admin-Pin dreimal eingeben, wird die Karte unbrauchbar und kann dann lediglich mit einem Factory-Reset (Verlußt aller Kartendaten!) zurück gesetzt werden!
@@ Zeile 775: / Zeile 775: @@
 gpg/card> quit</code>
+=== Schlüssel umziehen bzw. auf weiterem Rechner nutzen ===
+Oft kommt es vor dass man entweder sein Schlüsselmaterial von einem Rechner auf einen anderen|neuen umziehen möchte, oder man benutzt ein und denselben Stick wahlweise auf mehreren Rechnern (Desktop, Laptop, etc.).
+<WRAP center round tip 90%>
+Nur wie bekommt man nun seinen privaten Schlüssel, der ja nur in der SmartCard des Kryptosticks sicher verwahrt wird, oder genauer gesagt seine Identität auf den neuen weiteren Rechner? Ganz einfach, man exportiert den OpenPGP-Schlüssel aus dem Schlüsselbund und importiert diesen dann auf dem neuen Rechner wieder mit GnuPG!
+Der Ablauf ist der Gleiche wie bei einem "normalen PGP-Key" welchen wir z.B. mit Hilfe von **''gpg %%--%%generate-key''** erzeugt hätten. Der private Schlüssel auf dem Kryptostick ist dabei so etwas wie ein "Dummy", der lediglich die Information enthält, dass der eigentlich richtige private Schlüssel auf dem Stick mit der **ID...** zu finden ist. Und genau dieser "Dummy" muss dann auf dem  weiteren Rechner in den **keyring** importiert werden.</WRAP>
+Zunächst werfen wir also einen Blick in unseren keyring:
+   $ gpg2 --list-secret-keys
+<code>/home/django/.gnupg/pubring.kbx
+-------------------------------
+sec>  ed25519 2024-01-03 [SC]
+C082445CDFB72DECD650350610ED9AEE553353F
+      Card serial no. = FFFE 43243711
+uid           [ultimate] Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+ssb>  ed25519 2024-01-03 [A]
+ssb>  cv25519 2024-01-03 [E]
+sec>  ed25519 2024-12-15 [SC]
+      F5F0CD13074BA693D950F92A0A56C9A3A69FE291
+      Card serial no. = 000F 6447F253
+uid           [ultimate] Michael Nausch <michael@nausch.org>
+ssb>  ed25519 2024-12-15 [A]
+ssb>  cv25519 2024-12-15 [E]</code>
+Den privaten Schlüssel unseres Nitrokey mit der Karten Serien-Nummer **''000F 6447F253''** und der Key-ID **''0A56C9A3A69FE291''** wollen wir nun auf unseren weiteren Rechner holen. Hierzu stecken wir diesen an unseren "alten bzw. ersten" Rechner. Mit folgendem Aufruf können wir auch die benötigten Infos auslesen um sicherzustellen, dass auch wirklich der eine von unseren 13 Kryptosticks der richtige ist. 8-)
+   $ gpg --card-status | grep 'General key info'
+  General key info..: pub  ed25519/0A56C9A3A69FE291 2024-12-15 Michael Nausch <michael@nausch.org>
+Zunächst exportieren wir nun also die "Key-Dummy-Daten":
+   $ gpg -o ~/michael@nausch.org.sc_dummy_private_key.asc --export-secret-key 0A56C9A3A69FE291
+Diese Datei enthält nun alle nötigen Informationen.
+   $ file ~/michael@nausch.org.sc_dummy_private_key.asc
+  /home/django/michael@nausch.org.sc_dummy_private_key.asc: OpenPGP Secret Key Version 4, Created Sun Dec 15 17:08:38 2024, EdDSA; User ID; Signature; OpenPGP Certificate
+Diese Datei kopieren wir nun auf einem sicheren und geschützten Weg auf unseren neuen weiteren Rechner.
+Werfen wir zunächst noch einen Blick in den **keyring** auf unserem zweiten Rechner:
+   $ gpg2 --list-secret-keys
+<code>/home/django/.gnupg/pubring.kbx
+-------------------------------
+sec>  ed25519 2024-01-03 [SC]
+C082445CDFB72DECD650350610ED9AEE553353F
+      Card serial no. = FFFE 43243711
+uid           [ultimate] Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+ssb>  ed25519 2024-01-03 [A]
+ssb>  cv25519 2024-01-03 [E]
+</code>
+Hier fehlt also **__noch__** die Information für unseren weiteren Kryptostick der die eMail-adresse **''michael@nausch.org''** bedient.
+Wir importieren also nun die kopierte Pseudo-Dummy-Keydatei, welche wir auf unseren neuen bzw. weiteren Rechner kopiert haben.
+   $ gpg --import Downloads/michael@nausch.org.sc_dummy_private_key.asc
+<code>gpg: key 0A56C9A3A69FE291: public key "Michael Nausch <michael@nausch.org>" imported
+gpg: To migrate 'secring.gpg', with each smartcard, run: gpg --card-status
+gpg: key 0A56C9A3A69FE291: secret key imported
+gpg: Total number processed: 1
+gpg:               imported: 1
+gpg:       secret keys read: 1</code>
+Wie uns aufgetragen migrieren wir nun für die neue smartcard den **''secring.gpg''** bei angestecktem Nitrokey:
+   ~$ gpg --card-status
+<code>Reader ...........: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00
+Application ID ...: D276000124010304000F6447F2530000
+Application type .: OpenPGP
+Version ..........: 3.4
+Manufacturer .....: unknown
+Serial number ....: 6447F253
+Name of cardholder: Michael Nausch
+Language prefs ...: de
+Salutation .......: Mr.
+URL of public key : https://keys.openpgp.org/search?q=get&search=0x0A56C9A3A69FE291
+Login data .......: django
+Signature PIN ....: forced
+Key attributes ...: ed25519 cv25519 ed25519
+Max. PIN lengths .: 127 127 127
+PIN retry counter : 3 0 3
+Signature counter : 10
+KDF setting ......: off
+Signature key ....: F5F0 CD13 074B A693 D950  F92A 0A56 C9A3 A69F E291
+      created ....: 2024-12-15 17:08:38
+Encryption key....: DBBD 5355 D9D0 334A A3FA  751F A89D D54D AE0E 394A
+      created ....: 2024-12-15 17:08:38
+Authentication key: EE7C 3807 4F0A 8F2A 5601  BF91 1E61 4A9A 36D4 DF53
+      created ....: 2024-12-15 17:08:38
+General key info..: pub  ed25519/0A56C9A3A69FE291 2024-12-15 Michael Nausch <michael@nausch.org>
+sec>  ed25519/0A56C9A3A69FE291  created: 2024-12-15  expires: never
+                                card-no: 000F 6447F253
+ssb>  ed25519/1E614A9A36D4DF53  created: 2024-12-15  expires: never
+                                card-no: 000F 6447F253
+ssb>  cv25519/A89DD54DAE0E394A  created: 2024-12-15  expires: never
+                                card-no: 000F 6447F253</code>
+Nun lassen wir uns erneut alle secret-key-Informationen unsere **keyring** anzeigen:
+   $ gpg2 --list-secret-keys
+<code>/home/django/.gnupg/pubring.kbx
+-------------------------------
+sec>  ed25519 2024-01-03 [SC]
+C082445CDFB72DECD650350610ED9AEE553353F
+      Card serial no. = FFFE 43243711
+uid           [ultimate] Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+ssb>  ed25519 2024-01-03 [A]
+ssb>  cv25519 2024-01-03 [E]
+sec>  ed25519 2024-12-15 [SC]
+      F5F0CD13074BA693D950F92A0A56C9A3A69FE291
+      Card serial no. = 000F 6447F253
+uid           [ unknown] Michael Nausch <michael@nausch.org>
+ssb>  ed25519 2024-12-15 [A]
+ssb>  cv25519 2024-12-15 [E]
+</code>
+Voila, wir haben also nun alle benötigten Informationen in unserem keyring, so dass wir den weiteren Nitrokey auch auf unserem zusätzlichen Rechner nutzen können!
+<WRAP center round important 90%>
+**WICHTIG:** \\ \\ Wollen wir unseren transferierten Schlüssel auch in **[[#nitrokey_start_und_thunderbird|Thunderbird]]** nutzen reicht es **__nicht__** den Schlüssel wie soeben beschrieben nur "in" **''gpg''** zu im portieren, der Schlüssel muss zusätzlich über die **OpenPGP-Schlüsselverwaltung von Thunderbird** importiert werden! Ansonsten kommt es zu unliebsamen Fehlermeldungen wie z.B. **''Die konfigurierte Schlüssel-ID wurde nicht in Ihrem Schlüsselbund gefunden.''**!
+</WRAP>
 === Verschlüsseln und entschlüsseln ===
@@ Zeile 790: / Zeile 909: @@
 PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
 LOGO=archlinux-logo"</code>
-  - Nun verschlüsseln wir dieses Textdokument: <code> $ gpg2 -o testdatei.txt.pgp -a -r secmail@mailserver.guru -e testdatei.txt</code>  Wir haben also nun zwei Dokumente auf der Platte liegen. <code> $ ll testdatei.txt*</code><code>-rw-r--r-- 1 django django 382 Jun  3 22:35 testdatei.txt
+  - Nun verschlüsseln wir dieses Textdokument: <code> $ gpg2 -o testdatei.txt.pgp -a -r django@nausch.org -e testdatei.txt</code>  Wir haben also nun zwei Dokumente auf der Platte liegen. <code> $ ll testdatei.txt*</code><code>-rw-r--r-- 1 django django 382 Jun  3 22:35 testdatei.txt
 -rw-r--r-- 1 django django 581 Jun  3 22:35 testdatei.txt.pgp</code>Die Datei **testdatei.txt.pgp** können wir nun soweit nicht mehr lesen.<code> $ cat testdatei.txt.pgp</code><code>-----BEGIN PGP MESSAGE-----
@@ Zeile 804: / Zeile 923: @@
 -----END PGP MESSAGE-----</code>
   - Nun entschlüsseln wir unser Dokument wieder.<code> $ gpg2 --decrypt testdatei.txt.pgp > testdatei-entschlüsselt.txt</code><code>gpg: encrypted with cv25519 key, ID B5E54345BDA292A0, created 2024-01-03
-      "Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>"
+      "Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>"</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Den Inhalt dieser Datei können wir nun nach erfolgter Entschlüsselung natürlich wieder lesen.<code> $ cat testdatei-entschlüsselt.txt</code><code>>NAME="Arch Linux"
-gpg: all values passed to '--default-key' ignored
-</code> {{ :suse:nitrokey:nitrokey-start-suse-01.png?direct&350 |Bild: Bildschirmhardcopy der gpg-keyentry Abfrage}} Den Inhalt dieser Datei können wir nun nach erfolgter Entschlüsselung natürlich wieder lesen.<code> $ cat testdatei-entschlüsselt.txt</code><code>>NAME="Arch Linux"
 PRETTY_NAME="Arch Linux"
 ID=arch
@@ Zeile 902: / Zeile 1019: @@
 {{ :nitrokey:arch:thunderbird_007.png?nolink&874 |Bild: Menüfenster der Thunderbird individuellen Einstellungen}}
+<WRAP center round important 90%>
+**WICHTIG:** \\ Haben wir generierte Schlüssel von einem anderen Rechner aus auf unserem aktuellen Rechner kopiert und diese, wie im Kapitel **[[#schluessel_umziehen_bzw_auf_weiterem_rechner_nutzen|Schlüssel umziehen bzw. auf weiterem Rechner nutzen]]** beschrieben, importiert **__müssen__** wir die secret-keys auch noch Thunderbird und dessen **OpenPGP-Schlüssel Verwaltung** bekannt machen! \\
+Ansonsten kommt es zu unliebsamen Fehlermeldungen wie z.B. **''Die konfigurierte Schlüssel-ID wurde nicht in Ihrem Schlüsselbund gefunden.''**, da Thunderbird von der Existenz der hinterlegten privaten schlüssel zwar Kenntnis hat, diese aber auf Grund der fehlenden Verknüpfung nicht nutzen kann.
+</WRAP>
+Zur Kontrolle ob alle privaten Schlüssel in Thunderbird verankert sind oder zum Importieren von neuen (umgezogenen) Private Keys klicken wir auf die Schaltfläche **[ OpenPGP-Schlüssel __v__erwalten ]** auf der Konfigurations-Seite **Ende-zu-Ende-Verschlüsselung** bei den **Kontoeinstellungen**.
+{{ :nitrokey:arch:thunderbird_007.png?nolink&874 |Bild: Menüfenster der Thunderbird individuellen Einstellungen}}
+Im Folgenden Konfigurationsbeispiel sehen wir nur den Schlüssel für einen User|Adresse **''django@nausch.org''**.
+{{ :nitrokey:arch:thunderbird_010.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Zum Importieren des Schlüssels für den User|Adresse **''michael@nausch.org''** wählen wir unter **Datei** den Punkt **Geheime(n) Schlüssel aus Datei importieren**
+{{ :nitrokey:arch:thunderbird_011.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Auf der Folgenden Seite klicken wir nun auf die Schaltfläche **[ __D__atei für den Import auswählen ]** und wählen dann die betreffende Schlüsseldatei aus
+{{ :nitrokey:arch:thunderbird_011a.png?nolink&450 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Nun präsentiert und Thunderbirds Schlüsselverwaltung den erkannten Schlüssel für den User|Adresse **''michael@nausch.org''**. Wichtig ist das der Haken bei **Diesen Schlüssel als persönlichen Schlüssel verwenden** gesetzt ist. Anschliessend wählen wir die Schaltfläche **[ Fortfahren ]** aus.
+{{ :nitrokey:arch:thunderbird_012.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Über den Menüpunkt **[ Schlüss__e__leigenschaften ]** können wir uns nochmal svergewissern ob der Schlüssel für unseren Einsatzzwek entsprechend passt.
+{{ :nitrokey:arch:thunderbird_013.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Mit einem Klick auf die Schatfläche **[ OK ]** kommen wir zurück zur vorherigen Anzeige.
+{{ :nitrokey:arch:thunderbird_014.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+Dort klicken wir auf die Schlatfläche **[ S__c__hließen ]** und beenden damit den Import des Schlüsselmaterials bzw. des Dummy-Privatekey unseres Nitrokeys.
+Wir sehen nun unsere beiden aktiven Schlüssel:
+{{ :nitrokey:arch:thunderbird_015.png?nolink&550 |Bild: Menüfenster der Thunderbird individuellen Einstellungen zu OpenPGP-Schlüssel verwalten}}
+==== Nitrokey Start und Secure Shell ====
+<WRAP center round important 90%>
+Ob man in Zeiten von Überwachungsphantasten in Unternehmen und vor allem auch bei einer NSA oder BND, noch **[[http://www.golem.de/news/elliptische-kurven-die-herkunft-der-nist-kurven-1309-101567.html|RSA-Schlüssel]]** einsetzen kann und mag, muss natürlich jeder verantwortungsbewusste Administrator für sich selbst entscheiden.
+Der Sicherheitsguru Bruce Schneier hat in seinem **[[https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929|Blog]]** hierzu eine eindeutige Aussage getätigt:
+<wrap em>//"On the crypto bits in your guardian piece, I found especially interesting that you suggest classic discrete log crypto over ecc. I want to ask if you could elaborate more on that." __I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.__//</wrap>
+**[[https://de.wikipedia.org/wiki/Curve25519|EED25519]]** ist ein Elliptic Curve Signature Schema, welches beste Sicherheit bei vertretbaren Aufwand verspricht, als ECDSA oder DSA dies der Fall ist. Detaillierte Informationen zur **[[https://martin.kleppmann.com/papers/curve25519.pdf|Implementierung von Curve25519/X25519: Ein Tutorial zur elliptischen Kurvenkryptografie]]** finden sich in dem verlinktem Dokument von [[https://martin.kleppmann.com/|Martin Kleppmann]]. Zur Auswahl sicherer kryptografischer Kurven bei der //Elliptic-Curve Cryptography// findet man auf der Seite [[https://safecurves.cr.yp.to/|hier]] hilfreiche Erklärungen und eine Gegenüberstellung der möglichen verschiedenen Alternativen.
+</WRAP>
+Auf RSA Schlüssel muss man aber nicht mehr zwingend zurückgreifen, stehen doch aktuellere und zeitgemässere Cipher, MACs, Schlüssel Typen und Key Exchange Algorithmen zur Verfügung. Als Alternative zu einem RSA-Keys haben wir uns bereits im Abschnitt **[[start#ed25519-schluessel_generieren|Nitrokey Start und GnuPG - ED25519-Schlüssel generieren]]** Schlüsselmaterial auf Basis elliptischer Kurven erstellt, unter anderem auch einen //**Authentication Key**// erstellt.
+Diesen Schlüssel wollen wir nun auch zur Serveradministration verwenden.
+=== SSH Client vorbereiten ===
+Damit wir beim Verbindungsaufbau auf den Authentication Key zugreifen können, müssen wir unseren Client entsprechend vorbereiten.
+In der Konfigurationsdatei //**~/.gnupg/gpg.conf**// setzen wir als erstes die Option ''**use-agent**''.
+   $ vim ~/.gnupg/gpg.conf
+<file bash ~/.gnupg/gpg.conf># File re-created by pEp
+# See backup in '/home/django/.gnupg/gpg.conf.1.pep.bkp'
+# File re-created by pEp
+# See backup in '/home/django/.gnupg/gpg.conf.0.pep.bkp'
+# Created by pEpEngine
+keyserver hkp://keys.gnupg.net
+cert-digest-algo SHA256
+no-emit-version
+no-comments
+personal-cipher-preferences AES AES256 AES192 CAST5
+personal-digest-preferences SHA256 SHA512 SHA384 SHA224
+ignore-time-conflict
+allow-freeform-uid
+# Ansible generated, do not edit manual!
+# Option use-agent für Authentication Key Nutzung des Nitrokey Start bei SSH
+use-agent
+</file>
+Im nächsten Schritt aktivieren wir die Option ''**enable-ssh-support**'' in der Konfigurationsdatei //**~/.gnupg/gpg-agent.conf
+**// des GPG-Agenten.
+   $ vim ~/.gnupg/gpg-agent.conf
+<file bash ~/.gnupg/gpg-agent.conf># File re-created by pEp
+# See backup in '/home/django/.gnupg/gpg-agent.conf.1.pep.bkp'
+# File re-created by pEp
+# See backup in '/home/django/.gnupg/gpg-agent.conf.0.pep.bkp'
+default-cache-ttl 300
+max-cache-ttl 999999
+# Ansible generated, do not edit manual!
+# SSH-Support activated for gnupg-agent
+enable-ssh-support
+</file>
+Nun werden wir noch die Datei //**~/.bashrc**// erweitern, damit der **SSH_AUTH_SOCK** für den Zugriff des SSH-Schlüssels auf dem Nitrokey Start genutzt werden kann.
+   $ vim ~/.bashrc
+<file bash ~/.bashrc># .bashrc
+# Source global definitions
+if [ -f /etc/bashrc ]; then
+        . /etc/bashrc
+fi
+# User specific environment
+PATH="$HOME/.local/bin:$HOME/bin:$PATH"
+export PATH
+# Uncomment the following line if you don't like systemctl's auto-paging feature:
+# export SYSTEMD_PAGER=
+# User specific aliases and functions
+# Django : 2024-05-25
+#          Definition des SSH_AUTH_SOCK für den Zugriff des SSH-Schlüssels auf dem Nitrokey Start
+unset SSH_AGENT_PID
+        if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
+        export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
+fi</file>
+Damit unsere Änderungen aktiv werden, müssen wir nun zum Schluss noch den **pgp-agent** restarten bzw. einen Neustart des Clients erwirken. Wir entscheiden uns der Einfachheit halber von einen Neustart des Agenten mit Hilfe des Befehls ''**pkill gpg-agent**''.
+   $ pkill gpg-agent
+Ein Blick in die Prozessliste zeigt, dass der Agent nicht mehr läuft.
+   $ ps aux | grep gpg-agent
+  django    8752  0.0  0.0 215740   820 pts/1    S+   21:56   0:00 grep --color=auto gpg-agent
+Nun stecken wir unseren Nitrokey Start an den USB-Port und fragen den Kartenstatus ab.
+   $ gpg2 --card-status
+<code>Reader ...........: 20A0:4211:FSIJ-1.2.19-43243711:0
+Application ID ...: D276000124010200FFFE432437110000
+Application type .: OpenPGP
+Version ..........: 2.0
+Manufacturer .....: unmanaged S/N range
+Serial number ....: 43243711
+Name of cardholder: Michael Nausch
+Language prefs ...: de
+Salutation .......: Mr.
+URL of public key : [not set]
+Login data .......: [not set]
+Signature PIN ....: forced
+Key attributes ...: ed25519 cv25519 ed25519
+Max. PIN lengths .: 127 127 127
+PIN retry counter : 3 3 2
+Signature counter : 23
+KDF setting ......: off
+UIF setting ......: Sign=off Decrypt=off Auth=off
+Signature key ....: 2C08 2445 CDFB 72DE CD65  0350 610E D9AE E553 353F
+      created ....: 2024-01-03 21:17:32
+Encryption key....: 9533 C548 589F F00B 8FFF  C93B B5E5 4345 BDA2 92A0
+      created ....: 2024-01-03 21:17:32
+Authentication key: D5AF 3627 1220 7A2A 54BD  6C47 C72E 74B8 1A5C 4549
+      created ....: 2024-01-03 21:17:32
+General key info..: pub  ed25519/610ED9AEE553353F 2024-01-03 Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+sec>  ed25519/610ED9AEE553353F  created: 2024-01-03  expires: never
+                                card-no: FFFE 43243711
+ssb>  ed25519/C72E74B81A5C4549  created: 2024-01-03  expires: never
+                                card-no: FFFE 43243711
+ssb>  cv25519/B5E54345BDA292A0  created: 2024-01-03  expires: never
+                                card-no: FFFE 43243711
+</code>
+Ein erneuter Blick in die Prozessliste zeigt nun den neu gestarteten Agenten.
+   $ ps aux | grep gpg-agent
+  django    8766  0.0  0.0 364724   804 ?        Ss   21:57   0:00 gpg-agent --homedir /home/django/.gnupg --use-standard-socket --daemon
+  django    8853  0.0  0.0 215740   828 pts/1    S+   22:00   0:00 grep --color=auto gpg-agent
+=== Public-Key des ED25519 SSH exportieren ===
+Für den Zugriff auf unser Ziel-System mit Hilfe der SSH benötigen wir noch den öffentlichen Schlüssel unseres Authentication Keys, den wir nun exportieren werden.
+Zunächst besorgen wir uns die betreffende Schlüsselkennung des Authentication Keys, genauer gesagt die 4 letzten Zahlenreihen des nachfolgenden Aufrufs.
+   $ gpg2 --card-status | grep Authentication\ key
+  Authentication key: D5AF 3627 1220 7A2A 54BD  6C47 C72E 74B8 1A5C 4549
+In diesem Konfigurationsbeispiel ist die Schlüssel-ID des Autentication Keys also die Nummer ''**C72E74B81A5C4549**''.
+Nun exportieren wir den öffentlichen Schlüssel und schreiben diesen in eine separate Datei.
+   $ gpg2 --export-ssh-key C72E74B81A5C4549 >> ~/.ssh/C72E74B81A5C4549.pub
+Der Öffentliche Schlüssel in diesen Konfigurationsbeispiel lautet also:
+   $ cat ~/.ssh/C72E74B81A5C4549.pub
+  ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHMD4OSvbbTRAs88C5jQeUX7HOR0TYd+EIQLcKmGCBll openpgp:0x1A5C4549
+Diesen Schlüssel kopieren wir nun auf das entsprechende Zielsystem an Ort und Stelle ''**~/.ssh/authorized_keys**''.
+   $ scp ~/.ssh/C72E74B81A5C4549.pub zielhost.dmz.nausch.org: && ssh zielhost.dmz.nausch.org 'cat authorized_keys >> ~/.ssh/authorized_keys'
+=== SSH-Verbindung aufbauen ===
+Nun können wir wie gewohnt eine Verbindung zu unserem entfernten System aufbauen, sofern der GPG-Agent am laufen ist. Wir können dazu entweder erst einmal abfragen, ob dieser gestartet wurde, mit Hilfe des folgenden Aufrufs:
+   $ ps -aux | grep gpg-agent
+  django      1430  0.0  0.0 376092  3636 ?        SLsl 20:32   0:00 /usr/bin/gpg-agent --supervised
+Oder wir fragen einfach den Karten-Status ab, was unweigerlich den Neustart des GPG-Agenten nach sich zieht.
+   $ gpg2 --card-status
+Nun können wir die gewünschte Verbindung zum Zielsystem aufbauen.
+   $ ssh zielhost.dmz.nausch.org
+Da der SSH-Key zur Authentication nicht im Dateisystem liegt, sondern auf der SmartCard des Nitrokey werden wir nun nach der User-PIN gefragt, damit auf den privaten Schlüssel der Karte zugegriffen werden kann.
+{{ :nitrokey:arch:ssh_001.png?nolink&280 |Bild: PIN Abfrage beim Zugriff auf den Authentication Key der SmartCard des Nitrokeys}}
+Der entsperrte Schlüssel der SmartCard des Nitrokey Start wird nun im Speicher gehalten solange wir den USB-Hardwareschlüssel nicht abziehen.
+<WRAP center round important 90%>
+**WICHTIG:** \\
+Da wir den Schlüssel **__nicht__** aus einer Datei geladen hatten, können wir diese auch nicht mit Hilfe von ''**ssh-add**'' wieder entladen! Wollen wir verhindern, dass auf den im Speicher vorgehaltenen Schlüssel zugegriffen wird, müssen wir manuell den GPG-Agenten beenden.
+   $ pkill gpg-agent
+</WRAP>
+Anschliessend lassen sich Verbindungen zu unseren Remote-Systemen erst wieder aufbauen, wenn der GPG-Agent geladen und die Karte nach Eingabe der PIN entsperrt wurde!
+==== Nitrokey Start und Git/Gitlab ====
+<WRAP center round important 90%>
+Git ist an sich kryptographisch sicher, so dass Änderungen sicher nachprüfbar nachverfolgt werden können. Was damit aber noch nicht sichergestellt werden kann, stammt die Änderung auch wirklich von der Person, der wir vertrauen! Git unterstützt hier ein paar Möglichkeiten die Arbeiten an einem Repository zu unterschreiben und auch zu überprüfen.
+</WRAP>
+=== GPG Key-ID ermitteln ===
+Zunächst holen wir uns die Key-ID unseres Users.
+   $ gpg2 -K
+<code>/home/django/.gnupg/pubring.kbx
+-------------------------------
+sec>  ed25519 2024-01-03 [SC]
+C082445CDFB72DECD650350610ED9AEE553353F
+      Card serial no. = FFFE 43243711
+uid           [ultimate] Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>
+ssb>  ed25519 2024-01-03 [A]
+ssb>  cv25519 2024-01-03 [E]</code>
+Die Key-ID unseres Adminusers **''<django@nausch.org>''** lautet also **''610ED9AEE553353F''** (die letzten 16 Stellen reichen hierfür aus).
+=== Git konfigurieren ===
+Nun können wir  Git konfigurieren, damit bei einem Commit Änderungen signiert werden können. Hierzu setzen wir die globale Git Option **''user.signingkey''** - wir setzen diese Option nun auf den zuvor ermittelten Key-ID Wert **''610ED9AEE553353F''**
+   $ git config --global user.signingkey 610ED9AEE553353F!
+Am besten aktivieren wir zusätzlich auch noch die Option, dass automatisch __alle__ Commits automatisch signiert werden.
+   $ git config --local commit.gpgsign true
+=== Unterzeichnung von Commits ===
+Wir sind nun in der Lage einzelne Commits zu unterschreiben, wie in dem nachfolgendem Beispiel. **''git commit -S -m %%"<-%%commit-message%%->"%%''**. Die Option **''-S''** zum Signieren wird jedoch __nur__ benötigt, wenn wir nicht wie zuvor beschrieben, das automatische Signieren der Commits __nicht__ aktiviert wurde!
+<html><pre class="code">
+<font style="color: rgb(25, 100, 5)">✔ </font><font style="color: rgb(196, 160, 0)">~/devel/ansible </font>[<font style="color: rgb(163, 75, 177)">AIDE-19.0 </font>L|<font style="color: rgb(204, 0, 0)">● 6</font>]
+:13 $ git commit -S -m "AIDE 19.0 - auf konfigurierbaren Timer umgestellt"
+[AIDE-19.0 4c03596] AIDE 19.0 - auf konfigurierbaren Timer umgestellt
+files changed, 11 insertions(+), 3 deletions(-)
+</pre>
+</html>
+=== Unterschrift von Commits anzeigen ===
+Zum Anzeigen der Signaturen verwenden wir die Option **''%%--%%show-signature''** beim Befehlsaufruf **''git log''**.
+<html><pre class="code">
+<font style="color: rgb(25, 100, 5)">✔ </font><font style="color: rgb(196, 160, 0)">~/devel/ansible </font>[<font style="color: rgb(163, 75, 177)">AIDE-19.0 </font>L|<font style="color: rgb(25, 100, 5)">✔</font>]
+:01 $ git log --show-signature -1
+<font style="color: rgb(196, 160, 0)">commit 4c035960c07062227aa9e2a4832053e557085484 </font></font><font style="color: rgb(6, 152, 153)">HEAD </font>-> <font style="color: rgb(78, 154, 6">AIDE-19.0</font>, <font style="color: rgb(204, 0, 0)">origin/AIDE-19.0</font>)
+<font style="color: rgb(6, 152, 153)">gpg: Signature made Sun 13 Apr 2025 08:14:51 PM CEST
+gpg:                using EDDSA key 2C082445CDFB72DECD650350610ED9AEE553353F
+gpg: Good signature from "Django (Bastard Operator from Hell [BOfH]) <django@nausch.org>" [ultimate]</font>
+Author: django <django@nausch.org>
+Date:   Sun Apr 13 20:14:51 2025 +0200
+    AIDE 19.0 - auf konfigurierbaren Timer umgestellt
+</pre>
+</html>
+Optional kann man mit der Option **''%G''** beim Aufruf von **''git log''** die Signaturen aller commits prüfen.
+<html><pre class="code">
+<font style="color: rgb(25, 100, 5)">✔ </font><font style="color: rgb(196, 160, 0)">~/devel/ansible </font>[<font style="color: rgb(163, 75, 177)">AIDE-19.0 </font>L|<font style="color: rgb(25, 100, 5)">✔</font>]
+:18 $ git log --pretty="format:%h %G? %aN  %s"
+c03596 G django  AIDE 19.0 - auf konfigurierbaren Timer umgestellt
+f04a39 N Django BOfH  Merge branch 'HIDS0325Logging' into 'main'
+cdff19c N django  Logging nur noch 1x im syslog
+</pre>
+</html>
+Hier sehen wir, dass __**nur**__ der Commit mit der ID **''4c03596''** signiert wurde (gekennzeichnet mit einem **''G''**), die anderen beiden jedoch nicht!
+=== PGP-Public-Key und GitLab ===
+Damit die signierten Commits nun auch in Gitlab überprüft werden können, ist es nötig dass der öffentliche Schlüssel beim Gitlab-Konto hinterlegt wird. Hierzu speichern wir den PGP-Public-Key beim Menüpunkt  **GPG Keys** bei den **User Settings** ab.
+{{ :nitrokey:arch:git_signing_key.png?nolink&900 |Bild: Bildschirmhardcopy Gitlab User Einstellungen - PGP Schlüssel}}
+Bei der Anzeige der Commits in der GitLab Web-UI wird nun mit der Anzeige **Verfied Commit** entsprechend angezeigt, wenn der Commit entsprechend signiert wurde. Somit können wir zweifelsfrei feststellen, dass zum einen der Commit nicht verändert wurde und dass zum anderen der Urheber eben jener verifizierter Admin war|ist.
+{{ :nitrokey:arch:git_signed_commit.png?nolink&900 |Bild: Bildschirmhardcopy Gitlab Sigend Commit}}
+== Zusammenfassung ==
+<WRAP center round tip 90%>
+Ja, Commits oder auch Tags mit einer PGP-Signatur zu versehen, ist sicherlich eine gute und valide Idee. Allerdings nutzt dies wenig wenn nicht alle Beteiligten verstanden und verinnerlicht haben, warum dies in den Standardworkflows zu integrieren und umzusetzen ist. Hierzu ist es wichtig dass zum einen **alle Team-Mitglieder** über einen aktuellen und benutzbaren PGP-Schlüssel verfügen und ihre lokale Git-Umgebung entsprechend konfiguriert haben, dass eben **alle** Commits entsprechend automatisch signiert werden.
+</WRAP>