¿Quién ve realmente tu contraseña SSH en una VPN no confiable?

Pasa una sesión SSH por una VPN que no administras tú, y la contraseña sigue perteneciendo al servidor SSH, no a la red de en medio. Si el transporte hasta un host verificado está bien protegido, un observador pasivo en esa ruta no obtiene la contraseña en forma legible. Pero cambia una condición y la respuesta cambia: un host no verificado, una lista de cifrados debilitada o una estación de trabajo comprometida producen resultados distintos. Ejecuta las comprobaciones siguientes en orden y trata cada una como una condición de parada.

Nombra al destinatario antes de escribir nada

El campo de contraseña viaja dentro de un mensaje de autenticación, y ese mensaje viaja dentro del transporte cifrado. La confidencialidad es una propiedad del transporte, lo que significa que depende de haber negociado protección y de haberla negociado con el host que tenías en mente. Esa segunda mitad es la parte que la gente se salta. Una conexión cifrada con un impostor es confidencial e inútil a la vez. El inicio de sesión en la VPN no demuestra nada sobre el host SSH, y la reputación del proveedor no sustituye la comprobación de la clave.

Mantén las dos direcciones separadas en la cabeza. La clave del host responde a qué servidor llegaste. La autenticación por contraseña o por clave responde a qué usuario acepta el servidor. Mejorar la segunda nunca repara la primera.

Comprueba la identidad del host, el registro y la negociación

Empieza en el cliente con el registro que ya tienes. Una huella publicada comparada con una fuente de confianza, y una entrada de known_hosts que todavía coincide, te dan la única prueba que importa antes de que empiece la autenticación.

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

En el lado del servidor, imprime las huellas que piensas publicar en lugar de copiarlas de memoria. Distribuirlas por fuera del canal es justamente el punto; una huella pegada desde el mismo canal de chat que el nombre del host solo demuestra que ambas vinieron del mismo sitio.

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

Los algoritmos negociados salen de la intersección de ambos lados. Si una configuración de cliente fija un intercambio de claves obsoleto para llegar a un dispositivo antiguo, esa elección se aplica a cada host con el que habla, así que limítala a ese host en lugar de hacerla global.

Lee los métodos que el servidor acepta de verdad

Saber qué métodos de autenticación permite un servidor te dice para qué sirve la contraseña. Un host que solo acepta claves públicas no tiene intercambio de contraseñas que proteger, y un host que todavía acepta contraseñas merece una decisión deliberada y no un valor predeterminado heredado.

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

Pasar a un usuario a la autenticación por clave quita la contraseña de ese usuario de ese intercambio. No hace segura una estación de trabajo comprometida ni hace inofensiva una sesión remota no confiable. Son riesgos distintos con controles distintos. Decide también sobre el reenvío de agente. Reenviar un agente a un host no confiable da a ese host la capacidad de usar tus claves mientras dura la sesión, y eso es una exposición mayor que la cuestión de la contraseña con la que empezó todo.

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

Cuando el cliente avisa de que la identificación del host ha cambiado, detente y verifica por un canal que no pase por la misma ruta de red. Compara la huella con la consola del servidor o con el operador que lo reconstruyó. Borrar la entrada antigua para silenciar el aviso es la única acción que debes rechazar. Descarta la prueba y convierte una posible interceptación en un inicio de sesión normal.

Si el host se reconstruyó legítimamente, elimina la entrada obsoleta solo después de confirmar la nueva huella, luego reconecta y vuelve a comprobar la negociación. Registra el cambio con la fecha y el motivo, porque la siguiente persona verá el mismo aviso y necesita saber que se resolvió.

Qué no cubre este manual

Un operador de VPN que observa el tráfico no es lo mismo que software con privilegios locales en tu máquina. El compromiso del punto final, una extensión de navegador hostil o un registrador de teclas están por debajo de todo lo que SSH puede negociar, y ningún túnel cambia eso. Si la estación de trabajo es sospechosa, sigue el proceso de incidentes en lugar de probar el secreto reconectando por otra salida. Reconectar demuestra que la ruta de red cambió y nada sobre el punto final.

Termina con el caso ordinario: host verificado, transporte protegido, el método de autenticación que elegiste a propósito y ningún reenvío que no necesitaras. Esa combinación es la respuesta a la pregunta del título, y son cuatro decisiones en lugar de una.