Resumen

  • El primer intercambio de claves produce K y un hash H; ese primer H, formado con el diálogo real de negociación, se convierte en el identificador de la conexión.
  • Un rekey puede sustituir algoritmos, claves de tráfico, vectores, contextos e incluso la clave de host, pero no cambia el identificador original de la sesión.
  • La autenticación de clave pública firma ese identificador junto con la solicitud exacta de usuario y servicio. Evita reproducir una firma en otra conexión, aunque no concede por sí sola permiso para abrir un shell o reenviar puertos.

Dos ritmos dentro de una conexión

Una sesión remota puede durar más que las claves que cifran sus paquetes. El usuario espera que una transferencia, una terminal o un túnel continúen; el operador espera renovar el material criptográfico antes de que envejezca demasiado.

Si cada renovación fuera una nueva sesión, los protocolos superiores tendrían que reconstruir su estado. Si la nueva clave se tratara como una identidad independiente, la autenticación realizada al principio quedaría sin un vínculo claro con el tráfico posterior.

RFC 4251 separó esos problemas. El transporte autentica al servidor y protege el flujo. Encima corre la autenticación del usuario. Finalmente, el protocolo de conexión multiplica canales lógicos para shells, subsistemas y reenvíos. La jerarquía permite cambiar el mecanismo protector sin fingir que todo lo situado encima acaba de nacer.

El identificador no viajaba como una etiqueta

Cliente y servidor envían SSH_MSG_KEXINIT con una cookie aleatoria y listas ordenadas de intercambio de claves, clave de host, cifrado, integridad y compresión. La negociación elige, bajo las reglas del método, la primera opción preferida por el cliente que ambos extremos comparten.

El método acordado calcula un secreto K y un hash de intercambio H. En el Diffie–Hellman original de SSH 2, H incorpora las cadenas de versión, los dos KEXINIT sin reinterpretar, la clave de host del servidor, los valores efímeros y el secreto compartido. No es un número que una parte pueda escribir y reclamar como autoridad.

Cambiar una oferta, una versión, una clave o un valor efímero cambia el transcript. Las dos cookies aportan imprevisibilidad y los dos paquetes de negociación impiden que un solo extremo nombre unilateralmente la conexión. El identificador tampoco es K: puede hacerse público sin revelar el secreto ni permitir fabricar protección válida.

El servidor firma H con su clave de host. Esa firma prueba que el poseedor de la clave privada firmó ese intercambio concreto. Falta todavía el vínculo entre clave y nombre de host. El cliente debe obtenerlo de su base conocida, de un certificado, de una huella comprobada o de otra política. Una firma correcta no corrige una asociación de confianza incorrecta.

El primer hash sobrevivía a los siguientes

RFC 4253 hace del primer H el session_id. Cada intercambio usa su K y su H para derivar protección, pero solo el primero fija la identidad de esta conexión.

En un rekey, cualquiera de las partes puede iniciar otra negociación. Pueden cambiar los algoritmos y la clave de host. Se calculan claves y vectores nuevos, y se reinician los contextos de cifrado y compresión al cruzar SSH_MSG_NEWKEYS. Sin embargo, cliente y servidor mantienen sus papeles y el identificador continúa siendo el hash inicial.

La permanencia tiene un alcance preciso. No dice que una clave de host inesperada sea aceptable, que el nuevo algoritmo sea fuerte ni que el rekey vaya a terminar bien. Solo evita que una renovación exitosa del transporte borre la identidad que usan autenticación y conexión.

Una reconexión no disfruta de esa continuidad. Al establecer otro transporte se crea otro primer intercambio y, por tanto, otro identificador. Una aplicación puede reanudar trabajo por su propio protocolo; no puede convertir esa reparación en la misma sesión criptográfica de SSH.

La firma del usuario incluía la pregunta completa

RFC 4252 tomó el identificador como prefijo de la prueba publickey. Después vienen el número SSH_MSG_USERAUTH_REQUEST, nombre de usuario, servicio, método, indicador booleano, algoritmo y clave pública.

Por eso una firma capturada en la conexión A no sirve en B: el primer hash es distinto. Tampoco se puede cambiar el usuario, el servicio o el algoritmo sin invalidarla. La prueba no declara “esta clave es buena en general”; declara que su poseedor aprobó esta solicitud dentro de esta conversación protegida.

El servidor todavía verifica cuestiones diferentes. Primero, si la firma corresponde a la clave. Segundo, si esa clave es aceptable para la cuenta reclamada. Tercero, si la política exige otro factor. Una operación criptográfica válida puede acabar en SSH_MSG_USERAUTH_FAILURE sin contradicción.

La autenticación basada en host añade el nombre y el usuario del sistema cliente a la misma construcción. La posesión de una clave de máquina tampoco reemplaza la comprobación de que esa máquina y esa persona pueden iniciar sesión.

Autenticarse no era obtener todas las facultades

Tras SSH_MSG_USERAUTH_SUCCESS, comienza el servicio solicitado. Aun así, la política local debe decidir qué acciones se permiten: shell interactivo, subsistema de archivos, reenvío de puerto, agente o destino concreto.

Muchas de esas preguntas ni siquiera existen durante la autenticación. El cliente presenta la solicitud de canal después. El identificador mantiene el contexto entre capas; no transmite una autorización ilimitada desde una capa anterior.

Por eso un registro que guarda session_id y “clave pública aceptada” solo demuestra una correlación. Sin las solicitudes de canal y sus veredictos, no prueba qué comando fue admitido, qué túnel se abrió ni qué datos se procesaron.

La agilidad cambió algoritmos, no responsabilidades

Los nombres de 2006 no podían quedar congelados. RFC 8332 añadió firmas RSA con SHA-256 y SHA-512 para autenticar servidores y clientes. Una clave RSA ya existente conservaba su formato mientras otro nombre seleccionaba el procedimiento de firma. Clave, algoritmo y contenido firmado seguían siendo piezas distintas.

RFC 9142 revisó luego las recomendaciones de KEX y apartó métodos basados en SHA-1. El primer intercambio podía modernizarse sin modificar el contrato de las capas: su hash continuaba fijando el contexto que las pruebas superiores nombran.

Eso no convierte un comienzo débil en fuerte. Si el cliente confió en la clave equivocada o aceptó un método impropio, conservar el identificador solo ata con precisión las acciones futuras a ese error inicial. La continuidad no es absolución.

Cada evidencia responde a una pregunta

El nombre de host expresa la intención del destino. La clave de host necesita una regla que la relacione con ese nombre. El hash describe un intercambio negociado. Su primera instancia identifica una conexión. La clave del usuario prueba posesión para una solicitud. La política local autoriza operaciones.

Llamar a todo “identidad SSH” destruye esa secuencia. Los RFC demuestran semántica y evolución de algoritmos; no miden si un cliente real verifica claves, si un servidor hace rekey, si desapareció SHA-1 ni si se ejecutó un comando.

El logro histórico fue una invariancia pequeña y útil. SSH dejó que las claves cambiaran sin que la conversación olvidara el intercambio que la había constituido. El hash no recibió poder general; recibió un trabajo de enlace.