Der Vorfall, der mich zu GPG gebracht hat, fing harmlos an. Ein Kollege rief an, weil ein frisch eingerichteter Webserver auf einmal den SSH-Port auf 22 offen hatte, obwohl in der Rollout-Liste 2222 stand. Der Grund war schnell gefunden: Irgendjemand hatte auf dem Weg vom Test ins Produktivsystem die sshd_config editiert, statt sie zu kopieren. Einen Beweis gab es nicht, denn die Datei hatte keine Signatur. Seitdem gilt in meinen Setups: Jede Konfigurationsdatei, die mehrere Server erreicht, wird signiert. Und wer ein Backup für einen Kollegen verschlüsseln will, braucht dafür keine Zertifikatsstelle, sondern ein Tool, das auf fast jedem Linux schon installiert ist.

GPG leidet unter einem Image-Problem. Die meisten verbinden es mit E-Mail-Verschlüsselung, die in der Praxis kaum jemand nutzt, und mit dem Sammeln von Schlüsseln, die man nie braucht. Dabei ist GPG im Server-Alltag ein wunderbar pragmatisches Werkzeug: Du signierst Dateien, damit andere prüfen können, dass sie wirklich von dir stammen und unverändert sind. Du verschlüsselst Backups für Kollegen, ohne ein gemeinsames Passwort hin- und herzuschicken. Und du verwaltest dabei eine kleine, übersichtliche PKI, die dir gehört. Dieser Artikel zeigt, wie das ohne Drama funktioniert.

Was GPG wirklich ist: ein kleiner Public-Key-Baukasten

GPG steht für GNU Privacy Guard und ist die freie Umsetzung des OpenPGP-Standards. Beim Installieren von Ubuntu, Debian oder Fedora ist es oft schon da; auf einem frischen System reicht ein apt install gnupg. Unter der Haube steckt die gleiche Idee wie bei TLS: ein Schlüsselpaar aus privatem und öffentlichem Schlüssel. Was GPG von der Zertifikatsstelle unterscheidet, ist die Verwaltung: Es gibt keinen zentralen Aussteller, sondern du vertraust Schlüsseln direkt, weil du die Personen dahinter kennst. Für ein Team von fünf Admins ist das perfekt.

Zwei Grundoperationen brauchst du im Alltag wirklich. Beim Signieren beweist du Herkunft und Unversehrtheit: Du hast die Datei erstellt, und niemand hat sie seitdem angefasst. Beim Verschlüsseln sorgst du dafür, dass nur der Empfänger sie lesen kann. Der Unterschied ist wichtig, weil er oft verwechselt wird: Signieren macht Inhalte nicht geheim, Verschlüsseln macht sie nicht authentischer. Ich habe schon Konfigurationen verschlüsselt verschickt, die danach immer noch falsch waren, nur eben geheim falsch.

Warum eine Signatur im Kern ein Hash ist

Hier kommt der Teil, der beim Nachdenken alles erklärt: Eine digitale Signatur verschlüsselt nicht die ganze Datei. Das wäre viel zu langsam und würde riesige Signaturen erzeugen. Stattdessen bildet GPG zuerst einen kryptographischen Hash, einen festen Fingerabdruck der Datei, und signiert nur diesen. Bei einer Datei von 50 Megabyte ist das eine Zeichenkette von 32 Bytes. Der Aufwand ist damit unabhängig von der Dateigröße, und genau das macht Signieren so schnell.

Wenn du also die Signatur prüfst, passiert im Kern Folgendes: GPG berechnet den Hash der vorliegenden Datei neu, entschlüsselt mit dem öffentlichen Schlüssel den Hash aus der Signatur und vergleicht beide. Stimmen sie überein, ist die Datei echt und unverändert. Das ist der gleiche Fingerabdruck, den du mit dem bitcalc Hash-Generator selbst nachrechnen kannst. Wenn du einmal verstanden hast, dass eine Signatur nur ein signierter Hash ist, verstehst du GPG zur Hälfte.

