Apple: SSH y FileVault

• Al activar FileVault durante el arranque de macOS, el volumen de datos permanece bloqueado
• Los archivos de configuración de OpenSSH se guardan en el volumen de datos, por lo que mientras está bloqueado no se puede usar el método de autenticación habitual ni acceder al shell
• Si Remote Login (SSH) está activado, es posible desbloquear el volumen de datos desde una red remota mediante autenticación por contraseña
• Este método no permite una sesión SSH inmediata; tras el desbloqueo, la conexión SSH se interrumpe temporalmente
• El acceso por SSH queda disponible después de que se monte el volumen de datos y se inicien los servicios necesarios

---

Resumen de la integración de SSH y FileVault en Apple

• En macOS con FileVault activado, el volumen de datos queda bloqueado y no se puede acceder a él incluso después de iniciado el arranque
• Como todos los archivos de configuración del sistema y por cuenta de OpenSSH se almacenan dentro del volumen de datos, cuando este está bloqueado normalmente quedan deshabilitados el método de autenticación configurado y el acceso al shell

Desbloqueo remoto con Remote Login (SSH)

• Incluso después del arranque, cuando el volumen de datos sigue bloqueado, si Remote Login (inicio de sesión por SSH) está activado, se permiten intentos de autenticación por contraseña a través de la red
• El usuario puede usar SSH para desbloquear de forma remota el volumen protegido por FileVault mediante autenticación por contraseña

Limitaciones y proceso del desbloqueo

• Esta función permite desbloquear el volumen de datos, pero eso no significa que la sesión SSH quede conectada de inmediato
• En cuanto se desbloquea el volumen de datos, macOS interrumpe brevemente la conexión SSH mientras termina de montar el volumen y poner en marcha los servicios de soporte que dependen de él
• Una vez completado este procedimiento, se puede usar normalmente SSH y los demás servicios que estén habilitados

Introducción en macOS 26 Tahoe

• La función de desbloqueo remoto del volumen de datos a través de SSH se introdujo por primera vez en macOS 26 Tahoe

[GN⁺]

Comentarios en Hacker News

• Al activar FileVault, el volumen de datos queda bloqueado y no se puede acceder a él durante ni después del arranque hasta autenticarse con la contraseña de la cuenta; OpenSSH para macOS guarda tanto la configuración del sistema como la de cada cuenta en el volumen de datos. Por eso, mientras FileVault está activo, normalmente no se puede usar el método de autenticación configurado ni acceder al shell. Sin embargo, si está activado Remote Login, la autenticación por contraseña vía SSH sí funciona incluso en esta situación. Con eso se puede desbloquear remotamente el volumen de datos por la red. Eso sí, la sesión SSH no continúa de inmediato: tras desbloquear el volumen por SSH, la conexión se corta un momento mientras macOS termina de montar el volumen y reiniciar los servicios; después de eso, SSH (y otros servicios) ya pueden usarse normalmente. Es un cambio realmente bienvenido

• Me pregunto si esto significa que, tras un reinicio automático después de un corte de luz, ahora se puede operar un Mac mini servidor completamente remoto sin conectar físicamente un teclado. Es un cambio genial

  • Hice la prueba y confirmé que funciona perfectamente
    1. Activar General > Sharing > Remote Management
    2. Al conectarse por SSH después de reiniciar, aparece el mensaje: "Este sistema está bloqueado. Usa el nombre de la cuenta y la contraseña para desbloquearlo. Después podrás conectarte normalmente"
    3. Si la autenticación por SSH es exitosa, la conexión SSH se corta y aparece el mensaje: "El sistema se desbloqueó correctamente. Ahora puedes autenticarte normalmente por SSH"
    4. Al volver a conectarte por SSH, ya entras con normalidad
  • También se puede usar este comando

    sudo fdesetup authrestart -delayminutes -1
    

    Este método hace que en el siguiente reinicio se inicie sesión automáticamente una sola vez con la cuenta elegida. Es práctico porque no requiere ingresar la contraseña, pero tiene riesgos de seguridad. Según el caso, puede ser aceptable
  • Tengo una duda genuina: ¿por qué elegir macOS como sistema operativo de servidor? Yo también pienso que el hardware del Mac mini es muy atractivo y lo he considerado. Pero me cuesta decidirme a usar Linux en lugar de macOS
  • Antes, por culpa de un colega que activó FileVault por error en una máquina de CI, tuve que sacar el servidor del rack, limpiarle el polvo y conectarle monitor y teclado para iniciar sesión y desbloquearlo. Ahora que se puede desbloquear por SSH, si vuelve a pasar algo así se podrá resolver de inmediato de forma remota
  • Conozco bien la molestia de que un Mac remoto con FileVault necesitara un inicio de sesión físico para volver a estar en línea después de un corte de luz. Me pregunto si después del reinicio también se podrá llegar a una conexión remota completa por GUI. Estoy pensando en comprar un Mac mini para el laboratorio de casa y hasta he considerado si haría falta un dispositivo remoto tipo KVM

