SSH-Keys sicher aufbewahren

[DrCox1911]

Nachdem ich leider nach wie vor meine SSH-Keys nicht auf meine Yubikeys bekomme, bin ich weiterhin auf der Suche, wie ich meine SSH-Keys sicher aufbewahren kann.

Ich habe etliche Dienste per SSH-Key abgesichert:

1. VPS
2. Lokale Server
3. Github
4. Borgbase

Ich stehe wieder einmal vor einem Neuaufsetzen meines Fedora-Systems und würde die Sicherung gerne erneut anpacken.
Bisher sichere ich die Keys direkt aus dem ~/.ssh Verzeichnis per Urbackup auf meinen Unraid-Server.

Wie legt ihr denn eure SSH-Keys sicher ab?
Eine meiner Überlegungen ist, den SSH-Storage von KeepassXC auszuprobieren. KeepassXC nutze ich bereits für meine Passwörter.
Dabei sind meine KDBX-DBs mit Passwort und Yubikey abgesichert und werden über eine bei Hetzner angemietete Nextcloud synchronisiert.

Könnte daher also meine SSH-Keys indirekt per Yubi absichern.
Würdet ihr dann mit dem Setup SSH-Keys in KeepassXC in einer eigenen KDBX-DB per Passwort und Yubikey abgesichert auch in die Nextcloud packen?

 

[D0m1n4t0r]

Ausdrucken

 

[IBISXI]

Ein online erreichbarer Passwort Safe wäre das richtige dafür.
(Bitwarden, Vaultwarden)

Auch ein Containerbasierter Passwordsafe (Keepass und derivate) wäre gut.

 

[Marco01_809]

SSH-Keys liegen entweder als Datei in ~/.ssh (so wie du es jetzt hast). Diese kann man wahlweise mit einer Passphrase verschlüsseln. Oder sie werden dynamisch über einen SSH-Agent bereitgestellt, dann ist die Speicherung dem Agenten überlassen. Das einfachste wird es sein, die SSH-Agent Funktionalität des Passwortmanagers zu nutzen, dann sind die SSH-Keys so oder so mit der Datenbank zusammen verschlüsselt und man kann bedenkenlos Backups auf weniger sichere Speichermedien machen. Wenn die SSH-Keys verschlüsselt sind kann man die aber auch bedenkenlos woanders hin kopieren.

Bedenke auch dass du bei den Diensten wo du dich mit SSH-Keys authentifizierst in der Regel mehrere SSH Public Keys hinterlegen kannst, d.h. du kannst auch für jedes Gerät eigene Keys anlegen und sobald du das Gerät nicht mehr brauchst die Dateien überschreiben und bei den Diensten entfernen.

 

[Mickey Mouse]

es gibt doch ca. 1000 verschiedene Möglichkeiten (vermutlich mehr ) und jede passt mehr oder weniger gut zu DEINEN Einsatz Gebieten...

und ich werde das Gefühl nicht los, dass hier privat und public key (und passphrase) durcheinander geworfen werden (das ist richtig gefährlich).

 

[DrCox1911]

Ausdrucken

Danke für die Rückmeldung, sollte ich wohl bei den wichtigsten tatsächlich mal in Betracht ziehen.

Auch ein Containerbasierter Passwordsafe (Keepass und derivate) wäre gut.

Habe ich doch schon mit KeepassXC für meine normalen Passwörter.

Das einfachste wird es sein, die SSH-Agent Funktionalität des Passwortmanagers zu nutzen, dann sind die SSH-Keys so oder so mit der Datenbank zusammen verschlüsselt und man kann bedenkenlos Backups auf weniger sichere Speichermedien machen.

Danke, also prinzipiell so, wie ich das mit KeepassXC und dem SSH-Agent aktuell vorgehabt hätte.

und ich werde das Gefühl nicht los, dass hier privat und public key (und passphrase) durcheinander geworfen werden (das ist richtig gefährlich).

Inwiefern? Mir geht es hier nicht um die Passphrase, sondern um den eigentlichen private Key.

 

[IBISXI]

Habe ich doch schon mit KeepassXC für meine normalen Passwörter.

Und was würde nicht passen wenn Du SSH Keys auch dort versenkst?

 

[BeBur]

Du müsstest etwas konkreter definieren, wogegen du die Keys absichern willst, sonst kann man nicht sinnvoll zu einer konkreten Maßnahme raten.

 

[Iqra]

Ich hab das jetzt fünfmal gelesen und bin immer noch nicht sicher was überhaupt der Anspruch ist. 🤔

SSH Keys, insbesondere die private Komponente, sind einfach Schlüsseldateien. Nicht mehr. Nicht weniger. Es geht nicht um proof of knowledge sondern um proof of ownership; habe ich den privaten ssh key, dann darf ich rein, wenn die Gegenseite den zugehörigen pubkey hat.