Zwei Abläufe nebeneinander: links Signieren und Verifizieren einer Datei über ihren SHA-256-Hash, rechts Verschlüsseln und Entschlüsseln mit öffentlichem und privatem Schlüssel

Konfigurationsdateien signieren: der Einstieg

Dein erstes Schlüsselpaar erzeugst du mit gpg --generate-key. Das Tool fragt nach deinem Namen, deiner E-Mail-Adresse und einer Passphrase. Die Passphrase schützt deinen privaten Schlüssel, also wähle sie wie ein Passwort: zwanzig zufällige Zeichen aus dem bitcalc Passwort-Generator sind ein guter Anfang. Was dabei entsteht, siehst du dir mit der Keyliste an:

$ gpg --list-keys
/home/admin/.gnupg/pubring.kbx
--------------------------------
pub   rsa3072 2026-10-01 [SC] [verfällt: 2028-10-01]
      4F6A 1C29 8D03 4A72 B7C1  9E2F 3A8B D1C4 77E0 5F21
uid           [ ultimativ ] Roberto Admin <roberto@firma.de>
sub   rsa3072 2026-10-01 [E] [verfällt: 2028-10-01]

Die lange Zeile unter der Key-ID ist der Fingerprint, der vollständige Identifikator deines Schlüssels. Die kurze ID am Ende, hier 77E0 5F21, ist nur ein Abkürzung, die nie für Sicherheitsentscheidungen taugen sollte, denn sie ist kollisionsanfällig. Vergleiche im Zweifel immer den ganzen Fingerprint. Auf einem Server signiere ich jetzt zum Beispiel die sshd_config:

$ gpg --detach-sign --armor sshd_config
$ ls -la sshd_config*
-rw-r--r-- 1 admin admin 1523 19. Okt 08:10 sshd_config
-rw-r--r-- 1 admin admin  844 19. Okt 08:10 sshd_config.asc

--detach-sign erzeugt eine separate Signaturdatei, --armor schreibt sie als Text statt als Binärdaten, damit sie sich leicht per Ticket oder Versionskontrolle übertragen lässt. Das Ergebnis ist eine kleine Datei von ein paar hundert Bytes. Sie enthält nur den signierten Hash, nicht die Konfiguration. Die eigentliche sshd_config bleibt unverschlüsselt lesbar, was für Konfigurationen gewollt ist, denn sie sollen ja auf den Zielsystemen ankommen.

Wenn das Zielsystem die Datei erhalten hat, prüft es sie. Dazu muss der öffentliche Schlüssel des Signierers auf dem Zielsystem importiert sein:

$ gpg --import roberto-pub.asc
$ gpg --verify sshd_config.asc sshd_config
gpg: Signature made Do 19 Okt 2026 08:10:24 CEST
gpg:                using RSA key 4F6A 1C29 8D03 4A72 B7C1 9E2F 3A8B D1C4 77E0 5F21
gpg: Good signature from "Roberto Admin <roberto@firma.de>"

Der Satz Good signature ist die ganze Magie. Er bedeutet: Die Datei, die auf dem Server liegt, hat exakt den Hash, den Roberto am 19. Oktober signiert hat. Daran erkennt ein Rollout-Skript sofort, ob die richtige, freigegebene Version angekommen ist, statt irgendeine Zwischenversion, die jemand unterwegs geändert hat.

Die Warnung, die niemand überspringen sollte

GPG vermerkt es, wenn ein Schlüssel keinem vertrauenswürdigen Ursprung zugeordnet ist. Beim ersten Import eines fremden Schlüssels steht da noch WARNING: This key is not certified with a trusted signature. Das ist keine Panik, sondern eine ehrliche Auskunft: Du hast den Schlüssel bekommen, aber noch nicht verifiziert, dass er wirklich von der Person stammt, für die er sich ausgibt.

