Apple: SSH e FileVault

• Com o FileVault ativado, durante a inicialização do macOS, o volume de dados permanece bloqueado
• Os arquivos de configuração do OpenSSH ficam armazenados no volume de dados, então, enquanto ele estiver bloqueado, os métodos de autenticação existentes ou o acesso ao shell não ficam disponíveis
• Se o Remote Login (SSH) estiver ativado, é possível desbloquear o volume de dados remotamente pela rede com autenticação por senha
• Esse método não libera a sessão SSH imediatamente; após o desbloqueio, ocorre uma interrupção temporária da conexão SSH
• O acesso via SSH passa a ficar disponível depois que o volume de dados é montado e os serviços necessários são iniciados

---

Visão geral da integração entre SSH e FileVault da Apple

• Em macOS com FileVault ativado, o volume de dados fica bloqueado, o que impede o acesso a esse volume mesmo após o início da inicialização
• Como todos os arquivos de configuração do sistema e por conta do OpenSSH ficam armazenados no volume de dados, enquanto ele estiver bloqueado, os métodos de autenticação normalmente configurados ou o acesso ao shell ficam desativados

Desbloqueio remoto com Remote Login (SSH)

• Mesmo após a inicialização, com o volume de dados bloqueado, se o Remote Login (login via SSH) estiver ativado, o sistema permite tentativas de autenticação por senha pela rede
• O usuário pode usar SSH para desbloquear remotamente o volume protegido pelo FileVault por meio de autenticação por senha

Limitações e processo do desbloqueio

• Esse recurso permite desbloquear o volume de dados, mas isso não significa que a sessão SSH será conectada imediatamente
• Assim que o volume de dados é desbloqueado, o macOS interrompe temporariamente a conexão SSH enquanto conclui a montagem do volume e a inicialização dos serviços de suporte que dependem dele
• Depois que esse procedimento é concluído, o uso normal de SSH e de outros serviços ativados passa a ser possível

Introdução no macOS 26 Tahoe

• O recurso de desbloqueio remoto do volume de dados via SSH foi introduzido pela primeira vez no macOS 26 Tahoe

[GN⁺]

Comentários do Hacker News

• Ao ativar o FileVault, percebi que o volume de dados fica bloqueado e não pode ser acessado durante ou após a inicialização até que a autenticação seja feita com a senha da conta; o OpenSSH do macOS armazena tanto os arquivos de configuração do sistema quanto os por conta no volume de dados. Por isso, enquanto o FileVault está bloqueado, normalmente não é possível usar o método de autenticação configurado nem acessar o shell. Porém, se o Remote Login estiver ativado, a autenticação por senha via SSH passa a funcionar mesmo nessa situação. Isso permite desbloquear remotamente o volume de dados pela rede. A sessão SSH não continua imediatamente, mas, após o desbloqueio do volume via SSH, a conexão cai brevemente enquanto o macOS termina de montar o volume e reiniciar os serviços; depois disso, o SSH (e outros serviços) voltam a funcionar normalmente. Uma mudança realmente muito bem-vinda

• Fico pensando se isso significa que agora dá para operar um servidor Mac mini totalmente remoto, mesmo após uma reinicialização automática causada por queda de energia, sem precisar conectar fisicamente um teclado. Uma mudança incrível mesmo

  • Testei diretamente e confirmei que funciona perfeitamente
    1. Ativar General > Sharing > Remote Management
    2. Após reiniciar, ao conectar por SSH, aparece a mensagem: "Este sistema está bloqueado. Use o nome da conta e a senha para desbloqueá-lo. Depois disso, será possível se conectar normalmente"
    3. Ao autenticar com sucesso via SSH, a conexão é encerrada e aparece a mensagem: "Sistema desbloqueado com sucesso. Agora é possível autenticar normalmente via SSH"
    4. Ao se conectar por SSH novamente, o acesso funciona normalmente
  • Também dá para usar o seguinte comando

    sudo fdesetup authrestart -delayminutes -1
    

    Esse método faz login automático com a conta escolhida apenas na próxima reinicialização. É prático por não exigir digitação de senha, mas traz risco de segurança. Dependendo da situação, pode ser aceitável
  • Tenho uma curiosidade sincera: por que escolher macOS como sistema operacional de servidor? Eu também acho o hardware do Mac mini extremamente atraente e já considerei isso. Mas fico hesitante em rodar Linux no lugar do macOS
  • Já passei pela situação de um colega ter ativado o FileVault por engano em uma máquina de CI, e precisei literalmente tirar o servidor do rack, limpar a poeira, conectar monitor e teclado e fazer login para desbloquear. Agora que o desbloqueio por SSH é possível, se isso acontecer de novo, dá para resolver remotamente na hora
  • Conheço bem a inconveniência de precisar de login físico para colocar um Mac remoto com FileVault de volta online após uma queda de energia. Queria saber se, depois da reinicialização, também é possível chegar até o acesso remoto completo pela GUI. Estou pensando em comprar um Mac mini para homelab e até cogitando se ainda seria necessário usar algum dispositivo remoto tipo KVM

