Seiten: [1] 
|
 |
|
|
Autor
|
Thema: SSH-Keys sicher mit KeepassXC aufbewahren (Gelesen 132 mal)
|
|
Sebastian
Sr. Member
 Offline
Einträge: 487
|
 |
SSH-Keys sicher mit KeepassXC aufbewahren
« am: 15. November 2024, 12:05:22 »
|
|
Vorwort
Hallo Suletuxe,
Vorab, dies wird kein Tutorial sein, das direkt zum Ziel führt. Dies wird vielleicht später in unserem Wiki einen Platz finden. Da ich im Wiki bis jetzt Quasi (Andreas ausgenommen) der einzigeste Contributor bin. Weis ich noch nicht wirklich ob sich die mühe für mich lohnt (Spass macht es auf jeden fall nicht nur der Einzige zu sein, der das Wiki mit Inhalt füllt.)
Deswegen werde ich eher dies hier so erzählen, wie meine Erfahrungen waren, bis ich meine SSH Keys aus KeepassXC heraus bequem verwenden konnte. Da ich keine vollständige Desktopumgebung und lediglich den i3 Window Manager im Einsatz habe, gibt es hier gezwungenermaßen mehr Konfigurationsarbeiten zu tun, da nicht alles Out of the Box sofort funktioniert. Dafür habe ich aber Wiedereinmal mehr mein Horizont im Umgang mit Linux erweitern können. Und genau das ist es was ich an Linux so toll finde, es gibt immer wieder etwas neues zu lernen. Dann lasst uns mal Anfangen.
FAQ
Denn Passwordmanager KeepassXC muss ich glaube hier nicht weiter erläutern, diesen werden die meisten schon kennen.
Aber warum sollte man jetzt in seiner Password Datenbank auch noch SSH Keys aufbewahren und nicht nur Kennwörter?
Die Antwort darauf ist simple und einleuchtend. Um eure SSH Keys vor unbefugten Zugang zu schützen.
Aber ich habe meine SSH Keys doch sowieso mit einem Passwort geschützt, warum sollte ich also diesen noch mehr schützen?
Ganz einfach, selbst wenn ihr eure privaten SSH Keys mit einem Passwort geschützt habt, so verhält es sich wie überall anderes auch. Ihr solltet eure SSH Keys mit unterschiedlichen Passwörtern schützen (alles andere wäre schlechte Praxis). Und wo habt ihr euere Passwörter gespeichert? Richtig in euren Passwortmanager also kann dieser eigentlich auch dafür genutzt werden, um eure SSH Keys zu entschlüsseln. Zudem habt ihr so, auch einen sicheren Transport 'Weg für eure Privaten SSH Keys geschaffen, den diese reisen nun immer mit eurer Passwortdatenbank mit. Somit könnt ihr z.B. eure Datenbank auf einem USB-Stick verwahren und seid nicht dem dauerhaften Risiko ausgesetzt, dass eure Datenbank per Remote jederzeit entwendet werden könnte.
Vorbereitungen
SSH-Agent
Damit SSH Keys mit KeepassXC auch bequem genutzt werden können, müssen ein paar Vorbereitungen getroffen werden. Denn KeepassXC wird die Entschlüsselten privaten SSH Keys an einen SSH-Agenten übergeben. Damit dieser bei einem SSH Handshake den Schlüssel zum Signieren der mitgeteilten Massage zur Authentifizierung nutzen kann. Dafür muss aber auch ein SSH-Agent auf eurem System laufen, den KeepassXC auch nutzen kann.
In den meisten Fällen starten gängige Desktopumgebung so einen SSH-Agenten bereits im Hintergrund, sodass dieser einfach schon genutzt werden kann. In meinen Fall mit einem einfach Window Manager passierte das natürlich nicht also musste ich hier abhilfe schaffen.
Dank des Arch-Wikis wurde ich aber darüber in Kenntnis gesetzt, dass seid der Version 9.4p1-3 des openssh Pakets ein Systemd service enthalten ist, der einen SSH-Agenten startet. Also diesen Service im User Scope schnell gestartet und schon hatte ich einen laufenden SSH-Agenten. Der auf $XDG_RUNTIME_DIR/ssh-agent.socket lauscht.
systemctl --user enable --now ssh-agent.service
|
|
❯ systemctl --user status ssh-agent.service
● ssh-agent.service - OpenSSH key agent
Loaded: loaded (/usr/lib/systemd/user/ssh-agent.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-11-15 11:25:13 CET; 47min ago
Invocation: 1166d5693a8a43d78d7add38dbec77a4
Docs: man:ssh-agent(1)
man:ssh-add(1)
man:ssh(1)
Main PID: 967 (ssh-agent)
Tasks: 1 (limit: 9387)
Memory: 1.3M (peak: 1.6M)
CPU: 11ms
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/ssh-agent.service
└─967 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket
Nov 15 11:25:13 NB-FUJITSU ssh-agent[967]: SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket; export SSH_AUTH_SOCK;
Nov 15 11:25:13 NB-FUJITSU ssh-agent[967]: echo Agent pid 967;
Nov 15 11:25:13 NB-FUJITSU systemd[958]: Started OpenSSH key agent.
|
|
SSH_AUTH_SOCK Umgebungsvariable setzten
Nun hatte ich also einen laufenden SSH-Agenten der unten den oben angebenden Socket ansprechbar war, aber meine Umgebung und damit meine Anwendungen wie auch KeepassXC wissen davon noch nichts. Da die SSH_AUTH_SOCK Umgebungsvariable in meiner User Session noch nirgends gesetzt worden war. Ich hätte es mir an dieser Stelle einfach machen können und in KeepassXC den Pfad zum Socket des SSH-Agenten einfach einstellen können. Aber dann hätte nur KeepassXC diesen auch nutzen können, und ich möchte diesen vielleicht auch noch für andere Anwendungen mit verwenden können.
Also habe ich wieder das Arch-Wiki konsultiert wie ich eine Umgebungsvariable im Benutzerkontext auf einer grafischen Umgebung nutzbar machen konnte. Wichtig ist hier das diese Variable im Benutzerkontext genutzt werden soll. Da nicht alle Systemnutzer den gleichen SSH-Agenten ansprechen sollen. Ich bin zwar der einzige Nutzer des Systems. Aber wenn, dann sollte man es auch gleich richtig machen.
Also in diesem Wiki Artikel nachgeschlagen das Anscheint mein Display Manager (LightDM) einer derjenigen ist, der die ~/.bashrc Datei beim Login einließt.
Somit habe ich in der ~/.bashrc einfach die Umgebungsvariable bekannt gegeben:
export SSH_AUTH_SOCK=${XDG_RUNTIME_DIR}/ssh-agent.socket
|
|
Neu eingeloggt und mit
geprüft ob die Variable auch gesetzt wurde. Und.... nichts 
Was ist hier los dachte ich? Wo ist der Fehler? Es sollte doch eigentlich funktionieren.
Kurz und kanpp, da haben mich die Entwickler von EOS ganz schön getrollt. Denn diese haben ganz weit oben in der tt]~/.bashrc[/tt] folgende Zeile Code eingefügt:
....
# If not running interactively, don't do anything
[[ $- != *i* ]] && return
....
|
|
Ja vielen dank auch  ist also klar das meine Variable die ich weiter unten deklariert habe also gar nicht gelesen wird. Also die Deklartion der Variable darüber vorgenommen und tada es funktionierte
KeePassXC
SSH-Agent Unterstützung aktivieren
Da nun alle Vorbereitungen getroffen waren, konnte ich nun die SSH-Agent Unterstützung in KeepassXC aktivieren. Diese findet man unter folgendem Pfad:
Werkzeuge -> Einstellungen -> SSH-Agenten -> SSH-Agenten-Intergartion aktivieren
|
|
Sofort sprang die Leuchte auf grün. Da KeepassXC erfolgreich zu meinen SSH-Agenten über den Socket /run/user/1000/ssh-agent.socket aufnehmen konnte.
Private SSH-Keys nach KeepassXC übertragen
Im Grunde werden SSH-Keys in KeepassXC wie normale Passwort Einträge behandelt. Es wird bei solch einen Eintrag der Key nur als Anhang hinterlegt. Und KeepassXC mitgeteilt welcher der Anhänge der SSH Key ist.
Anmerkung:
Da ich meine Passwörter für meine SSH-Keys mir nun nicht mehr merken musste. Habe ich die Passwortstärke meiner SSH Keys auf 128 Zeichen im Vorfeld mit ssh-keygen erhöht. Bevor ich diese in KeepassXC importiert habe.
|
|
Also einfach einen neuen Passworteintrag in KeepassXC angelegt. Dort das Passwort für den SSH Schlüssel vergeben (Dies nutzt KeepassXC auch um den Schlüssel zu Entschlüsseln). Unter Fortgeschritten den Privaten SSH-Key hinterlegt.
Und unter SSH-Agent den Privaten Schlüssel unter Anhang angeben welcher genutzt werden soll. Zudem habe ich noch folgende Punkte aus kompfor gründen aktiviert:
- Schlüssel vom Agenten entfernen, wenn Datenbank geschlossen/gesperrt wird.
- Schlüssel vom Agenten Entfernen nach 600 Sekunden
Eintrag Abgespeichert, und mit STRG+H getestet ob, KeepassXC meinen Schlüssel dem Agenten hinzugefügt hat.
Dieses konnte ich mit
Verifizieren.
Schlusswort
Ich freue mich nun also, das ich meine SSH-Keys nun noch bequemer aber vor allem sicherer nutzten kann. Da ich diese nun auch nicht mehr auf meinen Rechner gespeichert haben muss und diese auch im Notfall mit mir führen kann.
Aber was mich am meisten Freud das ich durch diese kleine Sache wieder eine Menge beim Thema SSH Key Verwaltung lernen konnte. Und ich mich jetzt auch mit den Umgang mit einen SSH-Agent viel sicherer fülle, da dies nun keine Blackbox mehr für mich ist.
Ich hoffe das der ein oder andere dies auch Interessant fand und vielleicht auch ein paar Dinge hier mitnehmen konnte.
Über Feedback würde ich mich hier sehr freuen.
Wie Verwaltet ihr eure SSH-Keys den überhaupt?
Habt ihr noch eine andere Methode?
Nutzt ihr KeePassXC in Zukunft auch für die SSH Schlüssel Verwaltung?
Lasst es mich gerne wissen 
Hoffentlich lesen wir uns hier bald 
LG
Sebastian
|
| « Letzte Änderung: 16. November 2024, 12:04:00 von Sebastian » |
 Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:SSH-Keys sicher mit KeepassXC aufbewahren