Die Lösung ist kein technisches, sondern ein organisatorisches Ritual. Ich vergleiche den Fingerprint immer über einen zweiten Kanal. Wenn ein Kollege seinen Schlüssel per Slack schickt, rufe ich ihn an und lasse mir die ersten sechzehn Zeichen des Fingerprints vorlesen. Bei einem Team-internen Schlüssel genügt ein Gespräch im Büro. Wer den Fingerprint eines neuen Schlüssels per Hash-Generator gegengeprüft hat, kann ihn mit gpg --edit-key und sign sauber bestätigen. Ab dann steht bei deinen Prüfungen ein sauberer Vertrauenspfad.

Backups für Kollegen verschlüsseln

Der zweite Alltagsklassiker: Du willst einem Kollegen ein Backup, einen Datenbank-Dump oder eine Datei mit Zugangsdaten zukommen lassen, aber nicht über einen geteilten Ordner mit einem Passwort, das in drei Chat-Verläufen steht. Hier wird GPG richtig nützlich, denn du verschlüsselst für den öffentlichen Schlüssel des Empfängers, nicht für ein gemeinsames Geheimnis.

$ gpg --encrypt --recipient anna@firma.de --armor backup.sql
$ ls -la backup.sql*
-rw-r--r-- 1 admin admin 88.4M 19. Okt 09:02 backup.sql
-rw-r--r-- 1 admin admin 59.2M 19. Okt 09:02 backup.sql.asc

Was GPG dabei intern macht, ist elegant: Es erzeugt für jede Datei einen frischen, zufälligen Sitzungsschlüssel und verschlüsselt die Daten damit symmetrisch. Diesen Sitzungsschlüssel verschlüsselt es dann mit Annas öffentlichem Schlüssel. So läuft die schwere Kryptografie auf AES-256, während RSA nur einen winzigen Schlüssel schützt. Das ist effizient und hat einen angenehmen Nebeneffekt: Du kannst dieselbe Datei für mehrere Empfänger gleichzeitig verschlüsseln, etwa --recipient anna@firma.de --recipient backup-admin@firma.de, ohne sie mehrfach zu verarbeiten.

Anna entschlüsselt auf ihrem Rechner mit ihrem privaten Schlüssel. Ihre Passphrase fragt GPG ab, dann erscheint der Klartext:

$ gpg --decrypt backup.sql.asc > backup.sql
gpg: encrypted with 3072-bit RSA key, ID 9A04 E71B
gpg: decryption failed: No secret key

Der letzte Fehler ist genau die Stelle, an der viele scheitern. Ich habe die Datei für Annas Schlüssel verschlüsselt, aber auf meinem Rechner liegt nur mein eigener privater Schlüssel. Natürlich kann ich sie nicht öffnen. Das ist kein Bug, sondern das gewünschte Verhalten: Nur der Besitzer des passenden privaten Schlüssels kommt an die Daten. Wenn du eine Datei für dich selbst und einen Kollegen verschlüsseln willst, nimm beide als Empfänger, sonst stehst du selbst vor verschlossener Tür.

Schlüssel verwalten, bevor es weh tut

Nach ein paar Monaten GPG landet auf einem Admin-System schnell mehr als ein Schlüsselpaar. Dann lohnt es sich, ein paar Regeln von Anfang an einzuhalten. Die erste betrifft die Gültigkeit: Vergib jedem Schlüssel ein Ablaufdatum. Standardmäßig erzeugen viele Tools Schlüssel, die nie verfallen, und vergessene Schlüssel sind ein Sicherheitsrisiko, denn ihr privater Teil könnte längst auf irgendeiner alten Platte liegen. Mit gpg --edit-key kannst du eine Gültigkeit setzen und später verlängern, wenn der Schlüssel weiter lebt.

Die zweite Regel betrifft den Verlustfall. Wenn ein Admin das Unternehmen verlässt, hilft kein Löschen, denn sein Schlüssel könnte kopiert sein. Die saubere Antwort ist der Widerruf: Du erzeugst ein Revocations-Zertifikat, das du sofort nach der Schlüsselerzeugung erstellst und an einem sicheren Ort ablegst:

