Eu tenho um servidor rodando Debian Buster, cujo sistema de arquivos raiz énãocriptografado, mas outras unidades são.
[Hora prevista de chegada:Todos os diretórios do sistema operacional ( /var, /home, /etc, etc) estão na partição raiz não criptografada. O swap é criptografado, mas é criado de forma não interativa com uma nova chave aleatória a cada inicialização, então nada fica esperando por isso.]
Tenho entradas em /etc/crypttab e /etc/fstab para descriptografar e montar o 'armazenamento' criptografado unidades, e o processo de inicialização aguardará indefinidamente pela senha para a pequena partição criptografada que contém os arquivos-chave que descriptografam as outras unidades. Até agora tudo bem. O prompt da senha aparece em um monitor conectado fisicamente, eu digito a senha com um teclado conectado fisicamente e a inicialização continua. Eu tenho o daemon OpenSSH instalado e uso autenticação de chave pública para conectar-me ao servidor para todos os tipos de administração, uma vez inicializado.
Agora quero poder desbloquear remotamente esses dispositivos LUKS por meio de ssh. Como a raiz énãoum dos sistemas de arquivos criptografados, não vejo nenhuma necessidade de todo o negócio "dropbear + busybox no initramfs" e pensei que isso seria relativamente simples.
sudo systemctl edit ssh.servicee adicione as seguintes linhas:
[Unit]
Before=cryptsetup-pre.target
[Install]
WantedBy=cryptsetup-pre.target
Isso deve fazer com que o systemd embaralhe as coisas para iniciar o sshd antes de iniciar qualquer descriptografia de discos locais, certo? (Eu escolhi WantedBynão RequiredByporque não quero que o systemd 'falhe' o cryptsetup se o sshd não funcionar conforme o esperado.)
sudo systemctl daemon-reloadnão reclama e cat /etc/systemd/system/ssh.service.d/override.confmostra essas quatro linhas conforme esperado. Na reinicialização, o prompt da senha aparece (esperado), mas todas as tentativas de ssh no servidor voltam com No route to host, então claramente o ssh.service não foi iniciado primeiro.
Tentei alterar a substituição para especificar que ssh é WantedBy e vem antes [email protected]da unidade gerada pelo systemd. Curiosamente, isso não resultou em nenhum sshenenhum prompt de senha, então a inicialização ficou travada para sempre e tive que inicializar a partir da mídia de recuperação e remover a substituição. Isso não é exatamente útil, mas pelo menos teve um efeito observável. Talvez eu tenha criado uma dependência circular em algum lugar? O prompt da senha parece virrealmenteno início da sequência de inicialização.
Quais são meus próximos passos aqui? É possível substituir a unidade cryptsetup gerada pelo systemd para fornecer links para Wants=ela ? Se for possível, há alguma razão para pensar que obteríamos melhores resultados? Faria sentido escrever minhas próprias unidades em /etc/ para essa partição de armazenamento de chaves e remover as entradas inittab e fstab correspondentes? Resumindo, existe alguma maneira remotamente sensata de fazer isso funcionar, ou devo desistir dessa avenida e optar pelo dropbear + busybox no initramfs, afinal?After=ssh.service
PS. Pensei em apenas tornar as unidades criptografadas 'noauto', mas tenho VMs nesses discos configuradas para inicialização automática posteriormente no processo de inicialização, então prefiro que o desbloqueio remoto funcione.
Responder1
Usar cryptsetup.targetor cryptsetup-pre.targetnão funcionou para mim, mas não sei por quê.
Funcionou para criar uma sobreposição para [email protected]:
# /etc/systemd/system/[email protected]/myservice.conf
[Unit]
Wants=myservice.service
After=myservice.service