Consoles seriais e out-of-band para manter o acesso ao servidor quando a rede está fora do ar

Objetivo

Manter uma forma de acessar o console do servidor quando o caminho de rede normal (SSH pela interface principal) é justamente o que está quebrado: um firewall mal configurado, o carregamento de um driver de rede que falhou ou um kernel que entra em panic antes de subir a rede.

Pré-requisitos

Para uma linha serial física ou virtualizada: um cabo null-modem ou um dispositivo serial fornecido pelo hipervisor, e um emulador de terminal na outra ponta (a taxa de transmissão em baud deve ser a mesma nos dois lados). Para uma instância em nuvem: o recurso de console serial/de sistema do provedor, habilitado com antecedência. Para um servidor físico com BMC: ipmitool e acesso ao BMC pela rede ou por porta dedicada, configurados previamente.

Passos

1. Adicione um console serial à linha de comando do kernel, para que as mensagens de boot e os shells de emergência apareçam nele: console=tty0 console=ttyS0,115200 (dispositivo, taxa em baud; a documentação do kernel usa ttySx para "a serial port", ou seja, uma porta serial). A saída vai para todos os consoles listados, mas o último da lista se torna /dev/console, onde os shells de resgate e de emergência exibem o prompt; por isso, coloque o serial por último. Para tornar a configuração persistente, use grubby --update-kernel=ALL --args="console=tty0 console=ttyS0,115200" (família RHEL) ou defina GRUB_CMDLINE_LINUX e execute update-grub (Debian/Ubuntu); ela só vale a partir do próximo boot.
2. Para que o próprio menu do GRUB apareça na linha serial (necessário para escolher remotamente um kernel de fallback), defina GRUB_TERMINAL="console serial" e GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0" em /etc/default/grub e gere novamente o grub.cfg.
3. Prompt de login: o systemd-getty-generator inicia automaticamente o serial-getty@ttyS0.service quando há um console serial do kernel; para outras linhas, habilite-o explicitamente (systemctl enable --now serial-getty@ttyS1.service). O processo que atende a linha é o agetty.
4. Na AWS (tipos de instância baseados em Nitro), o acesso ao console serial vem desativado por padrão: a conta precisa habilitá-lo e as políticas IAM precisam concedê-lo; depois disso, ele funciona independentemente da rede da instância. O login exige um usuário do SO com senha, pois chaves SSH não se aplicam nesse caso.
5. No Azure, o Serial Console do portal oferece acesso equivalente pelo plano de controle; ele exige que o boot diagnostics esteja habilitado e, igualmente, um usuário local com senha.
6. Para servidores físicos com BMC, verifique o SOL com ipmitool sol info e conecte-se com ipmitool -I lanplus -H <bmc-ip> -U <user> -E sol activate (-E lê a senha da variável IPMI_PASSWORD, o que a mantém fora da lista de processos); sol activate exige a interface lanplus (IPMI v2.0). Para sair, use a sequência de escape (padrão ~.); execute sol deactivate se uma sessão anterior deixou o SOL marcado como ativo.
7. Teste cada caminho uma vez em um sistema saudável, incluindo as credenciais e a possibilidade de alcançar o BMC ou o console da nuvem independentemente da rede do próprio host.

Resultado esperado

O menu do bootloader, as mensagens do kernel e um prompt de login aparecem todos na linha serial ou no console do provedor, de modo que um travamento no boot ou um bloqueio por firewall ainda deixa um console utilizável.

Limites e base de verificação

Um console serial mostra apenas o texto que o kernel ou o espaço de usuário escrevem explicitamente nesse dispositivo; ele não substitui o journalctl a posteriori, caso o buffer do console tenha rolado além do que uma pessoa conseguiria capturar. O acesso ao BMC/SOL é, ele próprio, uma credencial a proteger: trate a rede do BMC com a mesma sensibilidade do acesso root ao próprio host, pois o SOL, assim como um console físico, alcança o menu de boot e os shells de resgate e, portanto, equivale na prática a acesso root.