$ gpg --output revoke-4F6A.asc --gen-revoke 4F6A1C298D034A72B7C19E2F3A8BD1C477E05F21
$ # Revocations-Zertifikat ausdrucken und im Tresor ablegen

Damit machst du eine Signatur öffentlich ungültig, ohne Zugriff auf den privaten Schlüssel zu brauchen. Wer das Zertifikat hat, kann den Schlüssel im Ernstfall für ungültig erklären. Im Betrieb verteilst du es am besten auf ein physisches Backup und in den Passwort-Manager, aber niemals nur auf dem Rechner, auf dem auch der private Schlüssel liegt, denn dann bringt es im Verlustfall nichts.

Die dritte Regel ist die wichtigste und am häufigsten missachtete: Sichere den privaten Schlüssel. Ein verlorener privater Schlüssel bedeutet, dass du nichts mehr entschlüsseln kannst, was für dich verschlüsselt wurde, und dass du nichts mehr signieren kannst. Dafür gibt es keinen Wiederherstellungsdienst. Der Export schreibt den Schlüssel in eine geschützte Datei:

$ gpg --export-secret-keys --armor 4F6A1C298D034A72B7C19E2F3A8BD1C477E05F21 > roberto-secret.asc
$ # Diese Datei verschlüsselt in den Tresor, nie in den Klartext-Backup-Ordner

Diese Datei ist ein Schlüssel zum Königreich, denn sie enthält den kompletten privaten Schlüssel. Sie gehört verschlüsselt in den Tresor oder in den Passwort-Manager, nicht in ein Backup-Archiv, das ohnehin jeder lesen kann. Die Passphrase, die den Schlüssel schützt, verwalte ich wie eine Root-Passphrase: im Passwort-Manager, nie auf einem Zettel am Monitor.

Drei Regeln für entspanntes GPG

Aus ein paar Jahren GPG-Betrieb auf Servern sind drei Regeln übrig geblieben, die ich jedem Setup auf den Weg gebe:

  • Fingerprints, nicht Key-IDs: Vergleiche immer den vollen Fingerprint über einen zweiten Kanal. Die kurzen Key-IDs am Ende sind Bequemlichkeit, kein Sicherheitsmerkmal.
  • Secret-Key sichern, bevor du ihn brauchst: Export nach der Erzeugung, verschlüsselt in den Tresor. Verloren heißt unwiderruflich verloren.
  • Signieren und Verschlüsseln getrennt denken: Beides im selben Kommando zu mischen (--sign --encrypt) ist bequem, aber verwirrt bei der Fehlersuche. Teste die beiden Pfade einmal getrennt.

Fazit

GPG ist kein Werkzeug für Paranoia, sondern für Alltagsfragen, die sonst niemand sauber beantwortet: Ist diese Datei wirklich von dir? Liest nur der Empfänger das Backup? Beide Fragen lassen sich mit zwei Kommandos beantworten, sobald man akzeptiert hat, dass eine Signatur im Kern nur ein signierter Hash ist. Genau deshalb passt der Hash-Generator so gut dazu: Wer den Fingerprint einer Datei nachrechnen kann, versteht, was GPG hinter den Kulissen tut.

Der Kollege mit der editierten sshd_config hat seine Lektion gelernt, und ich meine auch. Seitdem signieren wir jede Konfiguration, die ein System verlässt, und verschlüsseln Backups für genau die Personen, die sie lesen dürfen. Das kostet pro Datei eine Sekunde und pro Schlüsselpaar einmal zehn Minuten am Anfang. Dafür weiß heute jeder im Team, dass die Datei auf dem Server genau die ist, die freigegeben wurde. Das ist ein gutes Gefühl, und es braucht keine Zertifikatsstelle, nur einen Schlüssel, der dir gehört.