Tengo un servidor que ejecuta Debian Buster, cuyo sistema de archivos raíz esnocifradas, pero otras unidades sí lo están.
[Hora estimada de llegada:Todos los directorios del sistema operativo ( ,,, /varetc. ) están en la partición raíz no cifrada. El intercambio está cifrado, pero se crea de forma no interactiva con una nueva clave aleatoria en cada arranque, por lo que no hay nada que se detenga esperando.] Tengo entradas en /etc/crypttab y /etc/fstab para descifrar y montar el 'almacenamiento' cifrado unidades, y el proceso de arranque esperará indefinidamente la frase de contraseña de la pequeña partición cifrada que contiene los archivos clave que descifran las otras unidades. Hasta ahora, todo bien. El mensaje de contraseña aparece en un monitor conectado físicamente, escribo la frase de contraseña con un teclado conectado físicamente y el arranque continúa. Tengo instalado el demonio OpenSSH y uso autenticación de clave pública para conectarme al servidor para todo tipo de administración una vez que se inicia./home/etc
Ahora quiero poder desbloquear remotamente esos dispositivos LUKS a través de ssh. Dado que la raíz esnouno de los sistemas de archivos cifrados, no veo ninguna necesidad de todo el asunto de "dropbear+busybox en initramfs", y pensé que sería relativamente sencillo.
sudo systemctl edit ssh.servicey agregue las siguientes líneas:
[Unit]
Before=cryptsetup-pre.target
[Install]
WantedBy=cryptsetup-pre.target
Esto debería hacer que systemd cambie las cosas para iniciar sshd antes de iniciar cualquier descifrado de discos locales, ¿verdad? (Elegí WantedByen lugar de hacerlo RequiredByporque no quiero que systemd falle en cryptsetup si sshd no aparece como se esperaba).
sudo systemctl daemon-reloadno se queja y cat /etc/systemd/system/ssh.service.d/override.confmuestra esas cuatro líneas como se esperaba. Al reiniciar, aparece el mensaje de contraseña (esperado), pero todos los intentos de ingresar mediante ssh al servidor regresan con No route to host, por lo que claramente ssh.service no se inició primero.
Intenté cambiar la anulación para especificar que ssh es WantedBy y, [email protected]en su lugar, viene antes de la unidad generada por systemd. Curiosamente, esto no resultó en sshyno se solicitaba la frase de contraseña, por lo que el arranque simplemente se colgó para siempre y tuve que arrancar desde el medio de recuperación y eliminar la anulación. Eso no es exactamente útil, pero al menos tuvo un efecto observable. ¿Quizás he creado una dependencia circular en alguna parte? El mensaje de contraseña parece apareceren realidadal principio de la secuencia de arranque.
¿Cuáles son mis próximos pasos aquí? ¿Es posible anular la unidad cryptsetup generada por systemd para proporcionarle Wants=enlaces ? Si es posible, ¿hay alguna razón para pensar que se obtendrían mejores resultados? ¿Tendría sentido escribir mis propias unidades en /etc/ para esa partición del almacén de claves y eliminar las entradas inittab y fstab correspondientes? En resumen, ¿hay alguna manera remotamente sensata de hacer que esto funcione, o debería abandonar esta vía y optar por dropbear+busybox en initramfs después de todo?After=ssh.service
PD. Pensé en simplemente hacer que las unidades cifradas sean 'noautomáticas', pero tengo máquinas virtuales en esos discos configuradas para iniciarse automáticamente más adelante en el proceso de arranque, por lo que preferiría que funcionara el desbloqueo remoto.
Respuesta1
Usar cryptsetup.targeto cryptsetup-pre.targetno funcionó para mí, pero no sé por qué.
Funcionó para crear una superposición para [email protected]:
# /etc/systemd/system/[email protected]/myservice.conf
[Unit]
Wants=myservice.service
After=myservice.service