© Fernando Gregory / 123RF.com

Sensible Daten legt man nicht im Klartext ab. Wer sie jedoch verschlüsseln möchte, sieht sich bald dem Moloch GnuPG gegenüber. V02enc hält mit einfacher Verschlüsselung, Zugriff per Shell und dem Speichern in Git-Verzeichnissen dagegen.

Wer wie der Autor dieser Zeilen seine ersten Gehversuche mit Linux noch in den 1990ern gemacht hat, erinnert sich ohne Zweifel an die Verehrung, die seinerzeit dem Systemadministrator Root zuteilwurde. So war es – aus guten Gründen – verpönt, auf einem System dauerhaft als root angemeldet zu sein. Die grafische Desktop-Umgebung KDE blendet bis heute eine entsprechende Warnmeldung ein, wagt man es, sich über sie als Root einzuloggen. Andernorts sah man die Sache hingegen nicht so eng: Automatisierung und Orchestrierung waren noch lange kein Thema, und zahlreiche Admins hatten keine Skrupel, sensible Daten wie Passwörter im Klartext im Dateisystem abzulegen.

So galt es nicht immer als Standard, die Passwörter von Systembenutzern verschlüsselt in »/etc/shadow« zu lagern. Eine Anleitung vom März 1996 etwa, das “Linux Shadow Password HOWTO” [1], erläutert, wie Sie Ihr System auf die Verwendung mit Shadow-Passwörtern umstellen. Bis die sich auf allen Linux-Systemen endgültig durchgesetzt hatten, verging noch eine ganze Weile. Das im Jahr 2002 erschienene Debian GNU/Linux “Woody” zum Beispiel fragte während der Installation noch nach, ob man Shadow-Passwörter aktivieren wollte.

Aus heutiger Sicht ist das, nimmt man die verklärende Brille der Sysadmin-Romantik einmal ab, nur noch schwer vorstellbar. Zu Recht gelten Passwörter im Klartext heute als absolutes No-Go. Selbst Dienste wie Postfix, das Passwörter beispielsweise für den eigenen Login an einem SMTP-Relay-Host benötigt, können diese mittlerweile verschlüsselt abspeichern und einlesen. Für die gängigen Werkzeuge der Automatisierungslandschaft wie Ansible oder Puppet stehen zudem leistungsfähige Werkzeuge zur Verfügung, die es erleichtern, Passwörter verschlüsselt abzuspeichern und darauf nur zur Laufzeit zuzugreifen. Im Kontext einfacher Systemsicherheit sieht also alles gut aus, möchte man glauben.

Da passt es nicht so recht ins Bild, dass das Teilen eines sensiblen Inhalts über den Umweg der Kommandozeile und eines Dateisystems außerhalb fertiger Lösungen wie Ansible Vault immer noch wirkt wie eine echte Herkulesaufgabe. In der Realität kommt das gar nicht so selten vor, wie viele vermuten mögen. Angenommen, man ist im eigenen Unternehmen mit der Lösung für das Bare Metal Lifecycle Management von Servern noch nicht so weit, wie man gern wäre, und installiert Server weiterhin per Netboot mit manueller Konfiguration.

Um die IPMI-Schnittstelle der Server einzurichten und darauf per »ipmi« zugreifen zu können, will man im Regelfall die Out-of-Band-Schnittstellen der Systeme mit einem einmaligen Kennwort versehen. Hat man nun 20 Server an der Backe, kommen folgerichtig auch 20 IPMI-Passwörter hinzu. In irgendeiner Form muss man sie den Kollegen bereitstellen, damit die weiter am Setup arbeiten können. Da erhebt sich die Frage, wie man die Kombination aus Benutzername und Passwort für jedes einzelne System mit den anderen teilt. Noch dringender wird diese Frage, möchte man die IPMI-Passwörter in einem zentralen Konfigurationsverzeichnis pflegen sollen, etwa in einem Git-Verzeichnis.

Das rote Tuch

Intuitiv antworten die meisten Admins auf diese Frage mit “GnuPG!”, und im Kern ist das gar nicht so falsch. Sosehr man es aus der Sicherheitsperspektive auch herbeisehnen mag: Im Jahr 2024 wird man zugeben müssen, dass PGP und dessen freie Implementierung GnuPG zwar technisch ganz ordentlich funktionieren, bis heute aber nicht annähernd den wünschenswerten Verbreitungsgrad erreicht haben.