Wichtig ist daher im Sinne der Absicherung nur eins: Daß sie mir nicht abhanden kommen. SSH private key löschen interessiert keine Sau, dann muß ich halt einen neuen erstellen und muß den zugehörigen pubkey dort verteilen wo halt der bisherige jetzt obsolete ist.

Im Sinne eines Backups sind private ssh keys nicht schützenswert. Klar ist bequemer, wenn ich nicht an X stellen hinlangen muß und da die pub keys neu inpacken muß, aber im Sinne der Sicherheit ist das irrelevant und es läßt sich im Gegenteil sogar argumentieren daß ein gelegentlicher Austausch des key pairs eher die Sicherheit erhöht als mindert. (Ausnahme, ich habe eine Gegenstelle wo SSH key pair die einzig mögliche Authentifizierungsoption ist. Dann muß ich natürlich besser aufpassen.)

=> irgendwo offline sichern wie alles andere auch, keine besonderen Vorkehrungen nötig.
=> und für den regulären Gebrauch eine halbwegs vernünftige Paßphrase haben, für jeden Service auch ein key pair, die üblichen Maßnahmen halt, aber nix "SSH-key-spezifisches" was über "naja, wäre schon schön wenn keiner außer mir den privaten Teil in die Finger kriegen würde".

 

[DrCox1911]

Sorry für meine späte Antwort, lag flach.

Ich hätte meinen Fall wohl besser beschreiben sollen, daher hier nochmal der Grund für meine Frage:
Die abzusichernden SSH-Keys sind die Private-Keys an sich, also nicht die Passphrase sondern der tatsächliche Key.

Warum will ich diese sichern? @Iqra hat ja in seinem Posting schon ein paar Dinge zum Thema Key angesprochen, nur ist es bei mir eben nicht mal einfach so den Public-Key beim entsprechenden Dienst austauschen, da ich z.B. bei meinen Servern ohne den entsprechenden Private-Key gar nicht erst zum Server connecten kann. Ist der Private-Key also futsch, stehe ich ohne Zugang da. Einzige Lösung wäre dann, über das Web-Panel meines Serveranbieters den Server neuaufzusetzen => bin ich nicht gerade scharf drauf.

 

[Marco01_809]

Die meisten Server-Anbieter haben doch auch einen Recovery-Modus oder insbesondere bei vServern die Option von einer beliebigen ISO zu booten. Darüber kann man notfalls auch noch die root-Partition mounten und die .ssh/authorized_keys bearbeiten. Geht natürlich mit Downtime der Services einher.

Wenn die private-keys mit passphrase verschlüsselt sind muss man sich über die sicherheit der backups mMn aber auch nicht so schrecklich viel Gedanken machen... deine Passwort-Datenbank ist doch wahrscheinlich auch nicht mit mehr als einer Passphrase gesichert oder?

 

[Iqra]

Right, wenn es buchstäblich um ein Backup geht, dann ganz einfach wie jede andere Datei auch lokal sichern. Ich unterstelle mal daß es irgendwo ein lokales Backupsystem gibt, welches nicht übers Internet zugänglich ist -- darauf würde ich an der Stelle tatsächlich achten wollen.

Ansonsten, würde ich zumindest erstmal annehmen daß es vom Anbieter auch eine Option gibt, die virtuelle Serverinstanz(en) zumindest als .tgz oä zu sichern und das Archiv dann runterzuladen? Bzw dieses Backup auf ähnlichem Wege zurückzuspielen.

Wenn das NICHT geht, dann kann man auch drüber nachdenken, sich ein zusätzliches "Backup/Restore keypair" anzulegen und den private key davon lokal irgendwo gut geschützt abzulegen.
Entweder mitsamt Passphrase irgendwo in den Schrank, oder ohne Paßphrase in die cold storage.

Wenn dann was sein sollte, kann man das rausholen aus dem Schrank.
Natürlich muß der pubkey dazu immer noch auf dem/den Server(n) installiert werden, wie jeder andere pubkey auch. Aber da kann man zB auch einen dedizierten Account für nehmen. Muß dann aber natürlich auf die Berechtigungen achten und/oder man sudo bedarfsgerecht nutzen kann (und darf!).
Sonst ist man im Ernstfall drauf und "darf" nicht wiederherstellen. Wäre auch doof.

 

[jb_alvarado]

Vielleicht schon etwas alt, aber:

Ich habe mir einen Container mit Luks erstellt, ein kleines Script zum entschlüsseln und Mounten, nach ~/.ssh, geschrieben und in meine .zshrc eingebunden. Beim ersten Öffnen des Terminals bekomme ich nun eine Passwortabfrage und nach Eingabe habe ich ganz normal meine Schlüssel zur Verfügung.

Für mich ist das so optimal, weil ich die Schlüssel eh fast nur im Terminal brauche. Auch brauche ich so nicht das ganze Home Verzeichnis verschlüsseln und habe sensible Daten trotzdem sicher aufbewahrt.

Backup gehst so auch gut, weil nur der Container gesichert werden muss.