Como abrir uma porta no início do processo de inicialização para desbloquear LUKS via SSH

Eu tenho um servidor totalmente criptografado executando o Debian 7 e configurei o dropbear e o busybox para desbloquear o contêiner LUKS via SSH (como descrito neste tutorial e nesta resposta de perguntas e respostas ).

Infelizmente, sempre que tento fazer o SSH no servidor (pela LAN) na reinicialização, recebo o erro "Conexão recusada". Eu tentei telnete nmappara a porta padrão (22) e ambos dizem que a porta está fechada.

O servidor tem uma ufwregra para aceitar todo o tráfego da LAN:

Anywhere         ALLOW       192.168.1.0/24

Eu tentei mudar a porta que escutas dropbear sobre em /etc/defaults/dropbearmas sshe telnetainda são recusados conexões ¹ .

Como garantir que uma porta esteja aberta nesse estágio do processo de inicialização para que eu possa conectar-me para desbloquear o contêiner LUKS?

Desabilitar o firewall não faz diferença: nmapmostra todas as portas ainda fechadas.

Atualização 2/14

Eu adicionei break=premountà linha do kernel e dei uma olhada no initramfs. dropbearfoi iniciado, mas a rede não está ativa nesse ponto. Após sair, a rede aparece e a inicialização continua até o prompt para desbloquear o dispositivo LUKS.

Nesse ponto, a rede está ativa e o host recebeu o endereço IP correto, mas a porta 22 ainda está fechada.

A linha IP em /etc/initramfs-tools/intiramfs.confque estou usando é:

export IP=192.168.1.200::192.168.1.1:255.255.255.0::eth0:off

Consistente com as instruções /usr/share/doc/cryptsetup/README.remote.gz, tentei adicionar a opção de dispositivo, mas isso não é suficiente para ativar a rede e obter uma concessão dhcp.

Atualização 11/10/14

A resposta de Karl foi o que era necessário: configurar /etc/initramfs-tools/conf.d/cryptrootera a chave:

target=md1_crypt,source=UUID=8570d12k-ccha-4985-s09f-e43dhed9fa2a

Este guia também se mostrou mais atualizado e relevante (e bem-sucedido).

ssh networking luks

— jasonwryan
fonte

UAU! Eu não sabia completamente que você poderia desbloquear remotamente um LUKS totalmente bloqueado. Obviamente, não posso responder à sua pergunta com certeza, mas acho que o sshd não foi iniciado. Na minha máquina, o sshd inicia mais tarde no processo.

— Emory

Você tem acesso ao console da máquina enquanto ela está no ambiente do busybox? Você pode verificar se o dropbear está realmente em execução (via ps) e escutando a porta que você espera (via netstat)?

— Larsks

larsks - não, porque no console o prompt aguarda a digitação da senha e mudar para outro TTY significa apenas uma tela em branco (se eu entendi corretamente).

— jasonwryan

Você pode (temporariamente) remover a criptografia LUKS e verificar se o drop bear está realmente em execução?

— Emory

Você já tentou usar um dos break=Xparâmetros de inicialização para obter um initramfsshell inicial ? Sempre que depuro problemas de criptografia do sistema de arquivos, eu uso break=premount. Você pode verificar qual é a situação, resolvê-la e continuar inicializando.

— Alexios

Respostas:

Eu tive esse mesmo problema há algumas semanas (Debian Wheezy 7.6) e após alguns dias de solução de problemas, descobri que havia um arquivo de configuração ausente que impedia que o script cryptroot no init-top funcionasse corretamente, portanto, ele não parava. para pedir a senha via ssh, matando o dropbear no final da sequência (init-bottom).

O arquivo de configuração é chamado cryptroote deve estar em /etc/initramfs-tools/conf.d/ Se não me engano, o arquivo de configuração deveria ter sido criado automaticamente durante a instalação (li apenas um tutorial falando sobre esse arquivo de configuração), mas de alguma forma não foi (testado em um servidor físico e em uma VM, mesmo sistema operacional e versões)

Foram necessárias algumas tentativas para configurá-lo corretamente, pois não consegui encontrar a sintaxe adequada naquele momento. Meu arquivo de configuração de criptografia é o seguinte:

target=crypt-root,source=/dev/vg0/root,lvm=root

Uma vez criado o arquivo de configuração, atualize o initramfs e tente novamente:

update-initramfs -u

— Karl
fonte

Você é uma lenda! Obrigado: eu lutava com isso há muito tempo e tinha praticamente perdido a esperança de resolvê-lo. Minha cryptrootsintaxe é diferente da sua, mas sua resposta foi suficiente para me indicar a direção certa. Estou em dívida com você.

— jasonwryan

Estou feliz que você finalmente conseguiu. Vi sua pergunta enquanto investigava meu problema e achei que deveria postar como resolvi a questão depois de executá-la.

— 11114 Karl

A linha de assunto está errada. O problema não é uma porta fechada, é uma porta que não estava ligada. SSHd ainda não começou; esse é o motivo pelo qual você não pode se conectar a ele.

— poige
fonte

@camh, existem regras sobre isso?

— Poige

Eu estava mais focado na primeira frase, que é editorial. O resto é bastante conciso para ser uma boa resposta, mas acho que ainda é uma resposta. Vou remover meu comentário.

— Camh

@camh, eu vejo ...

— poige

Não estou usando sshd: como a pergunta indica, estou tentando conectar-me a uma instância dropbear que é executada na porta 22 por padrão.

— jasonwryan

@jasonwryan, não desempenha nenhum papel no serviço exatamente TCP que você está tentando usar, o que realmente importa é que ele não foi iniciado.

— poige

O dropbear (servidor ssh) deve ser iniciado muito cedo durante a fase de inicialização - antes dos initscripts de sequência (rcN.d) e de inicialização do firewall; ainda mais cedo que / é montado (também é criptografado, certo?). Assim initramfs, a pré- / área do usuário carregada para o kernel pelo gerenciador de inicialização. A imagem é (re) gerada pelo update-initramfs -uconteúdo de /etc/initramfs-tools/, incluindo a configuração do dropbear em /etc/initramfs-tools/etc/dropbear/. Para brincar com a configuração dropbear, brinque com essa.

Assim, alguns pontos a serem verificados:

o dropbear não inicia: não foi conectado corretamente à sequência initramfs;
o firewall padrão nega tudo.

— yrk
fonte

Obrigado yarek: Eu acho que você está certo - atualizei minha pergunta com um bug do debian (e uma correção que não funciona). Eu também tentei desativar o firewall.

— Jasonwryan