Das beginnt bereits damit, dass GnuPG meist vor allem im E-Mail-Kontext zum Einsatz kommt, sich dann aber nicht problemlos auf jedem Betriebssystem einsetzen lässt. In der Theorie wäre es ein valider Ansatz, die erwähnten IPMI-Passwörter per GnuPG zu verschlüsseln und dann per E-Mail an alle relevanten Kollegen zu versenden. Das setzt jedoch voraus, dass jeder Empfänger nicht nur über ein funktionierendes GPG in seinem E-Mail-Programm verfügt, sondern auch einen eigenen privaten Schlüssel und den öffentlichen Teil des eigenen Schlüssels auf einem für den Sender erreichbaren Keyserver platziert hat.

Zwar lässt sich GnuPG auch auf der Kommandozeile nutzen, um Dateien zu ver- und entschlüsseln. Dann ließe sich sogar das vorher genannte Beispiel mit einem involvierten Git-Verzeichnis in irgendeiner Form abbilden. Komfortabel klappt das mit GnuPG aber nicht, und noch weniger, wenn jeder Mitarbeiter in der Lage sein soll, die verschlüsselte Datei zu verändern. Der müsste die Datei zunächst lokal im Klartext ausgeben, ändern und erneut so verschlüsseln, dass die Schlüssel aller Kollegen mit Zugriff auch tatsächlich Verwendung finden. Vergisst er einen Schlüssel, kann dessen Besitzer trotz prinzipieller Zugriffsrechte die Datei nicht mehr lesen.

Wer das Chaos kennt, das entsteht, wenn mehrere Leute eine LibreOffice-Writer-Datei in einer Nextcloud kollektiv bearbeiten sollen, ahnt, wo das endet. Überdies setzen sich der Erfahrung nach derartige Krückenkonstruktionen lediglich im Ausnahmefall durch. Die Admins finden früher oder später Mittel und Wege, um das System zu umgehen. Andere Lösungen wie das erwähnte Ansible Vault lassen sich zwar einfacher handhaben, benötigen dafür jedoch allerlei Zusatzsoftware und ein separates Setup. Obendrein ermöglichen es einige der Lösungen dann ebenfalls nicht, die verschlüsselten Passwortdateien zusammen mit dem Rest der Konfiguration in einem Git-Verzeichnis abzulegen. In Summe erweist sich die Situation also alles andere als befriedigend.

Bessere Lösungen gefragt

Offensichtlich ist all das auch dem Berliner Entwickler Kevin Niehage aufgefallen. Schon von Berufs wegen befasst er sich viel mit den Themen Sicherheit und Datenschutz. Niehage hatte für das Problem einen ganz konkreten Use Case: Er war nach eigenen Angaben damit beschäftigt, seine eigene IT-Infrastruktur auf den Betrieb in Containern umzubauen. Dabei wollte er in der Lage sein, die zu einem Dienst gehörenden Passwörter und Geheimnisse zusammen mit diesem in Git zu speichern und zu verwalten, und zwar verschlüsselt. Er beschloss, sich des Problems anzunehmen und eine Lösung für das Teilen von sensiblen Daten über den Umweg eines Dateisystems zu bauen. Sie sollte einerseits möglichst portabel und andererseits möglichst einfach in der Bedienung sein.

Ganz bei null anfangen musste Niehage dabei nicht: Im Rahmen der Tätigkeit für seinen früheren Arbeitgeber SysEleven hatte er immerhin zwei Verschlüsselungswerkzeuge namens V00 und V01 entwickelt. Deren ursprüngliche Aufgabe bestand darin, das Teilen temporärer Passwörter über einen HTTP-basierten Dienst zu ermöglichen. Das entsprechende Github-Projekt [2] findet sich in Niehages Account bis heute. Den Dienst [3] selbst können Sie ebenfalls dort abrufen.

