Apple: SSH und FileVault

• Bei aktiviertem FileVault ist das Daten-Volume während des macOS-Starts gesperrt
• Die OpenSSH-Konfigurationsdateien werden auf dem Daten-Volume gespeichert, sodass während der Sperre weder bestehende Authentifizierungsmethoden noch Shell-Zugriff verfügbar sind
• Wenn Remote Login (SSH) aktiviert ist, kann das Daten-Volume aus der Ferne über das Netzwerk per Passwort-Authentifizierung entsperrt werden
• Diese Methode erlaubt nicht sofort eine SSH-Sitzung; nach dem Entsperren wird die SSH-Verbindung vorübergehend unterbrochen
• Erst nachdem das Daten-Volume eingehängt und die erforderlichen Dienste gestartet wurden, ist SSH-Zugriff möglich

---

Überblick über Apples Zusammenspiel von SSH und FileVault

• Auf einem macOS mit aktiviertem FileVault ist das Daten-Volume gesperrt, sodass auch nach dem Boot-Zeitpunkt kein Zugriff auf dieses Volume möglich ist
• Da alle systemweiten und kontospezifischen Konfigurationsdateien von OpenSSH innerhalb des Daten-Volumes gespeichert werden, sind im gesperrten Zustand üblicherweise konfigurierte Authentifizierungsmethoden oder Shell-Zugriff deaktiviert

Remote-Entsperrung per Remote Login (SSH)

• Auch wenn das Daten-Volume nach dem Booten noch gesperrt ist, werden bei aktiviertem Remote Login (SSH-Anmeldung) Passwort-Authentifizierungsversuche über das Netzwerk zugelassen
• Nutzer können per SSH aus der Ferne über Passwort-Authentifizierung ein mit FileVault gesperrtes Volume entsperren

Einschränkungen und Ablauf der Entsperrung

• Mit dieser Funktion kann die Sperre des Daten-Volumes aufgehoben werden, aber die SSH-Sitzung wird nicht sofort verbunden
• Unmittelbar nachdem das Daten-Volume entsperrt wurde, wird die SSH-Verbindung kurzzeitig unterbrochen, während macOS das Volume einhängt und die davon abhängigen unterstützenden Dienste startet
• Nach Abschluss dieses Vorgangs können SSH und andere aktivierte Dienste normal genutzt werden

Einführung in macOS 26 Tahoe

• Die Funktion zur Remote-Entsperrung des Daten-Volumes über SSH wurde erstmals in macOS 26 Tahoe eingeführt

[GN⁺]

Hacker-News-Kommentare

• Wenn FileVault aktiviert ist, wird das Daten-Volume gesperrt, und man kann während oder nach dem Booten nicht darauf zugreifen, bis man sich mit dem Account-Passwort authentifiziert. OpenSSH für macOS speichert sowohl systemweite als auch benutzerspezifische Konfigurationsdateien auf dem Daten-Volume. Deshalb sind die normalerweise eingerichteten Authentifizierungsmethoden oder Shell-Zugriffe nicht verfügbar, solange FileVault aktiv gesperrt ist. Wenn jedoch Remote Login aktiviert ist, ist die Passwort-Authentifizierung per SSH in diesem Zustand möglich. Damit kann man das Daten-Volume remote über das Netzwerk entsperren. Die SSH-Sitzung wird dabei nicht direkt fortgesetzt; nach dem Entsperren des Volumes per SSH wird die Verbindung kurz getrennt, während macOS das Volume einhängt und Dienste neu startet. Danach sind SSH (und andere Dienste) wieder normal nutzbar. Eine wirklich erfreuliche Änderung

