SSH remoto por VPN: o que o túnel não faz

Uma VPN dá a um servidor SSH um caminho privado e elimina a necessidade de um serviço público à escuta na porta 22. Ela não autentica o host, não autoriza o usuário e não decide quais contas podem entrar. Isso continua sendo tarefa do SSH. Se a VPN é a forma certa de chegar ao servidor depende de três condições, e o túnel é apenas uma das respostas possíveis.

O que o túnel muda e o que o SSH ainda decide

O túnel muda a alcançabilidade: quais endereços podem ser alcançados e a partir de onde. Ele não muda o que acontece depois que a conexão TCP se estabelece, quando o servidor apresenta uma chave de host e pede uma identidade de usuário.

Mantenha as duas camadas separadas na cabeça e na documentação. Um login de VPN prova quem pode usar a rede. Ele não diz nada sobre quais contas existem no alvo, e não é permissão para entrar em toda máquina alcançável.

Os modos de falha também são separados, e é isso que torna a separação útil durante um incidente.

Três condições que decidem o modelo de acesso

Primeiro, o servidor precisa ser alcançável por pessoas fora da sua rede? Se não, um caminho privado mais um bastion ou uma malha é o desenho menor. Segundo, o público de clientes consegue de fato executar o cliente VPN, incluindo os que estão em dispositivos gerenciados com restrições?

Terceiro, você precisa de controle por serviço ou por usuário? Uma VPN concede alcance de rede; o SSH concede acesso a contas. Se o requisito é que um terceirizado alcance um host e nada mais, isso é um requisito de autorização e o túnel sozinho não consegue expressá-lo.

Responda às três e o modelo se escolhe sozinho. Pule-as e você acaba expondo o SSH publicamente para evitar a distribuição do cliente.

Confirme o caminho privado antes de culpar o SSH

Conecte-se à VPN aprovada e use o nome ou endereço privado documentado do alvo. Depois verifique a rota selecionada, a permissão do gateway e o caminho de volta até o cliente. Um nome que resolve corretamente não é prova de que o endereço pega o túnel pretendido, porque prefixos locais e remotos sobrepostos podem enviar a requisição para outro lugar completamente. Vale a pena escrever essa distinção no runbook.

Se a conexão nunca se estabelece, confirme que o servidor está escutando na interface que você espera e que o firewall do host permite a origem que ele realmente vê. Um NAT no gateway pode reescrever essa origem, então uma lista de permissões escrita para o endereço de túnel do cliente pode nunca corresponder.

Essa incompatibilidade é a falha de SSH mais comum causada por si mesmo sobre uma VPN.

Leia a etapa da falha, não o erro combinado

Três etapas produzem três mensagens diferentes, e só uma delas é sobre credenciais.

Use o erro exato e o log do próprio servidor em vez de redefinir as credenciais de VPN e de SSH juntas. Redefinir as duas é como um diagnóstico de cinco minutos se torna um incidente de identidade de dois dias.

A saída detalhada mostra até que etapa você chegou:

ssh -vv [email protected]

Mantenha as chaves de host e a autorização intactas

Valide a chave de host pelo processo de confiança previsto, especialmente depois de uma troca de servidor. Um aviso inesperado de chave alterada é justamente a mensagem que você não deve descartar só porque a VPN conectou, porque um túnel privado não faz do destino a máquina que você pensa que é. Verifique a impressão digital contra uma fonte em que você confie independentemente da conexão.

No lado do servidor, confirme que a conta está autorizada e que o método de autenticação que você configurou é o que está sendo oferecido. Uma chave presente mas ignorada costuma ser um problema de permissões ou de configuração, e não de rede.

Limite o acesso ao serviço às identidades necessárias e mantenha um caminho de recuperação autorizado para mudanças de rede.