Die Idee hinter der Shared-Secrets-Suite ist dabei recht simpel: Legt ein Provider für einen Kunden beispielsweise einen neuen Zugang für eine VPN-Verbindung an, versieht er sie im Normalfall mit einem Einmalpasswort, das er dem Kunden im nächsten Schritt zuschickt. Einmalpasswort heißt das Passwort nicht, weil es nur einmal zum Einsatz kommt, sondern weil der Kunde es beim Anbieter ausschließlich ein einziges Mal abrufen kann. Danach ist er für die sichere Aufbewahrung selbst verantwortlich. Technisch klappt das nur, wenn der Anbieter dem Kunden das Passwort über einen eigens dafür eingerichteten Dienst zur Verfügung stellt. Genau diese Aufgabe löst die von Niehage maßgeblich entwickelte Shared-Secrets-Suite.

Das Konstrukt funktioniert gut: In Form eines eigenen Docker-Containers lässt sich das Werkzeug flott ausrollen und lauscht SSL-geschützt auf der vom Containermanager exponierten Adresse. Danach lässt sich der Dienst zum einen nutzen, um Passwörter von Benutzern entgegenzunehmen, sie dabei zu verschlüsseln und in einer lokalen Datenbank zu speichern. Zum anderen kümmert sich der Dienst darum, berechtigten Nutzern ein geteiltes Passwort einmalig auszuliefern.

Die Datenbank dient vor allem dem Tracking der bereits ausgelieferten Passwörter. Wird ein Link für das Abrufen eines Passworts mehrmals genutzt, erkennt die Shared-Secrets-Suite das und erlaubt so Rückschlüsse darauf, ob die Passwort-Links etwa über den Umweg eines gehackten E-Mail-Accounts in die falschen Hände geraten sind. Dabei nutzt Shared Secrets wie erwähnt zwei verschiedene Algorithmen zur Verschlüsselung: »v00« kommt für die Kommunikation zwischen sendendem Client und Server zum Einsatz, »v01« sorgt für die verschlüsselte Auslieferung des Passworts an den Client.

Dabei greift »v00« ganz klassisch auf symmetrische Verschlüsselung (Abbildung 1) zurück, sodass der Server das ihm zugeschickte Passwort gar nicht sieht, wenn der einsendende Client ein Passwort dafür festlegt (Abbildung 2). Ein Einbruch in den Server mit den Einmalpasswörtern führt insofern auch nicht dazu, dass alle gespeicherten Passwörter als kompromittiert gelten müssen.

Abbildung 1: V02enc geht maßgeblich auf die Erfahrung von Kevin Niehage bei der Entwicklung der Shared-Secrets-Suite zurück.

Abbildung 2: Die Shared-Secrets-Suite nimmt ein Geheimnis entgegen und verschlüsselt es auf Wunsch mit einem Passwort.

Das V01-Format hingegen gewährleistet, dass der für die Ausgabe hin zur Nutzerseite generierte String sämtliche relevanten Parameter in der URL enthält, wenn der einmalige Abruf des Passworts erfolgt. Hierzu zeigt der Server dem Client beim Einsenden des Passworts zunächst einen Link an, über den sich das Passwort erneut abrufen lässt (Abbildung 3). Dabei setzt er auf hybride Verschlüsselung, indem er das Prinzip der symmetrischen Verschlüsselung mit jenem eines Public-Key-Verfahrens kombiniert. Den RSA-Schlüssel für die Abfrage des Geheimnisses generiert der Server dynamisch; er ist Base64-encodiert und Teil der URL zum Abruf des Passworts. Zudem merkt sich der Server den Fingerabdruck des genutzten RSA-Schlüssels für die Entschlüsselung und verhindert so eine erneute spätere Abfrage.

Abbildung 3: Die Shared-Secrets-Suite erzeugt eine URL, die in Base64-Codierung alle nötigen Details für die Entschlüsselung des Passworts enthält. Der Abruf ist nur einmal möglich, weil der Dienst sich den Fingerabdruck des genutzten Schlüssels merkt.

Bei der von SysEleven eingesetzten Version von Shared Secrets handelt es sich um die zweite Version, einen beinahe vollständigen Rewrite aus dem Jahr 2019. Die erste Version des Diensts nutzte unter der Haube noch GnuPG, das man dann aber aus diversen Gründen verwarf. So oder so: Weil er maßgeblich an der Arbeit der Shared-Secrets-Suite beteiligt war, wusste Niehage bald, wie ein alltagstauglicher Mechanismus zum verschlüsselten Ablegen von Passwörtern aussehen muss. Seine Überlegungen kulminierten letztlich in einem Werkzeug namens V02enc.

Grundlagen