• Ich frage mich, ob das bedeutet, dass man jetzt nach einem Stromausfall und automatischem Neustart einen vollständig entfernten Mac-mini-Server betreiben kann, ohne physisch eine Tastatur anzuschließen. Wirklich eine großartige Änderung

  • Eigene Tests haben bestätigt, dass es perfekt funktioniert
    1. General > Sharing > Remote Management aktivieren
    2. Nach dem Neustart beim SSH-Login die Meldung sehen: "Dieses System ist gesperrt. Verwenden Sie Benutzername und Passwort zum Entsperren. Danach ist eine normale Anmeldung möglich"
    3. Nach erfolgreicher Authentifizierung per SSH wird die SSH-Verbindung getrennt und die Meldung angezeigt: "System erfolgreich entsperrt. SSH-Anmeldung ist jetzt normal möglich"
    4. Erneut per SSH verbinden, dann kommt man normal hinein
  • Der folgende Befehl kann ebenfalls verwendet werden

    sudo fdesetup authrestart -delayminutes -1
    

    Diese Methode sorgt dafür, dass beim nächsten Neustart genau einmal automatisch mit dem ausgewählten Account angemeldet wird. Das ist praktisch, weil keine Passworteingabe nötig ist, bringt aber ein Sicherheitsrisiko mit sich. Je nach Situation kann das akzeptabel sein
  • Ich frage mich ehrlich, warum man macOS als Server-Betriebssystem wählt. Ich selbst finde die Mac-mini-Hardware auch sehr attraktiv und habe schon darüber nachgedacht. Trotzdem zögere ich, statt macOS lieber Linux darauf laufen zu lassen
  • Ich hatte früher den Fall, dass ein Kollege versehentlich FileVault auf einer CI-Maschine aktiviert hat und ich den Server tatsächlich aus dem Rack ziehen, entstauben, Monitor und Tastatur anschließen und mich dann anmelden und entsperren musste. Jetzt, da Entsperren per SSH möglich ist, könnte ich so etwas beim nächsten Mal direkt remote lösen
  • Ich kenne die Unannehmlichkeit gut, dass ein entfernter Mac mit aktiviertem FileVault nach einem Stromausfall nur mit physischem Login wieder online kommt. Ich frage mich, ob nach dem Neustart auch ein vollständiger Remote-Zugriff per GUI möglich ist. Ich überlege, mir einen Mac mini fürs Homelab zu holen, und denke sogar darüber nach, ob ich dafür ein Remote-Gerät wie KVM brauche

• Ich möchte erwähnen, dass diese Änderung für nicht persönliche Mac-Umgebungen wie in Unternehmen enorm ist. Das Preis-Leistungs-Verhältnis und die Qualität des Mac Mini sind für Automatisierungszwecke ziemlich brauchbar, und auch in echten Firmen wäre der schrittweise Einsatz wohl weiter ausgebaut worden, wenn dieses Problem nicht gewesen wäre. Das FileVault-Problem war ein zentraler Bremsfaktor

  • Ich interessiere mich dafür, Macs als allgemeine Server zu verwenden. Mich würde interessieren, ob es zusätzliche Einstellungen oder Vorgehensweisen gibt, um sie für den Servereinsatz leichter zu verwalten, und ob dort Mac-spezifische Workloads laufen oder auch containerbasierte Linux-Workloads

• Ich freue mich, dass macOS 26 Tahoe die Funktion zum Entsperren des Daten-Volumes per SSH hinzugefügt hat. Nach dem jüngsten Tahoe-Upgrade hatte ich mich gewundert, dass SSH plötzlich unerwartet funktionierte, und jetzt verstehe ich, dass es daran lag. Normalerweise fahre ich meinen Mac nicht herunter, aber manchmal muss ich remote darauf zugreifen und vergesse dann, dass am Vortag ein großes Update installiert wurde. Diese Änderung nimmt mir etwas Sorge

• Ich vermute, das bedeutet, dass auf das System-Volume jetzt keine FileVault-Verschlüsselung mehr angewendet wird. Ich denke das, weil das System-Volume schreibgeschützt ist, feste Inhalte hat und auf allen macOS-Systemen gleich ist. Es klingt auch logisch, dass das System bis zum Netzwerkstart bootet und erst dann die Entsperrung des Daten-Volumes verlangt. Falls FileVault die Verschlüsselung des System-Volumes tatsächlich auslässt, halte ich das für eine sehr vernünftige Änderung. Es wird auch erwähnt, dass mit Overlay-Techniken oft so getan wird, als würde auf die Systempartition geschrieben, obwohl tatsächlich auf das Daten-Volume geschrieben wird

  • Informationen wie WLAN-Passwörter werden ebenfalls auf dem Daten-Volume gespeichert, daher ist Netzwerk nicht zwangsläufig immer verfügbar