« Antwort #1 am: 16. November 2024, 11:56:43 »
|
|
Hallo Sebastian,
da bei uns alle eine Desktopumgebung am Laufen haben (über 80% den KDE/Plasma denke ich) ist die Verwaltung und Anwendung der SSH-Keys out-of-the-box konfiguriert und läuft sofort, sowie man Schlüssel erstellt / benutzt. Ich denke aber, dass auch nicht allzu viele solche Schlüssel benutzen, oder wissen, was das ist. Ich hatte es zwar schon ein paarmal auf den Treffen erklärt, aber nicht alle waren anwesend bzw. haben das noch in Erinnerung.
Zusätzlich denke ich, dass niemand außer uns beiden weiß, was der Unterschied zwischen einer Desktopumgebung und einem Windowmanager ist, und niemand sich die Mühe machen wollte / würde, sich einen Windowmanager auf seine Bedürfnisse hin zu konfigurieren. Selbst ich habe niemals daran gedacht und nutze lieber den Komfort des KDE/Plasma...
Kmail kann auf jeden Fall sofort mit signierten und / oder verschlüsselten Mails umgehen und holt fehlende Schlüssel via WKD (falls vom versendenden Mailserver unterstützt). Da braucht man nichts mehr konfigurieren, Im Hintergrund läuft unter anderem gnupg, und für die Schlüsselverwaltung kann man zwischen KGPG und Kleopatra wählen, was einem besser gefällt.
Selbstverständlich geht es auch mit einem Windowmanager, wie deine Beschreibung eindrucksvoll zeigt. Sie zeigt auch, dass man sich mit solchen Kenntnissen eine eigene "Desktopumgebung" auf einem Windowmanager aufbauen kann, die nur man selbst hat und sonst niemand
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 487
|
|
Re:SSH-Keys sicher mit KeepassXC aufbewahren
« Antwort #2 am: 16. November 2024, 12:30:06 »
|
|
Hallo Anderas,
Ja ich weiß, dass ich mit einem Window-Manager sehr speziell bin. Mein Ziel dieses Post ist es aber auch eher aufzuzeigen, welche Abläufe bzw. welche Vorarbeiten im Hintergrund getroffen werden müssen, die einem eine Desktopumgebung von vornherein abnimmt. Ich möchte damit jetzt auch nicht sagen, dass jetzt doch lieber alle einen Window-Manager benutzen sollen, sondern nur dass wenn auf den Komfort verzichtet wird (so wie ich), gezwungen wird sich mit den Dingen genauer/intensiver auseinander zu setzten und somit dabei viel lernen kann.
Ich hoffe so, dass damit vielleicht auch den Usern, die eine Desktopumgebung verwenden, vielleicht besser verstehen, was auf ihrem System in diesem Bezug alles im Hintergrund passiert. Was dann wiederum dazuführt, besser ein Problem zu lokalisieren, falls man diesmal haben sollte. Da man dann die Stellen kennt, die man Prüfen sollte. Wer wie viel aus meiner Erfahrung mitnimmt, ist jedem selbst überlassen.
PS;
Was Kmail anbelangt, PGP Keys (für E-Mail-Verschlüsselung) und SSH Keys (Zur SSH Login Authentifizierung) sind zwei unterschiedliche Dinge. Zwar hat gnupgp auch einen SSH Agent und kann glaube auch SSH Keys erzeugen, aber beide Key Sorten entsprechen einen anderen Standard und auch einen anderen Anwendungszweck. Das wäre dann wie Äpfel mit Birnen vergleichen, auch wenn sich beide Key Sorten die gleichen Verschlüsselungsalgorithmen teilen können.
PPS:
Ich habe ja immer noch die Hoffnung, dass vielleicht jemand (auch wenn er es nicht brauch) nur vielleicht aus Interesse mal ein paar Dinge hier und da nachfragt. Und wenn es nur Fragen sind, weil vielleicht etwas nicht verstanden wurde. Nur alleine, damit überhaupt mal eine Diskussion zustande kommt. Man kann sich ja gegenseitig befruchten.
LG
Sebastian
|
| « Letzte Änderung: 16. November 2024, 12:40:55 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:SSH-Keys sicher mit KeepassXC aufbewahren
« Antwort #3 am: 16. November 2024, 12:48:36 »
|
|
Secured Shell Keys wird außer uns beiden niemand brauchen - da bin ich mir sicher. Deswegen bin ich auf die "bekannteren Brüder" - die GPG-Keys - eingegangen...
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 487
|
|
Re:SSH-Keys sicher mit KeepassXC aufbewahren
« Antwort #4 am: 19. November 2024, 10:57:28 »
|
|
Nachtrag:
Ich habe bei meinem System später noch festgestellt das ein Socket für die gcr (GNOME Crypto Runtime) auf $XDG_RUNTIME_DIR/gcr/ssh am Lauschen ist.
Nach Recherche was das ist und warum ich das habe, kam ich dabei zu folge dem Ergebnis:
Was ist gcr?
GCR bietet eine Bibliothek für kryptografische Benutzeroberflächen und Parsing, die von verschiedenen GNOME-Anwendungen verwendet wird.
|
|
Warum habe ich das? Ich habe doch keinen Gnome Desktop!
Dafür musste ich mein System erst einmal ein wenig genauer durchleuchten:
pacman -Qs gcr
local/gcr-4 4.3.0-1
A library for bits of crypto UI and parsing
...
|
|
❯ pacman -Qi gcr-4
Name : gcr-4
Version : 4.3.0-1
Beschreibung : A library for bits of crypto UI and parsing
Architektur : x86_64
URL : https://gitlab.gnome.org/GNOME/gcr
Lizenzen : LGPL-2.1-or-later
Gruppen : Nichts
Stellt bereit : libgck-2.so=2-64 libgcr-4.so=4-64
Hängt ab von : glib2 glibc gnutls libp11-kit libsecret openssh systemd-libs
Optionale Abhängigkeiten : gtk4: gcr-viewer-gtk4 [Installiert]
Benötigt von : gvfs libnma-common
Optional für : Nichts
In Konflikt mit : Nichts
Ersetzt : Nichts
Installationsgröße : 2,85 MiB
Packer : Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Erstellt am : Mi 12 Jun 2024 00:49:17 CEST
Installiert am : Do 13 Jun 2024 14:23:01 CEST
Installationsgrund : Installiert als Abhängigkeit eines anderen Pakets
Installations-Skript : Nein
Verifiziert durch : Signatur
|
|
Ah deswegen habe ich das also, da ich das Paket gvfs für das Mounten unterschiedlicher Dateisysteme im User Kontext installiert habe.
Also dachte ich mir ok, wenn der Socket eh schon läuft. Und wahrscheinlich dafür schon ein paar Dinge voreingestellt sind, dann deaktiviere ich den Service für den ssh-agenten wieder und lasse meine SSH_AUTH_SOCK Umgebungsvariable lieber auf $XDG_RUNTIME_DIR/gcr/ssh zeigen:
systemctr --user disable ssh-agent.service
|
|
in der ~/.bashrc:
export SSH_AUTH_SOCK=${XDG_RUNTIME_DIR}/gcr/ssh
|
|
gesagt, getan und neu eingeloggt. Mit
geprüft ob der SSH-Agent leer ist. War er aber nicht
Es wurden alle meine unverschlüsselten Keys beim Login in den Agent geladen. Warum das so ist, habe ich eine Vermutung:
❯ systemctl --user cat gcr-ssh-agent.service
# /usr/lib/systemd/user/gcr-ssh-agent.service
[Unit]
Description=GCR ssh-agent wrapper
Requires=gcr-ssh-agent.socket
[Service]
Type=simple
StandardError=journal
Environment=SSH_AUTH_SOCK=%t/gcr/ssh
ExecStart=/usr/lib/gcr-ssh-agent --base-dir %t/gcr
Restart=on-failure
[Install]
Also=gcr-ssh-agent.socket
WantedBy=default.target
|
|
Ich vermute da die ELF gcr-ssh-agent ein Wrapper für den OpenSSH Agent ist das diese einfach stumpf ssh-add aufruft. Wovon dort wieder im Handbuch drin steht das:
...
ssh-add adds private key identities to the authentication agent, ssh-agent(1). When run without arguments, it adds the files ~/.ssh/id_rsa,│
~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519_sk.
...
|
|
Hierdurch werden alle Keys, die im Standardpfad liegen, zum SSH-Agent hinzugefügt. Getestet, indem ich den Dateinamen meiner Keys ändere und wolla, diese werden nicht mehr beim Login automatisch hinzugefügt.
Somit habe ich wieder ein Stück mehr mein System kennengelernt. Und es verblüfft mich immer wieder, wie transparent Linux ist.
PS:
Dies ist ein weiterer Post, für diejenigen die es auch so brennent interessiert zu wissen wie die Dinge alle zusammenhängen und ineeinander greifen. Jeder darf hiervon nur das für sich mitnehmen, dass er auch brauch und den rest ruhig ignorieren, wer dies nicht benötigt oder nicht wissen möchte.
Ich für meinen Teil finde es sehr aufschlussreich zu wissen wie die Dinge ineinandergreifen.
LG
Sebastian
|
|
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