Wie so oft in der Open-Source-Welt entstand V02enc, weil Niehage mit bestehenden Lösungen unzufrieden war. Wer sich beispielsweise in der modernen Welt der Container bewegt, ist dem grundlegenden Problem des Speicherns vertraulicher Details in der einen oder anderen Form zweifelsohne bereits begegnet. Auch AGE [4] ist einem dann möglicherweise bereits über den Weg gelaufen.

Das sagte Niehage aus mehreren Gründen nicht zu: Einerseits ist es nämlich unmöglich, bei einer einmal abgelegten AGE-Datei herauszufinden, für welche Anwender sie verschlüsselt wurde. Andererseits funktioniert es bei AGE ebenso wenig, eine verschlüsselte Datei einfach zu aktualisieren. Stattdessen muss man sie praktisch neu anlegen und dabei wieder für dieselben Empfänger verschlüsseln wie die ursprüngliche Datei. Wer die Liste der ursprünglichen Empfänger nicht besitzt, kann AGE-Dateien also praktisch nicht verändern, ohne dabei mit hoher Wahrscheinlichkeit bestehende Nutzer auszuschließen.

Auch die am Markt gleichfalls etablierte Alternative SOPS kommt mit Designschwachstellen daher: Zwar entfällt das Problem der unbekannten Empfänger einer verschlüsselten Datei, weil SOPS dafür pro Datei eine Datei »keys.txt« führt. Wer im selben Repository aber mehrere Dateien für verschiedene Kreise von Empfängern verschlüsseln möchte, sieht sich bald mit einer Flut aus »keys.txt«-Files konfrontiert, was das Handling ausgesprochen unangenehm macht.

Der Entwickler stand also vor der Aufgabe, das Funktionsprinzip des V01-Algorithmus aus seiner Shared-Secrets-Suite nachzuahmen, allerdings mit symmetrischer statt hybrider Verschlüsselung. Das V01-Format diente Niehage als Vorlage: Er veränderte es so, dass es nicht mehr asymmetrische RSA-Schlüssel nutzte, sondern symmetrische Schlüssel etwa aus OpenSSL verwenden konnte. Obendrein erweiterte er die Header des Formats, um beim Entschlüsseln frühzeitig feststellen zu können, ob der Anwender ein korrektes Passwort angegeben hatte oder nicht. Eine Art lokaler Brute-Force-Angriff mit einem Passwort für jeden Empfänger, für den eine Datei verschlüsselt worden war, würde insbesondere bei größeren zu entschlüsselnden Dateien ewig dauern.

Heraus kam nach der Umsetzung dieser Änderungen das Format V02. Niehage stattete es zusätzlich mit mehreren CLI-Werkzeugen aus, darunter »v02enc« und »vim02enc« sowie »git02enc« für die Integration in Git. Den gesamten Quelltext der Werkzeuge finden Sie in Niehages Git-Verzeichnis [5].

V02enc nutzen

Das Verwenden des Werkzeugs geht angenehm unkompliziert von der Hand. Als Abhängigkeit setzt V02enc lediglich PHP 8 voraus. Zunächst beziehen Sie »v02enc« aus Niehages Github-Quellen per »git clone« von der Projekt-URL. Die Installation gestaltet sich etwas hakelig, denn »v02enc« besteht im Wesentlichen aus drei PHP-Dateien, die Sie in einen lokalen Pfad des Dateisystems kopieren und mittels »chmod +x« ausführbar machen müssen. Als Standarddestination bietet sich »/usr/local/bin/« an.

Sobald »v02enc« installiert und ausführbar ist, legen Sie im ersten Schritt eine zufällige Passphrase an (Listing 1, erste Zeile). Sie fungiert im Kontext von V02enc als geheimer Schlüssel. Der angegebene Pfad entspricht dabei jenem, an dem V02enc standardmäßig nach dem zu nutzenden Schlüssel sucht. Möchten Sie den Schlüssel nicht offen im Dateisystem liegen haben, sichern Sie ihn separat mittels eines Passworts ab. Der Quelltext von V02enc enthält eine ausführliche Anleitung dazu. Das zweite Kommando aus Listing 1 (Zeile 2 bis 4) legt im nächsten Schritt eine verschlüsselte Version der Datei »example.txt« unter »example.txt.v02enc« an, wozu es auf den eben erzeugten Secret Key zurückgreift.

