Inicio de sesión automático en un Mac sin pantalla, y por qué macOS 27 se lo salta

Un Mac alquilado tiene que sobrevivir solo a un reinicio. No hay nadie delante de la máquina para escribir una contraseña. El escritorio en el navegador del cliente se conecta a la sesión gráfica, así que la máquina tiene que volver con la sesión iniciada. El inicio de sesión automático sin pantalla en Apple Silicon es un pequeño montón de detalles concretos, y cuatro de ellos fallan en silencio. Uno es nuevo en macOS 27. Aquí los tienes.

Los dos ajustes que lo activan

El inicio de sesión automático tiene dos piezas. Una preferencia que nombra al usuario, y la contraseña guardada donde la ventana de inicio de sesión puede leerla.

# 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á ofuscado con una clave fija, no cifrado. Cualquiera que pueda leer el archivo puede recuperar la contraseña. Solo es aceptable porque la máquina únicamente es accesible por una red privada, nunca por la internet pública. En una máquina con un puerto abierto, sería una credencial a la vista de todos.

Las cuatro paradas silenciosas

FileVault

FileVault cifra el disco, y el disco tiene que desbloquearse antes de que macOS pueda iniciar la sesión de nadie. En una máquina con teclado, una persona escribe el desbloqueo. Sin pantalla no hay nadie que lo escriba, así que el inicio de sesión automático y FileVault son incompatibles en una máquina que no puedes tocar. Trabajamos con FileVault desactivado y usamos la red privada como frontera.

El flag de bloqueo de pantalla

Hay una preferencia que vuelve a bloquear la pantalla incluso tras el inicio de sesión automático, pensada para máquinas que se bloquean cuando la pantalla entra en reposo. Si está activada, la sesión arranca pero la pantalla está bloqueada, y quien mira en remoto la ve negra. Borramos autoLoginUserScreenLocked cada vez que activamos el inicio de sesión automático.

El bloqueo por pánico, que nos costó un día

El sutil. Cuando falla una sesión, macOS registra lastLoginPanic en las preferencias de la ventana de inicio de sesión. Después se salta a propósito el inicio de sesión automático en el siguiente arranque y muestra la pantalla de inicio de sesión. Es una medida de seguridad, para que una máquina que se cuelga al iniciar sesión no entre en un bucle.

En un Mac recién dado de alta, el primer arranque estaba ocupado indexando una copia grande de Xcode con una carga media de más de 160. El inicio de sesión no terminó a tiempo y se activó el bloqueo. Todos los arranques siguientes se saltaron el inicio de sesión automático, en una máquina con una configuración totalmente correcta.

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

Tras borrarlo con la máquina ya tranquila, el inicio de sesión automático funcionó a la primera, con la misma contraseña y los mismos ajustes que había desde el principio. Casi lo documentamos como un bug de una nueva versión de macOS. Aquella vez no lo era. La prueba fue una prueba de control: el mismo síntoma desapareció en cuanto la máquina dejó de estar sobrecargada, y la configuración de fondo nunca había estado mal. Esa historia está junto a las demás en comprobaciones que no pueden fallar.

macOS 27: el bloqueo en cada arranque

Después dimos de alta nuestros primeros mini M6 con macOS 27, y el bloqueo volvió. Esta vez las máquinas estaban inactivas y tranquilas. Aun así, se quedaban en la ventana de inicio de sesión tras cada reinicio, con lastLoginPanic activado de nuevo cada vez.

Nuestra imagen incluye un LaunchAgent en /Library/LaunchAgents. Mantiene un agente de programación con IA funcionando en la sesión del cliente. El script que lleva dentro ya no hacía nada si el escritorio no estaba listo. Así que sospechamos del archivo, no del script.

La prueba fue de control. Tomamos dos unidades M6 idénticas en el mismo estado. Una tenía el plist y la otra no. Las reiniciamos con tres segundos de diferencia. La que no tenía el plist inició sesión. La que lo tenía entró en pánico y se quedó en la ventana de inicio de sesión. Al volver a poner el plist en una unidad que había iniciado sesión bien, se quedó atascada otra vez en el siguiente arranque. Así que pasa en cada arranque, no solo en el primero.

En macOS 27, la ventana de inicio de sesión carga los LaunchAgents de /Library/LaunchAgents durante el proceso de inicio de sesión automático. En nuestras máquinas, esa carga bastaba para que fallara el inicio de sesión y se activara el bloqueo. Borrar la clave no sirve, porque el siguiente arranque la vuelve a activar.

# 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

Sacamos el plist de /Library/LaunchAgents. Ahora un pequeño LaunchDaemon de root espera a que exista la sesión del usuario y a que el Dock esté en marcha. Entonces carga el agente en esa sesión. El inicio de sesión automático funciona en cada arranque, y el agente arranca más o menos un minuto después.

Otros dos detalles de macOS 27 nos mordieron por el camino. Primero, macOS 27 bloquea la pantalla unos segundos después del inicio de sesión automático. Cuando está bloqueada, el dueño de /dev/console es root, así que no lo uses para comprobar si hay alguien con la sesión iniciada. Comprueba mejor que existe el dominio gui/UID del usuario y que el Dock está en marcha. Segundo, el Asistente de Configuración del primer arranque sigue unido a la sesión. Si lo matas, toda la sesión cae a la ventana de inicio de sesión y se vuelve a activar el bloqueo. Desactívalo con sus claves de preferencias, y nunca lo mates.

La receta que funciona