• Quero destacar que isso é uma mudança enorme para ambientes Mac não pessoais, como empresas. O custo-benefício e a qualidade do Mac Mini são bem interessantes para automação, e nas empresas a adoção estava aumentando aos poucos sempre que possível. O problema do FileVault era um dos principais fatores que travavam isso

  • Eu tinha interesse em usar Mac como servidor de uso geral. Queria saber se há configurações ou práticas adicionais para facilitar a administração nesse cenário, e se o uso é voltado a workloads específicos de Mac ou se também rodam workloads Linux baseados em contêineres

• Fiquei feliz em ver que o macOS 26 Tahoe adicionou a função de desbloquear o volume de dados via SSH. Depois de atualizar recentemente para Tahoe, eu tinha estranhado conseguir acessar por SSH de forma inesperada, e agora descobri que foi por causa dessa mudança. Normalmente eu não desligo o Mac, mas às vezes preciso acessá-lo remotamente e acabava esquecendo que havia instalado uma grande atualização no dia anterior. Com essa mudança, essa preocupação diminui

• Isso me faz supor que agora a criptografia do FileVault não se aplica mais ao volume do sistema. Acho lógico, já que o volume do sistema é somente leitura, tem conteúdo fixo e é o mesmo em todos os macOS. Também faz sentido conseguir inicializar toda a pilha de rede antes de exigir o desbloqueio do volume de dados. Se o FileVault realmente passar a ignorar a criptografia do volume do sistema, acho uma mudança muito sensata. Vale mencionar também que, com a tecnologia de overlay, muitas vezes parece que se está escrevendo na partição do sistema, mas na prática os dados vão para o volume de dados

  • Informações como a senha do Wi‑Fi também ficam no volume de dados, então a rede nem sempre estará disponível

• Mudança interessante, mas fico curioso se o problema de “race condition” visto em sessões gráficas também se aplicaria ao SSH, como no caso de o shell estar armazenado no volume de dados. Por exemplo, ao reiniciar com a opção de restaurar aplicativos, já vi o sistema abrir os apps antes de todos os volumes estarem montados, o que fazia a execução do shell falhar. Isso acontecia muito ao instalar o shell com Nix. Parece bem possível que o mesmo problema ocorra com SSH. Queria saber se isso foi resolvido em nível de sistema

  • No processo de desbloqueio via SSH, a conexão é encerrada logo após o desbloqueio do volume de dados. Depois que a montagem termina, basta conectar de novo e o shell é executado, então esse problema não ocorre. Ao usar a Nix store, já consegui resolver isso com um shim usando wait4path. Basta instalar o shim com antecedência em um caminho conhecido no volume de dados e defini-lo como shell de login
  • A Apple elimina esse problema pela raiz encerrando todos os processos após o desbloqueio do dispositivo ("userspace reboot")
  • Acho que a reconexão resolve a maior parte dos casos. Especialmente no SSH, normalmente já existe algum mecanismo de tentativa de reconexão de rede, então não parece ser um grande problema
  • Esse caso provavelmente pode ser resolvido com o utilitário wait4path, que já vem no sistema operacional há muito tempo

• Acho essa mudança realmente muito bem-vinda. Eu mantinha o FileVault desativado justamente por causa disso

• Estou testando a Full Disk Encryption do Omarchy (uma configuração de Arch com uma proposta bem definida) e pensando se daria para usá-lo como minha VM principal. Quando estou fisicamente no local, tenho acesso ao desktop com aceleração por GPU e a todas as minhas cargas de trabalho de longa duração. Mas, se eu ficar remoto por algumas semanas e a máquina reiniciar, eu teria de digitar a senha do disco fisicamente, o que já me desanima de tentar. Estou rodando isso em ProxMox, mas, por causa de configurações como USB passthrough, não consigo acessar pela visualização VNC padrão. Fico curioso se o Omarchy tentará implementar desbloqueio remoto como o macOS

  • No Linux, já era possível há muito tempo implementar desbloqueio remoto colocando o dropbear no initramfs

• Tenho certeza de que deve existir algum vetor de ataque ou vulnerabilidade nisso

  • Fora os riscos normais de segurança do SSH com senha, não consigo pensar em nenhum risco adicional específico. Se isso for uma preocupação, acho que colocá-lo atrás de um firewall como Wireguard já ajuda bastante. Antes era preciso desativar o FileVault em servidores Mac, então, em comparação, essa mudança me parece muito positiva
  • Pela experiência com problemas de segurança como o Blastdoor, eu sempre tendo a abordar mudanças assim com cautela

• Eu tinha um Mac mini que havia descartado para uso em homelab justamente por falta desse recurso, mas agora parece que tudo mudou