$ head -c 32 /dev/random > ~/.v02enc
$ v02enc --encrypt --key ~/.v02enc \
         --input ./example.txt \
         --output ./example.txt.v02enc
$ v02enc --update ./new-text.txt --key ~/.v02enc \
         --input ./example.txt.v02enc \
         --output ./example.txt.v02enc.tmp && \
  mv ./example.txt.v02enc.tmp ./example.txt.v02enc

Möchten Sie eine Datei mit mehreren Keys und damit für mehrere Empfänger verschlüsseln, geben Sie die Option »-k« mehrfach an (Abbildung 4). Das erscheint im ersten Augenblick widersprüchlich, ergibt aber Sinn, wenn man davon ausgeht, dass Nutzer ihre Schlüssel mit einem Passwort schützen. Damit ist es möglich, die verschiedenen Schlüssel in einem zentralen Verzeichnis zu pflegen und beispielsweise mittels Ansible in den jeweiligen persönlichen Verzeichnissen der Anwender auf allen relevanten Systemen auszurollen.

Abbildung 4: V02enc verschlüsselt eine Datei symmetrisch für mehrere Empfänger, was seine Nutzung auf Zielsystemen erheblich erleichtert und es zu einer mächtigeren Alternative zu Werkzeugen wie Vault macht.

Entschlüsselt dann ein Anwender eine Datei, die V02enc auch für seinen Schlüssel verschlüsselt hat, greift das Tool automatisch auf den passenden Schlüssel im persönlichen Ordner des Nutzers zu. Ähnlich unkompliziert funktioniert das Aktualisieren bestehender Dateien. Dazu genügt des letzten Befehls aus Listing 1 (ab Zeile 5).

Gut zu erkennen ist, dass V02enc zunächst eine neue verschlüsselte Datei neuen Inhalts anlegt, sie dann aber im nächsten Schritt heranzieht, um die alte Datei zu überschreiben. Das verspricht in Summe nicht sonderlich viel Komfort. Daher hat V02enc-Autor Niehage sich eine Erleichterung zumindest für Vim-Nutzer ausgedacht: Liegt der eigene Schlüssel an der Standardstelle im Dateisystem und hat der Admin nicht nur »v02enc« installiert, sondern auch »vim02enc«, öffnet das Kommando »vim02enc example.txt.v02enc« die Datei unmittelbar in Vim und speichert sie im Nachgang auch wieder verschlüsselt ab.

Sinnvoll integrieren

V02enc ist explizit für die Nutzung in von Git verwalteten Quelltextverzeichnissen vorgesehen. Dumm nur, dass Git ab Werk von der Existenz von V02enc nichts weiß. Das führt dazu, dass etwa die Ausgabe von »git Duff« nur Binärcode anzeigen würde, wenn sich eine verschlüsselte Datei im lokalen Verzeichnis geändert hat. Doch dafür legt Niehage seinem Werkzeug das Helferlein »v02gitdiff« bei. Damit es funktioniert, muss Colordiff installiert sein. Danach genügt es, die Datei »$HOME/.gitconfig« um die beiden Zeilen aus Listing 2 zu erweitern.

[diff]
external = /Pfad/zu/v02gitdiff

Für ein »git diff« ruft Git danach nicht mehr das klassische Diff auf, sondern V02gitdiff als Wrapper um Colordiff. Dabei entschlüsselt es verschlüsselte Dateien dynamisch und kann dementsprechend die Unterschiede darin anzeigen. Wer V02enc in Kombination mit Git regelmäßig nutzt, freut sich darüber.

Wer stattdessen Mercurial für seine Quelltexte nutzt, findet auch das Werkzeug »v02hgdiff« im Quelltext des Verschlüsselungswerkzeugs. Hier fallen die nötigen Änderungen an der lokalen Konfigurationsdatei »$HOME/.hgrc« allerdings etwas umfangreicher aus, wie Listing 3 zeigt. Auch für das Gespann aus V02enc und Mercurial muss Colordiff installiert sein.

[extensions]
extdiff =
[extdiff]
cmd.v02hgdiff = /Pfad/zu/v02hgdiff
[alias]
diff = !for FILE in $(hg status -n); do hg v02hgdiff "$(hg root)/${FILE}" -o "$(hg root)"; done

MacOS und Keychain

