SSH num segundo caminho privado enquanto a VPN permanece ativa

Uma máquina alcança outra através de uma VPN, e agora alguém quer a mesma shell na rede privada de um fornecedor. A rota existe, o ping funciona e o SSH continua a recusar. A causa habitual é que o daemon nunca escutou no novo endereço, pelo que não há nada a que ligar. Isto é um problema de ligação de endereço antes de ser um problema de firewall.

Porque é que uma nova rota não cria um novo listener

Um socket à escuta é criado por um processo que indica os endereços em que aceitará ligações. Uma rota apenas diz aos pacotes para onde viajar; não cria um listener no destino. Quando o sshd está configurado com um único ListenAddress, as ligações a qualquer outro endereço local são recusadas mesmo que a interface esteja ativa. O mesmo se aplica a uma unidade de socket que possui a porta, e é por isso que a primeira verificação é sempre o que está realmente à escuta.

Compare os dois caminhos pelo endereço de destino, não pelo nome da interface. Um cliente liga-se a um endereço, e esse endereço tem de estar ligado antes de qualquer regra de firewall ser relevante.

Liste os endereços e os listeners

Antes de editar seja o que for, registe os endereços no anfitrião e os sockets que existem agora.

ip -br addr
ss -ltnp | grep ':22'

A lista de endereços mostra qual endereço privado é real e em que interface, enquanto a lista de sockets mostra se algo está ligado a ele. Um listener em 0.0.0.0:22 já aceita todos os endereços, pelo que uma nova ligação nada acrescenta. Um listener num único endereço específico explica a recusa de imediato. Se a porta pertence a uma unidade de socket e não ao daemon, a configuração do daemon não é a história completa.

Adicione a ligação e mantenha a antiga

O OpenSSH aceita várias entradas ListenAddress, pelo que o caminho VPN pode permanecer enquanto o privado é adicionado. Teste o ficheiro antes de o recarregar.

sshd -t
systemctl reload sshd

Um teste de configuração falhado deixa o daemon em execução intacto, e é exatamente isso que quer enquanto está ligado pelo caminho que está a editar. Mantenha a entrada existente, adicione o novo endereço local e confirme que o serviço recarrega sem interromper a sessão atual. Em instalações ativadas por socket, adicione o endereço à unidade de socket e recarregue essa unidade. Depois leia novamente a lista de listeners, porque uma ligação que nunca apareceu significa que foi editado o componente errado.

Verifique a nova sessão antes de fechar a antiga

Ligue-se ao novo endereço enquanto a sessão original ainda está aberta, usando saída detalhada para ver que endereço e chave foram usados. Mantenha a sessão original aberta até a verificação ter sucesso duas vezes.

ssh -v [email protected]

Leia as linhas de depuração para o endereço de destino e a chave de anfitrião apresentada. Confirme a impressão digital da chave de anfitrião contra um valor em que já confia, em vez de aceitar uma chave desconhecida porque a rede é descrita como privada. O novo destino precisa da sua própria entrada known_hosts, e isso é esperado. A antiga sessão de gestão só deve ser fechada quando o caminho privado funcionar.

O SSH protege o transporte, mas não torna duas redes equivalentes por si só. Decida se a confiança do trânsito privado corresponde aos dados antes de depender dele.