Automatische Anmeldung auf einem headless Mac, und warum macOS 27 sie überspringt

Ein gemieteter Mac muss einen Neustart allein überstehen. Niemand steht an der Maschine, um ein Passwort einzutippen. Der Browser-Desktop des Kunden hängt an der grafischen Anmeldesitzung, also muss die Maschine angemeldet zurückkommen. Die automatische Anmeldung ohne Bildschirm auf Apple Silicon ist ein kleiner Haufen konkreter Details, und vier davon scheitern still. Eines ist neu in macOS 27. Hier sind sie.

Die zwei Einstellungen, die sie scharf schalten

Die automatische Anmeldung besteht aus zwei Teilen. Eine Einstellung, die den Benutzer nennt, und das Passwort an einer Stelle, die das Anmeldefenster lesen kann.

# who logs in automatically
defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser runner

# the password, XOR-obfuscated, in /etc/kcpassword
# (padded to a multiple of 12 bytes, keyed with a fixed vector)

/etc/kcpassword ist mit einem festen Schlüssel verschleiert, nicht verschlüsselt. Wer die Datei lesen kann, bekommt das Passwort heraus. Das ist nur vertretbar, weil die Maschine nur über ein privates Netz erreichbar ist, nie über das öffentliche Internet. Auf einem Rechner mit offenem Port läge damit ein Passwort offen herum.

Die vier stillen Stopps

FileVault

FileVault verschlüsselt die Festplatte, und sie muss entsperrt sein, bevor macOS jemanden anmelden kann. An einer Maschine mit Tastatur tippt ein Mensch das Passwort ein. Ohne Bildschirm und Tastatur tippt es niemand. Automatische Anmeldung und FileVault schließen sich auf einem Rechner, den Sie nicht anfassen können, also aus. Wir betreiben die Maschinen mit FileVault aus und nutzen das private Netz als Grenze.

Das Flag für die Bildschirmsperre

Es gibt eine Einstellung, die den Bildschirm auch nach der automatischen Anmeldung wieder sperrt. Sie ist für Maschinen gedacht, die beim Ruhezustand des Displays sperren. Ist sie gesetzt, startet die Sitzung, aber der Bildschirm ist gesperrt. Ein entfernter Betrachter sieht dann Schwarz. Wir löschen autoLoginUserScreenLocked jedes Mal, wenn wir die automatische Anmeldung einrichten.

Der Panic-Schlüssel, der uns einen Tag gekostet hat

Der subtile Fall. Scheitert eine Anmeldesitzung, speichert macOS lastLoginPanic in den Einstellungen des Anmeldefensters. Beim nächsten Start überspringt es dann bewusst die automatische Anmeldung und zeigt den Anmeldebildschirm. Das ist eine Schutzfunktion, damit eine Maschine, die bei der Anmeldung abstürzt, nicht in einer Schleife hängt.

Auf einem frisch eingerichteten Mac war der allererste Start damit beschäftigt, eine große Xcode-Kopie zu indexieren, bei einer Load Average über 160. Die Anmeldung wurde nicht rechtzeitig fertig, und der Schlüssel wurde gesetzt. Jeder weitere Start übersprang die automatische Anmeldung, auf einer Maschine, deren Konfiguration völlig korrekt war.

sudo defaults delete /Library/Preferences/com.apple.loginwindow lastLoginPanic
sudo shutdown -r now

Auf einer ruhigen Maschine gelöscht, funktionierte die automatische Anmeldung sofort. Mit demselben Passwort und denselben Einstellungen, die die ganze Zeit gesetzt waren. Fast hätten wir es als Bug in einer neuen macOS-Version gemeldet. Diesmal war es keiner. Der Beweis war eine Gegenprobe: Dasselbe Symptom verschwand, sobald die Maschine nicht mehr überlastet war, und die Konfiguration war nie falsch. Diese Geschichte steht neben den anderen in Prüfungen, die nicht fehlschlagen können.

macOS 27: der Schlüssel bei jedem Start

Dann haben wir unsere ersten M6 minis mit macOS 27 eingerichtet, und der Schlüssel war zurück. Diesmal waren die Maschinen untätig und ruhig. Trotzdem blieben sie nach jedem Neustart am Anmeldefenster stehen, und lastLoginPanic war jedes Mal wieder gesetzt.

Unser Image liefert einen LaunchAgent in /Library/LaunchAgents aus. Er hält einen KI-Coding-Agent in der Sitzung des Kunden am Laufen. Das Skript darin tat ohnehin nichts, solange der Desktop nicht lief. Also verdächtigten wir die Datei, nicht das Skript.

Der Test war eine Gegenprobe. Wir nahmen zwei identische M6-Maschinen im selben Zustand. Eine hatte die plist, eine nicht. Wir starteten sie im Abstand von drei Sekunden neu. Die ohne plist meldete sich an. Die mit plist setzte den Panic-Schlüssel und blieb am Anmeldefenster stehen. Legten wir die plist zurück auf eine Maschine, die sich normal angemeldet hatte, blieb sie beim nächsten Start wieder hängen. Es betrifft also jeden Start, nicht nur den ersten.

Unter macOS 27 lädt das Anmeldefenster LaunchAgents aus /Library/LaunchAgents während des Handshakes der automatischen Anmeldung. Auf unseren Maschinen reichte dieses Laden, um die Anmeldung scheitern zu lassen und den Schlüssel zu setzen. Ihn zu löschen hilft nicht, denn der nächste Start setzt ihn wieder.

# the fix: keep the plist out of the auto-load path
sudo mv /Library/LaunchAgents/dev.example.agent.plist /opt/example/launchd/

# then load it into the user's session after login, from a root daemon
launchctl bootstrap gui/$(id -u runner) /opt/example/launchd/dev.example.agent.plist

Wir haben die plist aus /Library/LaunchAgents verschoben. Ein kleiner LaunchDaemon mit Root-Rechten wartet jetzt, bis die Sitzung des Benutzers existiert und das Dock läuft. Dann lädt er den Agent in diese Sitzung. Die automatische Anmeldung funktioniert bei jedem Start, und der Agent startet etwa eine Minute später.

Zwei weitere Details von macOS 27 haben uns unterwegs erwischt. Erstens sperrt macOS 27 den Bildschirm wenige Sekunden nach der automatischen Anmeldung. Ist er gesperrt, gehört /dev/console root. Prüfen Sie damit also nicht, ob jemand angemeldet ist. Prüfen Sie stattdessen die Domain gui/UID des Benutzers und ein laufendes Dock. Zweitens hängt der Systemassistent für den ersten Start noch an der Sitzung. Beenden Sie ihn, fällt die ganze Sitzung auf das Anmeldefenster zurück, und der Schlüssel wird wieder gesetzt. Unterdrücken Sie ihn über seine Einstellungsschlüssel und beenden Sie ihn nie.

Das funktionierende Rezept