Auch wenn die Zwischenüberschrift im ersten Augenblick etwas absonderlich anmuten mag: Viele Admins und Entwickler, die im Alltag an Linux-Systemen arbeiten, tun das mit Macs. Dafür gibt es durchaus Gründe: Das MacOS zugrunde liegende Darwin ist als BSD-Derivat ein echtes Unix und bietet ab Werk Werkzeuge wie einen ordentlichen Kommandozeileneditor mit einer Bash. Projekte wie Homebrew ermöglichen es zudem, die meisten für Linux zur Verfügung stehenden Werkzeuge auch unter MacOS zu betreiben. Zwar hapert es beispielsweise bei Programmen, die XDarwin und damit die grafische Oberfläche X11 nutzen. Weil die meisten Entwickler aber ohnehin die Kommandozeile oder grafische IDEs bevorzugen, die für MacOS nativ vorliegen, stellt das im Normalfall kein Problem dar.

Auch Niehage scheint zu den Apple-Fans zu gehören. In der Installationsanleitung zu V02enc versteckt sich nämlich ein interessanter Hinweis im Hinblick auf Apples Betriebssystem. Dort gibt es eine systemweite Verwaltung von Passwörtern namens Keychain, in der Anwender selbst Einträge hinterlegen können. V02enc unterstützt Keychain.

Über Listing 4 ließe sich auf der Kommandozeile beispielsweise ein Passwort in Keychain mit der Bezeichnung »lmtest« anlegen (Abbildung 5). Ruft der Nutzer daraufhin V02enc auf, kann er die Bezeichnung »lmtest« über den Parameter »-c« als Argument an V02enc übergeben. Das fischt im Anschluss das entsprechende Passwort aus der Keychain in MacOS und nutzt es als Key für die Verschlüsselung, wobei die in MacOS ohnehin für Keychain vorgesehenen Sicherheits-Features gelten.

$ security add-generic-password -a "$(whoami)" -s "lmtest" -T "" -U \
  -w "$(echo -n "Password: " > &2 && read -s password && \
      echo $password | xxd -p | tr -d "\n")"

Zum Anzeigen des Passworts muss sich der Nutzer durch die Eingabe seines Systempassworts oder mittels Touch ID authentifizieren. Wer mit MacOS arbeitet und V02enc nutzen möchte, findet hier jedenfalls eine erhebliche Erleichterung. Wer das Spiel auf die Spitze treiben möchte, setzt in der Shell einen Alias von »v02enc« auf »v02enc -c Bezeichnung« und sorgt so dafür, dass jeder Aufruf von »v02enc« automatisch den in Keychain hinterlegten Schlüssel übergibt.

Abbildung 5: Für MacOS-Nutzer enthält V02enc eine Integration in Keychain, was das Verwalten des Passworts erheblich sicherer und einfacher macht.

Fazit

V02enc stellt unter Beweis, dass gute Ideen nicht zwangsläufig aus Konzernen kommen müssen und genauso wenig immer Jahre bis zu ihrer erfolgreichen Implementierung benötigen. Ausgehend von seiner Erfahrung im Kontext von Shared Secrets legt Kevin Niehage stattdessen in Form von V02enc ein Werkzeug vor, das Geheimnisse zum Teilen per Kommandozeile sowie zum Abspeichern in Quelltextverzeichnissen denkbar einfach ver- und entschlüsselt. Dass dabei die Möglichkeit besteht, eine Datei für den Zugriff durch mehrere Anwender parallel zu verschlüsseln, erleichtert Teams die Arbeit erheblich, die vor ebendieser Herausforderung stehen.

Zugegeben: Zwar ließe sich ein vergleichbarer Funktionsumfang auch per Ansible Vault implementieren. Das kann es in Sachen Schlankheit mit V02enc allerdings nicht aufnehmen und benötigt zudem deutlich mehr Brimborium, um überhaupt zu funktionieren. V02enc hingegen lässt sich trivial auf allen nötigen Systemen ebenso verteilen wie die Schlüssel der Nutzer, die es verwenden sollen. Werkzeuge wie »vim02enc« und die nahtlose Integration in die Diff-Ansichten von Git und Mercurial sowie die Integration in die Keychain auf MacOS runden das Angebot ab. Suchen Sie eine schlanke Alternative zu Ansible Vault und vergleichbaren Lösungen, sollten Sie sich V02enc definitiv genauer ansehen. (jcb)