Ich habe einen Server mit Debian Buster, dessen Root-Dateisystem istnichtverschlüsselt, andere Laufwerke jedoch schon.
[Voraussichtliche Ankunftszeit:Alle Systemverzeichnisse des Betriebssystems ( /var, /home, /etc, usw.) liegen in der unverschlüsselten Root-Partition. Der Swap-Speicher ist verschlüsselt, wird aber bei jedem Booten nicht-interaktiv mit einem neuen, zufälligen Schlüssel erstellt, sodass nichts durch das Warten darauf aufgehalten wird.]
Ich habe Einträge in /etc/crypttab und /etc/fstab zum Entschlüsseln und Mounten der verschlüsselten „Speicher“-Laufwerke und der Boot-Prozess wartet unbegrenzt auf die Passphrase für die kleine verschlüsselte Partition, die die Schlüsseldateien zum Entschlüsseln der anderen Laufwerke enthält. So weit, so gut. Die Passphrase-Eingabeaufforderung erscheint auf einem physisch angeschlossenen Monitor, ich gebe die Passphrase mit einer physisch angeschlossenen Tastatur ein und der Boot-Vorgang wird fortgesetzt. Ich habe den OpenSSH-Daemon installiert und verwende Public-Key-Authentifizierung, um mich nach dem Booten für alle möglichen Verwaltungsaufgaben mit dem Server zu verbinden.
Jetzt möchte ich diese LUKS-Geräte per SSH remote entsperren können. Da rootnichteines der verschlüsselten Dateisysteme, ich sehe keine Notwendigkeit für die ganze „Dropbear+Busybox in Initramfs“-Geschichte, und ich dachte, das wäre relativ unkompliziert.
sudo systemctl edit ssh.serviceund füge die folgenden Zeilen hinzu:
[Unit]
Before=cryptsetup-pre.target
[Install]
WantedBy=cryptsetup-pre.target
Dadurch sollte systemd die Dinge neu organisieren und sshd starten, bevor mit der Entschlüsselung lokaler Festplatten begonnen wird, oder? (Ich habe WantedByanstelle von gewählt RequiredBy, weil ich nicht möchte, dass systemd Cryptsetup „fehlschlägt“, wenn sshd nicht wie erwartet startet.)
sudo systemctl daemon-reloadbeschwert sich nicht und cat /etc/systemd/system/ssh.service.d/override.confzeigt diese vier Zeilen wie erwartet an. Beim Neustart erscheint (wie erwartet) die Passphrase-Eingabeaufforderung, aber alle Versuche, sich per SSH beim Server anzumelden, werden mit zurückgegeben No route to host, also wurde ssh.service offensichtlich nicht zuerst gestartet.
Ich habe versucht, die Überschreibung zu ändern, um anzugeben, dass ssh WantedBy ist und stattdessen vor der von systemd generierten [email protected]Einheit steht. Interessanterweise führte dies dazu, dass kein sshUndkeine Passphrase-Eingabeaufforderung, also blieb der Bootvorgang einfach ewig hängen und ich musste von einem Wiederherstellungsmedium booten und die Überschreibung entfernen. Das ist nicht gerade hilfreich, aber es hatte zumindest einen beobachtbaren Effekt. Vielleicht habe ich irgendwo eine zirkuläre Abhängigkeit geschaffen? Die Passphrase-Eingabeaufforderung scheint tatsächlich zu kommenWirklichfrüh in der Startreihenfolge.
Was sind hier meine nächsten Schritte? Ist es möglich, die von systemd generierte Cryptsetup-Einheit zu überschreiben, um sie Wants=und After=Links zu ssh.serviceübergeben? Wenn dies möglich ist, gibt es einen Grund zu der Annahme, dass dies zu besseren Ergebnissen führen würde? Wäre es sinnvoll, meine eigenen Einheiten unter /etc/ für diese Keystore-Partition zu schreiben und die entsprechenden inittab- und fstab-Einträge zu entfernen? Kurz gesagt, gibt es irgendeinen halbwegs vernünftigen Weg, dies zum Laufen zu bringen, oder sollte ich diesen Weg aufgeben und doch Dropbear+Busybox in Initramfs verwenden?
PS. Ich habe darüber nachgedacht, die verschlüsselten Laufwerke einfach auf „noauto“ zu setzen, aber ich habe VMs auf diesen Festplatten so konfiguriert, dass sie später im Startvorgang automatisch gestartet werden. Daher würde ich lieber eine funktionierende Remote-Entsperrung einrichten.
Antwort1
Die Verwendung von cryptsetup.targetoder cryptsetup-pre.targethat bei mir nicht funktioniert, aber ich weiß nicht, warum.
Es hat funktioniert, ein Overlay zu erstellen für [email protected]:
# /etc/systemd/system/[email protected]/myservice.conf
[Unit]
Wants=myservice.service
After=myservice.service