Quen ve realmente o teu contrasinal SSH nunha VPN non fiable?

Pasa unha sesión SSH por unha VPN que non administras ti, e o contrasinal segue pertencendo ao servidor SSH, non á rede de en medio. Se o transporte ata un host verificado está ben protexido, un observador pasivo nesa ruta non obtén o contrasinal en forma lexible. Pero cambia unha condición e a resposta cambia: un host non verificado, unha lista de cifrados debilitada ou unha estación de traballo comprometida producen resultados distintos. Executa as comprobacións seguintes en orde e trata cada unha como unha condición de parada.

Nomea o destinatario antes de escribir nada

O campo do contrasinal viaxa dentro dunha mensaxe de autenticación, e esa mensaxe viaxa dentro do transporte cifrado. A confidencialidade é unha propiedade do transporte, o que significa que depende de ter negociado protección e de tela negociado co host que tiñas en mente. Esa segunda metade é a parte que a xente salta. Unha conexión cifrada cun impostor é confidencial e inútil ao mesmo tempo. O inicio de sesión na VPN non demostra nada sobre o host SSH, e a reputación do provedor non substitúe a comprobación da clave.

Mantén as dúas direccións separadas na cabeza. A clave do host responde a que servidor chegaches. A autenticación por contrasinal ou por clave responde a que usuario acepta o servidor. Mellorar a segunda nunca repara a primeira.

Comproba a identidade do host, o rexistro e a negociación

Comeza no cliente co rexistro que xa tes. Unha impresión dixital publicada comparada cunha fonte de confianza, e unha entrada de known_hosts que aínda coincide, danche a única proba que importa antes de que comece a autenticación.

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

No lado do servidor, imprime as impresións dixitais que pensas publicar en lugar de copialas de memoria. Distribuílas por fóra da canle é xustamente o punto; unha impresión dixital pegada desde a mesma canle de chat que o nome do host só demostra que ambas veñen do mesmo sitio.

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

Os algoritmos negociados saen da intersección de ambos os lados. Se unha configuración de cliente fixa un intercambio de claves obsoleto para chegar a un dispositivo antigo, esa elección aplícase a cada host co que fala, así que limítaa a ese host en lugar de facela global.

Le os métodos que o servidor acepta de verdade

Saber que métodos de autenticación permite un servidor diche para que serve o contrasinal. Un host que só acepta claves públicas non ten intercambio de contrasinais que protexer, e un host que aínda acepta contrasinais merece unha decisión deliberada e non un valor predeterminado herdado.

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

Pasar a un usuario á autenticación por clave quita o contrasinal dese usuario dese intercambio. Non fai segura unha estación de traballo comprometida nin fai inofensiva unha sesión remota non fiable. Son riscos distintos con controis distintos. Decide tamén sobre o reenvío de axente. Reenviar un axente a un host non fiable dá a ese host a capacidade de usar as túas claves mentres dura a sesión, e iso é unha exposición maior que a cuestión do contrasinal coa que empezou todo.

Trata un aviso de clave de host como un paso de incidente

Cando o cliente avisa de que a identificación do host cambiou, detente e verifica por unha canle que non pase pola mesma ruta de rede. Compara a impresión dixital coa consola do servidor ou co operador que o reconstruíu. Borrar a entrada antiga para silenciar o aviso é a única acción que debes rexeitar. Descarta a proba e converte unha posible interceptación nun inicio de sesión normal.

Se o host se reconstruíu lexitimamente, elimina a entrada obsoleta só despois de confirmar a nova impresión dixital, logo reconecta e volve comprobar a negociación. Rexistra o cambio coa data e o motivo, porque a seguinte persoa verá o mesmo aviso e necesita saber que se resolveu.

Que non cobre este manual

Un operador de VPN que observa o tráfico non é o mesmo que software con privilexios locais na túa máquina. O compromiso do punto final, unha extensión de navegador hostil ou un rexistrador de teclas están por debaixo de todo o que SSH pode negociar, e ningún túnel cambia iso. Se a estación de traballo é sospeitosa, segue o proceso de incidentes en lugar de probar o segredo reconectando por outra saída. Reconectar demostra que a ruta de rede cambiou e nada sobre o punto final.

Remata co caso ordinario: host verificado, transporte protexido, o método de autenticación que escolliches a propósito e ningún reenvío que non necesitases. Esa combinación é a resposta á pregunta do título, e son catro decisións en lugar de unha.