• Eine interessante Änderung, aber ich frage mich, ob das Problem mit "Race Conditions" aus grafischen Sitzungen auch für SSH gilt, etwa wenn die Shell auf dem Daten-Volume liegt. Zum Beispiel gab es reale Fälle, in denen beim Neustart mit aktivierter App-Wiederherstellung Anwendungen schon starteten, bevor alle Volumes eingehängt waren, sodass das Starten der Shell scheiterte. Das trat vor allem auf, wenn die Shell mit Nix installiert war. Es scheint gut möglich, dass dasselbe Problem auch bei SSH auftreten könnte. Ich frage mich, ob das systemseitig gelöst wurde

  • Beim Entsperren per SSH wird die Verbindung direkt nach dem Entsperren des Daten-Volumes beendet. Nachdem das Volume vollständig eingehängt ist, verbindet man sich erneut, und dann startet die Shell, daher gibt es dieses Problem nicht. Bei Nutzung des Nix store habe ich das schon mit einem Shim unter Verwendung von wait4path gelöst. Man installiert den Shim vorher an einem bekannten Pfad auf dem Daten-Volume und legt ihn als Login-Shell fest
  • Apple verhindert dieses Problem grundsätzlich, indem nach dem Entsperren des Geräts alle Prozesse beendet werden ("userspace reboot")
  • Ich denke, das lässt sich größtenteils durch erneutes Verbinden lösen. Gerade bei SSH gibt es üblicherweise Mechanismen für Netzwerk-Wiederholungen, daher ist das kein großes Problem
  • Ich denke, dieser Fall lässt sich mit dem seit Langem im OS enthaltenen Utility wait4path lösen

• Ich halte das für eine wirklich erfreuliche Änderung. Wegen dieses fehlenden Features hatte ich FileVault ausgeschaltet

• Ich experimentiere mit der Full Disk Encryption von Omarchy (einer stark meinungsgetriebenen Arch-Konfiguration) und überlege, ob ich es als meine Haupt-VM verwenden kann. Wenn ich physisch davor sitze, habe ich Zugriff auf den GPU-beschleunigten Desktop und auf alle lang laufenden Rechenaufgaben. Wenn ich aber mehrere Wochen entfernt bin und die Maschine neu startet, schreckt mich schon der Umstand ab, dass ich das Festplattenpasswort zwingend physisch eingeben müsste. Es läuft auf ProxMox, aber wegen Einstellungen wie USB-Passthrough ist kein Zugriff über einen Standard-VNC-Viewer möglich. Ich frage mich, ob Omarchy wie macOS einen Remote-Unlock versuchen wird

  • Unter Linux konnte man schon vor sehr langer Zeit Remote-Unlock umsetzen, indem man dropbear in initramfs integriert

• Ich bin sicher, dass es irgendwo einen Angriffsweg für eine Schwachstelle geben wird

  • Abgesehen von den üblichen Sicherheitsrisiken passwortbasierter SSH-Anmeldung fällt mir kein besonderes zusätzliches Risiko ein. Wenn man sich Sorgen macht, dürfte es schon viel helfen, das hinter einer Firewall wie Wireguard zu betreiben. Früher musste man FileVault auf Mac-Servern deaktivieren, daher ist das im Vergleich eine deutlich willkommenere Änderung
  • Nach Erfahrungen mit Sicherheitsproblemen wie Blastdoor gehe ich an solche Änderungen immer vorsichtig heran

• Ich habe einen Mac mini aufgegeben, den ich genau wegen dieses fehlenden Features nicht für mein Homelab verwenden konnte, aber jetzt fühlt es sich so an, als hätte sich alles geändert