L’ouverture de session automatique sur un Mac sans écran, et pourquoi macOS 27 la saute

Un Mac loué doit survivre seul à un redémarrage. Personne ne se tient devant la machine pour taper un mot de passe. Le bureau dans le navigateur du client s’attache à la session graphique. La machine doit donc revenir avec une session ouverte. L’ouverture de session automatique sans écran sur Apple Silicon tient à une petite pile de détails précis, et quatre d’entre eux échouent sans bruit. L’un est nouveau dans macOS 27. Les voici.

Les deux réglages qui l’activent

L’ouverture de session automatique tient en deux éléments. Une préférence qui nomme l’utilisateur, et le mot de passe stocké là où la fenêtre de connexion peut le lire.

# 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 est masqué avec une clé fixe, pas chiffré. Quiconque peut lire le fichier peut retrouver le mot de passe. C’est acceptable uniquement parce que la machine n’est joignable que par un réseau privé, jamais par l’internet public. Sur une machine avec un port ouvert, ce serait un identifiant laissé à la vue de tous.

Les quatre blocages silencieux

FileVault

FileVault chiffre le disque, et le disque doit être déverrouillé avant que macOS puisse ouvrir une session. Sur une machine avec un clavier, un humain tape le déverrouillage. Sans écran, personne ne peut le taper. L’ouverture de session automatique et FileVault s’excluent donc sur une machine que vous ne pouvez pas toucher. Nous tournons avec FileVault désactivé, et nous comptons sur le réseau privé comme frontière.

Le drapeau de verrouillage de l’écran

Une préférence reverrouille l’écran même après l’ouverture de session automatique. Elle est prévue pour les machines qui se verrouillent quand l’écran se met en veille. Si elle est active, la session s’ouvre mais l’écran est verrouillé, ce qu’un observateur à distance voit en noir. Nous effaçons autoLoginUserScreenLocked chaque fois que nous activons l’ouverture de session automatique.

Le verrou de panique, qui nous a coûté une journée

Le plus subtil. Quand une ouverture de session échoue, macOS enregistre lastLoginPanic dans les préférences de la fenêtre de connexion. Il saute alors volontairement l’ouverture automatique au démarrage suivant et affiche l’écran de connexion à la place. C’est une sécurité, pour qu’une machine qui plante à l’ouverture de session ne tourne pas en boucle.

Sur un Mac fraîchement intégré, le tout premier démarrage était occupé à indexer une grosse copie de Xcode, avec une charge moyenne au-dessus de 160. L’ouverture de session ne s’est pas terminée à temps, et le verrou a été activé. Chaque démarrage suivant a sauté l’ouverture automatique, sur une machine dont la configuration était parfaitement correcte.

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

Une fois le verrou effacé sur une machine au calme, l’ouverture automatique a marché tout de suite, avec le même mot de passe et les mêmes réglages qu’avant. Nous avons failli signaler cela comme un bug d’une nouvelle version de macOS. Cette fois-là, ce n’en était pas un. La preuve est venue d’un témoin : le même symptôme a disparu dès que la machine n’était plus surchargée, et la configuration sous-jacente n’avait jamais été fausse. Cette histoire figure avec les autres dans des vérifications qui ne peuvent pas échouer.

macOS 27 : le verrou à chaque démarrage

Puis nous avons intégré nos premiers Mac mini M6 sous macOS 27, et le verrou est revenu. Cette fois, les machines étaient inactives et au calme. Elles restaient pourtant à la fenêtre de connexion après chaque redémarrage, avec lastLoginPanic de nouveau activé à chaque fois.

Notre image livre un seul LaunchAgent dans /Library/LaunchAgents. Il garde un agent de code IA en marche dans la session du client. Le script qu’il contient ne faisait déjà rien tant que le bureau n’était pas prêt. Nous avons donc soupçonné le fichier, pas le script.

Le test a été un témoin. Nous avons pris deux machines M6 identiques, dans le même état. L’une avait le plist, l’autre non. Nous les avons redémarrées à trois secondes d’intervalle. Celle sans le plist a ouvert sa session. Celle avec le plist a paniqué et s’est arrêtée à la fenêtre de connexion. Remettre le plist sur une machine qui avait bien ouvert sa session l’a de nouveau bloquée au démarrage suivant. C’est donc à chaque démarrage, pas seulement au premier.

Sous macOS 27, la fenêtre de connexion charge les LaunchAgents de /Library/LaunchAgents pendant l’échange d’ouverture de session automatique. Sur nos machines, ce chargement suffisait à faire échouer l’ouverture de session et à activer le verrou. Effacer la clé ne sert à rien, car le démarrage suivant la réactive.

# 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

Nous avons sorti le plist de /Library/LaunchAgents. Un petit LaunchDaemon root attend désormais que la session de l’utilisateur existe et que le Dock tourne. Il charge ensuite l’agent dans cette session. L’ouverture automatique marche à chaque démarrage, et l’agent démarre environ une minute plus tard.

Deux autres détails de macOS 27 nous ont piégés en route. D’abord, macOS 27 verrouille l’écran quelques secondes après l’ouverture automatique. Quand il est verrouillé, /dev/console appartient à root. Ne l’utilisez donc pas pour savoir si quelqu’un est connecté. Vérifiez plutôt le domaine gui/UID de l’utilisateur et la présence d’un Dock en marche. Ensuite, l’Assistant réglages du premier lancement reste attaché à la session. Le tuer renvoie toute la session à la fenêtre de connexion et réactive le verrou. Désactivez-le avec ses clés de préférences, et ne le tuez jamais.

La recette qui marche