Quem vê realmente a sua senha SSH numa VPN não confiável?

Passe uma sessão SSH por uma VPN que você não administra, e a senha continua pertencendo ao servidor SSH, não à rede no meio. Se o transporte até um host verificado estiver bem protegido, um observador passivo nesse caminho não obtém a senha em forma legível. Mas mude uma condição e a resposta muda: um host não verificado, uma lista de cifras enfraquecida ou uma estação de trabalho comprometida produzem resultados diferentes. Execute as verificações abaixo em ordem e trate cada uma como condição de parada.

Nomeie o destinatário antes de digitar qualquer coisa

O campo da senha viaja dentro de uma mensagem de autenticação, e essa mensagem viaja dentro do transporte cifrado. A confidencialidade é uma propriedade do transporte, o que significa que depende de ter negociado proteção e de a ter negociado com o host que você pretendia. É exatamente essa segunda metade que as pessoas pulam. Uma conexão cifrada para um impostor é confidencial e inútil ao mesmo tempo. O login na VPN não prova nada sobre o host SSH, e a reputação do provedor não substitui a verificação da chave.

Mantenha as duas direções separadas na cabeça. A chave do host responde a qual servidor você chegou. A autenticação por senha ou por chave responde a qual usuário o servidor aceita. Melhorar a segunda nunca conserta a primeira.

Verifique a identidade do host, o registro e a negociação

Comece no cliente com o registro que você já tem. Uma impressão digital publicada e comparada com uma fonte confiável, e uma entrada de known_hosts que ainda corresponde, dão a única prova que importa antes de a autenticação começar.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

No lado do servidor, imprima as impressões digitais que pretende publicar em vez de copiá-las de memória. Distribuí-las fora do canal é justamente o ponto; uma impressão digital colada do mesmo canal de conversa que o nome do host só prova que ambas vieram do mesmo lugar.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Os algoritmos negociados vêm da interseção dos dois lados. Se uma configuração de cliente fixa uma troca de chaves obsoleta para alcançar um dispositivo antigo, essa escolha vale para cada host com que ele fala, então limite-a a esse host em vez de torná-la global.

Leia os métodos que o servidor realmente aceita

Saber quais métodos de autenticação um servidor permite diz para que serve a senha. Um host que só aceita chaves públicas não tem troca de senhas a proteger, e um host que ainda aceita senhas merece uma decisão deliberada em vez de um padrão herdado.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Passar um usuário para autenticação por chave remove a senha desse usuário daquela troca. Isso não torna uma estação de trabalho comprometida segura, nem torna uma sessão remota não confiável inofensiva. São riscos diferentes com controles diferentes. Decida também sobre o encaminhamento de agente. Encaminhar um agente para um host não confiável dá a esse host a capacidade de usar suas chaves enquanto a sessão durar, e isso é uma exposição maior do que a questão da senha com que tudo começou.

Trate um aviso de chave de host como um passo de incidente

Quando o cliente avisa que a identificação do host mudou, pare e verifique por um canal que não passe pelo mesmo caminho de rede. Compare a impressão digital com o console do servidor ou com o operador que o reconstruiu. Apagar a entrada antiga para silenciar o aviso é a única ação que você deve recusar. Ela descarta a prova e transforma uma possível interceção num login normal.

Se o host foi reconstruído legitimamente, remova a entrada obsoleta só depois de a nova impressão digital ser confirmada, reconecte e verifique a negociação novamente. Registre a mudança com a data e o motivo, porque a próxima pessoa verá o mesmo aviso e precisa saber que foi resolvido.

O que este guia não cobre

Um operador de VPN que observa o tráfego não é a mesma coisa que software com privilégios locais na sua máquina. O comprometimento do ponto final, uma extensão de navegador hostil ou um registrador de teclas estão abaixo de tudo o que o SSH pode negociar, e nenhum túnel muda isso. Se a estação de trabalho é suspeita, siga o processo de incidente em vez de testar o sigilo reconectando por outra saída. Reconectar prova que o caminho de rede mudou e nada sobre o ponto final.

Termine com o caso comum: host verificado, transporte protegido, o método de autenticação que você escolheu de propósito e nenhum encaminhamento de que não precisasse. Essa combinação é a resposta à pergunta do título, e são quatro decisões em vez de uma.