• Quiero mencionar que este cambio es enorme para entornos de Mac no personales, como en empresas. La relación costo-rendimiento y la calidad del Mac Mini lo hacen bastante útil para automatización, y de hecho en la empresa habíamos estado aumentando su adopción poco a poco si no fuera por este problema. El tema de FileVault era uno de los principales frenos

  • Me interesaba usar Mac como servidor de propósito general. Quisiera saber si hay configuraciones o métodos adicionales para administrarlo más fácilmente como servidor, y si suelen correr cargas de trabajo exclusivas de Mac o también cargas Linux basadas en contenedores

• Me alegra que en macOS 26 Tahoe hayan añadido la función de desbloqueo del volumen de datos por SSH. Hace poco, tras actualizar a Tahoe, me sorprendió poder conectarme por SSH y ahora entiendo que se debía a este cambio. Normalmente no apago la Mac, pero a veces necesito acceder de forma remota y olvido que la noche anterior se instaló una gran actualización, lo que me dejaba en aprietos. Con este cambio, me preocupo menos

• Supongo que esto significa que FileVault ya no cifra el volumen del sistema. Como el volumen del sistema es de solo lectura, su contenido es fijo y es igual en todas las instalaciones de macOS, tiene lógica pensarlo así. También resulta convincente la idea de arrancar todo, incluida la red, y luego pedir el desbloqueo del volumen de datos. Si FileVault realmente deja fuera el cifrado del volumen del sistema, me parece un cambio muy sensato. También se menciona que, con tecnologías de overlay, muchas veces parece que se escribe en la partición del sistema, pero en realidad se guarda en el volumen de datos

  • Datos como la contraseña del WiFi también se guardan en el volumen de datos, así que la red no necesariamente estará disponible siempre

• Es un cambio interesante, pero me pregunto si el problema de “condición de carrera” que ocurre en sesiones gráficas, como cuando el shell está guardado en el volumen de datos, también afectará a SSH. Por ejemplo, al reiniciar y elegir restaurar apps, hubo casos reales donde las apps arrancaban antes de que se montaran todos los volúmenes y entonces fallaba la ejecución del shell. Suele pasar al instalar el shell con Nix. Parece muy probable que el mismo problema pueda ocurrir con SSH. Me pregunto si esto ya se resolvió a nivel del sistema

  • En el proceso de desbloqueo por SSH, la conexión se cierra justo después de desbloquear el volumen de datos. Cuando termina de montarse el volumen, vuelves a conectarte y entonces se ejecuta el shell, así que no hay ese problema. Al usar Nix store, he resuelto algo parecido con un shim usando wait4path. Basta con instalar el shim de antemano en una ruta conocida del volumen de datos y configurarlo como shell de inicio de sesión
  • Apple evita este problema de raíz terminando todos los procesos tras desbloquear el dispositivo (“userspace reboot”)
  • Me parece que reconectarse resolverá la mayoría de los casos. Sobre todo en SSH, donde normalmente ya existen mecanismos de reintento de red, así que no sería un gran problema
  • Creo que este caso puede resolverse con la utilidad wait4path, incluida en el OS desde hace mucho tiempo

• Me parece un cambio realmente bienvenido. Yo tenía FileVault desactivado precisamente por esta limitación

• Estoy probando el Full Disk Encryption de Omarchy (una configuración de Arch con una dirección muy marcada) y pensando si podría usarlo como mi VM principal. Cuando trabajo físicamente con la máquina, tengo acceso al escritorio con aceleración por GPU y a todos los procesos de larga duración. Pero si estoy varias semanas fuera y la máquina se reinicia, me frenaba por completo el hecho de tener que ingresar físicamente la contraseña del disco. Corre sobre ProxMox, pero por temas como el USB passthrough no puedo acceder con un visor VNC estándar. Me pregunto si Omarchy intentará algo como el desbloqueo remoto de macOS

  • En Linux, desde hace muchísimo tiempo se puede implementar desbloqueo remoto metiendo dropbear en initramfs

• Seguro que en algún lado hay una superficie de ataque para explotar una vulnerabilidad

  • Más allá de los riesgos de seguridad habituales de SSH con contraseña, no se me ocurre un riesgo adicional claro. Si preocupa, ponerlo detrás de un firewall como Wireguard probablemente mejora bastante la situación. Antes había que desactivar FileVault en los Mac servidores, así que en comparación me parece un cambio mucho mejor
  • Por experiencias con problemas de seguridad como Blastdoor, siempre termino abordando cambios así con mucha cautela

• Tenía un Mac mini que había descartado para el homelab por no contar con esta función, pero ahora siento que todo cambió