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

11

Eu tenho um servidor totalmente criptografado rodando Debian 7 e configurei o dropbear e o busybox para destravar o contêiner LUKS via SSH (como descrito em neste tutorial e em esta resposta U & L ).

Infelizmente, sempre que tento SSH para o servidor (pela LAN) na reinicialização, recebo um erro de "Conexão recusada". Eu tentei telnet e nmap para a porta padrão (22) e ambos dizem que a porta está fechada.

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

Anywhere         ALLOW       192.168.1.0/24

Eu tentei alterar a porta que o dropbear escuta em /etc/defaults/dropbear , mas ssh e telnet ainda têm conexões recusadas 1 .

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

Desativar o firewall não faz diferença: nmap mostra todas as portas ainda fechadas.

Atualização 2/14

Eu adicionei break=premount à linha do kernel e dei uma olhada no initramfs. dropbear foi iniciado, mas a rede não está nesse ponto. Depois de sair, a rede é acionada e a inicialização continua até o prompt para desbloquear o dispositivo LUKS.

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

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

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

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

Atualização 11/10/14

A resposta de Karl foi necessária: configurar /etc/initramfs-tools/conf.d/cryptroot foi 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).

    
por jasonwryan 21.04.2012 / 23:29

3 respostas

3

Eu tenho esse mesmo problema há algumas semanas (Debian Wheezy 7.6) e depois de alguns dias de solução de problemas descobri que havia um arquivo de configuração faltando que estava impedindo que o script cryptroot no init-top rodasse corretamente, daí não estava parando para pedir a senha via ssh, matando o dropbear no final da sequência (init-bottom).

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

Demorei algumas tentativas para configurá-lo corretamente, pois não encontrei a sintaxe adequada naquele momento. Meu arquivo de configuração cryptroot é o seguinte:

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

Uma vez criado o arquivo de configuração, basta atualizar o initramfs e tentar novamente:

update-initramfs -u

Provavelmente você já corrigiu seu problema, mas espero que ajude alguém na mesma situação.

    
por 09.10.2014 / 20:11
3

O dropbear (servidor ssh) deve ser iniciado muito cedo durante a fase de inicialização - mais cedo do que a sequência de init (rcN.d) e os scripts de inicialização do firewall; ainda mais cedo do que / é montado (ele também é criptografado, certo?). Então, vem para initramfs , o pre / userland carregado pelo kernel pelo carregador de boot. A imagem é (re) gerada por update-initramfs -u do conteúdo de /etc/initramfs-tools/ , incluindo configuração dropbear em /etc/initramfs-tools/etc/dropbear/ . Para jogar com a configuração dropbear, brinque com essa.

Assim, alguns pontos para verificar:

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

Espero que isso ajude.

    
por 04.05.2012 / 17:00
3

O assunto está errado. O problema não é uma porta fechada, é uma porta que não estava vinculada. O SSHd ainda não começou; essa é a razão pela qual você não pode se conectar a ele.

    
por 04.05.2012 / 14:28