Historia de SSH: de telnet a OpenSSH

Dónde comienza la historia de SSH

La historia de SSH comienza con el robo de contraseñas. Antes de 1995, iniciar sesión en una máquina Unix remota significaba usar telnet o rlogin, y ambos enviaban la contraseña por la red como texto legible. Cualquiera que pudiera monitorizar el tráfico de red podía leerla, y a principios de la década de 1990 algunas personas ya lo hacían a gran escala.

SSH fue la respuesta de una persona a ese problema. Se escribió en 1995 y se distribuyó gratuitamente. Desde entonces, el protocolo se ha reconstruido una vez, y el programa que utiliza casi todo el mundo hoy es un fork de otro fork. Las fechas siguientes son importantes porque cada paso respondió a un fallo concreto.

Qué enviaban realmente telnet y rlogin

Telnet está definido en RFC 854, publicado en mayo de 1983 por Jon Postel y Joyce Reynolds. Describe una sesión de terminal transportada mediante TCP y no incluye ningún tipo de cifrado. Cada byte que se escribe, incluida la contraseña, viaja como bytes sin cifrar que cualquier dispositivo situado en la ruta puede leer.

rlogin surgió de Berkeley Unix y se documentó posteriormente en RFC 1282 (BSD Rlogin, B. Kantor, diciembre de 1991). Añadió algo peor que una contraseña legible: la confianza basada en el host. Se podía indicar a un servidor que aceptara conexiones de un host concreto sin ninguna contraseña. El RFC incluye una sección titulada "A Cautionary Tale" que afirma: "Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised." También señala que la confianza se basa en nombres de host, por lo que un compromiso de DNS (domain name system) o una dirección falsificada puede eludirla.

Ambos diseños eran adecuados para la red en la que surgieron. Las primeras redes Ethernet utilizaban un medio compartido: todos los equipos de un segmento recibían todas las tramas y debían ignorar las que no estaban dirigidas a ellos. Un equipo que dejaba de ignorarlas, que es lo que significa el modo promiscuo, podía ver el tráfico de los demás. Si además una universidad proporcionaba cuentas de shell a miles de estudiantes, una sola cuenta comprometida podía convertirse en un recolector de contraseñas de todo un departamento.

El aviso de 1994 que no incluía ninguna solución

El 3 February 1994, CERT publicó el aviso CA-94:01, "Ongoing Network Monitoring Attacks". Informaba de que intrusos habían capturado información de acceso de decenas de miles de sistemas en Internet. La herramienta utilizada ponía la interfaz de red en modo promiscuo y registraba el inicio de cada nueva sesión de telnet, rlogin y FTP, que es la parte que contiene el nombre de usuario y la contraseña.

CERT recomendó a los sitios cambiar la contraseña de todas las cuentas accesibles a través de la red. Si se considera esta recomendación junto con los protocolos, el problema es evidente: la nueva contraseña atraviesa el mismo enlace en texto sin cifrar la primera vez que se utiliza. No existía ninguna solución dentro de telnet o rlogin, porque ninguno de los dos protocolos tenía un lugar donde implementarla.

Por qué un ataque de escucha en Helsinki produjo SSH

En 1995, la red de la Universidad Tecnológica de Helsinki sufrió un ataque de captura de contraseñas del tipo descrito por CERT. Tatu Ylönen, un investigador de la universidad, escribió un reemplazo y lo publicó como freeware en julio de 1995. Lo llamó Secure Shell.

Dos decisiones de diseño fueron fundamentales. La sesión estaba cifrada, por lo que un atacante que escuchara en el segmento no obtenía información útil. Además, el servidor demostraba su identidad mediante una clave, de modo que el cliente podía comprobar si había llegado a la máquina correcta. Ese era el punto débil que la confianza basada en nombres de host de rlogin dejaba expuesto.

También se extendió porque los comandos coincidían con los que los usuarios ya escribían. ssh sustituía a rsh y rlogin, y scp sustituía a rcp. El cambio sólo exigía modificar un hábito, no el flujo de trabajo. A finales de 1995, la base de usuarios había alcanzado aproximadamente 20,000 usuarios en cincuenta países. En diciembre de ese año, Ylönen fundó SSH Communications Security para desarrollar y vender el software.

De una versión libre a un producto comercial

Cuando SSH se convirtió en un negocio, cambió la licencia del código fuente. Las versiones posteriores incluían condiciones que limitaban lo que otras personas podían hacer con el código, y la última versión que cualquiera podía reutilizar libremente fue ssh 1.2.12. No hay nada indebido en ello. Simplemente, la versión de SSH sobre la que el resto del mundo podía construir dejó de avanzar, mientras el desarrollo continuaba en un lugar al que ese mundo no podía acceder. Las licencias determinan qué código perdura, un patrón sobre el que conviene leer en cómo las licencias de código abierto dieron forma a la infraestructura moderna.

Por qué OpenBSD bifurcó OpenSSH en 1999

A principios de 1999, Björn Grönvall retomó aquella última versión libre y empezó a corregir sus errores. Su versión se llamó OSSH y sólo hablaba el protocolo SSH 1.3.

El proyecto OpenBSD adoptó OSSH y lo reconstruyó. Según el propio proyecto, Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell y Dug Song se encargaron de limpiar, auditar y ampliar el código. El resultado fue OpenSSH 1.2.2, que se incluyó en OpenBSD 2.6 el 1 de diciembre de 1999.

¿Por qué una bifurcación creada por un pequeño proyecto de sistema operativo terminó instalada en casi todas las máquinas? Por lo que OpenBSD necesitaba de ella. OpenBSD distribuye un sistema base auditado, diseñado para ser seguro con su configuración predeterminada. Por eso, el acceso remoto cifrado tenía que formar parte de ese sistema base y distribuirse con una licencia sin restricciones. El código auditado con una licencia sin restricciones era precisamente lo que también necesitaban los demás proveedores de sistemas operativos. Damien Miller, Philip Hands y otras personas iniciaron casi de inmediato una rama portable. De ahí procede el p de una versión como 10.5p1. OpenBSD desarrolla la versión limpia y la rama portable añade la integración necesaria para el resto de sistemas. La forma en que Unix se dividió en los sistemas que usamos hoy explica por qué esa integración es necesaria.

El soporte para la segunda versión del protocolo llegó después. OpenSSH 2.0 se incluyó en OpenBSD 2.7 el 15 de junio de 2000.

Por qué SSH-2 es un protocolo nuevo y no un aumento de versión

SSH-1 protegía la integridad del flujo cifrado con CRC-32, una suma de comprobación diseñada para detectar errores de transmisión, no para resistir a un atacante. En 1998, Ariel Futoransky y Emiliano Kargieman, de CORE SDI, demostraron las consecuencias. Con los modos de cifrado CBC o CFB y una comprobación CRC-32, un atacante que conozca tan sólo 16 bytes del texto plano puede insertar texto cifrado elegido que el receptor acepta como auténtico. Esto permite ejecutar comandos en el servidor.

El fallo estaba en el protocolo, por lo que no podía corregirse sin romper la compatibilidad. En su lugar, las implementaciones incorporaron un detector: código en un archivo llamado deattack.c que intentaba reconocer el ataque mientras ocurría. En febrero de 2001 se descubrió que el detector contenía su propio desbordamiento de enteros, CVE-2001-0144. Esto permitía la ejecución remota de código contra servidores y clientes que incluían el parche. Un diseño que no se puede reparar acumula parches, y los parches introducen sus propios errores.

SSH-2 se desarrolló en un grupo de trabajo del IETF llamado secsh y se publicó como una serie de RFC en enero de 2006: la arquitectura en RFC 4251, la capa de transporte en RFC 4253, la autenticación de usuarios en RFC 4252 y la capa de conexión en RFC 4254. La división en capas es la parte importante, porque permite sustituir cada capa de forma independiente. Gran parte del resto de esta historia consiste en realizar esa sustitución.

Destacan dos cambios. La integridad pasó de CRC-32 a un HMAC (código de autenticación de mensajes basado en hash) protegido con una clave derivada de un secreto compartido. Por tanto, un atacante que no pueda calcular el MAC no puede falsificar un paquete. Además, el acuerdo de claves pasó a utilizar Diffie-Hellman. En SSH-1, el cliente elegía la clave de sesión y la enviaba cifrada con las claves RSA del servidor. Cualquiera que obtuviera posteriormente esas claves privadas podía descifrar una sesión registrada. Diffie-Hellman deriva un secreto nuevo para cada sesión que nunca se transmite. Por eso, registrar el tráfico ahora y robar la clave del host más adelante no permite obtener ninguna información. Esta propiedad se denomina secreto hacia adelante.

SSH-2 no comparte compatibilidad en el cable con SSH-1. Por eso cambió el número en lugar del decimal.

Por qué se eliminó SSH-1 en lugar de repararlo

La eliminación se llevó a cabo durante tres versiones de OpenSSH. La versión 7.0, publicada el 11 de agosto de 2015, desactivó el protocolo 1 de forma predeterminada durante la compilación. La versión 7.4, publicada el 19 de diciembre de 2016, eliminó la compatibilidad del servidor con este protocolo. La versión 7.6, publicada el 3 de octubre de 2017, eliminó también el lado cliente, junto con sus opciones de configuración y su documentación.

Mantenerlo como opción para equipos antiguos habría sido una decisión más compatible, pero el detector CRC-32 explica por qué se rechazó esa opción. El desbordamiento sólo era alcanzable porque el código del protocolo 1 estaba incluido en la compilación y se encontraba en una ruta que la mayoría de los administradores consideraba inactiva en sus sistemas. El código incluido en el software puede alcanzarse. El código eliminado no.

Por qué la primera conexión SSH advierte sobre la clave del host

El cifrado indica que el tráfico es privado. No indica quién está al otro lado. Si un atacante se coloca en la ruta y responde en lugar de su servidor, obtiene una sesión perfectamente cifrada con usted. Eso se denomina ataque de intermediario. SSH lo evita mediante una clave de host: el servidor demuestra que posee la parte privada de un par de claves y el cliente comprueba esa clave frente a la que registró la última vez. Si quiere conocer los detalles de la propia conexión, consulte qué ocurre al abrir una conexión SSH.

En la primera conexión no existe una conexión anterior. Por tanto, el cliente no tiene nada con lo que comparar y debe preguntarle:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Responder yes guarda esa clave en ~/.ssh/known_hosts. En cada conexión posterior se compara con el valor guardado. Si no coincide, el programa muestra su advertencia más importante:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

La interpretación correcta de ese primer aviso es que el protocolo reconoce su único momento débil. La confianza en el primer uso significa que la primera conexión sólo es tan segura como la red desde la que la realiza. Puede reducir ese riesgo. Consulte la huella digital en la consola de su proveedor o en el registro de compilación del servidor antes de conectarse. Publíquela en DNS como un registro SSHFP (RFC 4255), aunque sólo resulta útil si utiliza DNSSEC. También puede firmar las claves de host con su propia autoridad certificadora (CA), para que los clientes confíen en la CA y no en cada clave individual. En la práctica, la mayoría de las personas acepta el aviso sin comprobarlo. Conviene reconocerlo claramente.

Cómo las claves públicas desplazaron a las contraseñas

La autenticación mediante clave pública estaba disponible desde las primeras versiones de SSH, pero tardó años en convertirse en la práctica habitual. El mecanismo es asimétrico: el cliente demuestra que posee una clave privada firmando un desafío, y la clave privada nunca sale del cliente. Una contraseña funciona al contrario. Aunque SSH la transporta dentro del canal cifrado, el servidor recibe el secreto real. Por tanto, un servidor comprometido u hostil termina teniendo algo que puede reutilizar contra usted en otros servicios.

La segunda razón es matemática. Cualquier servidor con el puerto 22 abierto en una dirección pública recibe intentos de inicio de sesión automatizados durante todo el día, y una contraseña es una cadena que se puede adivinar. Una clave no se puede adivinar en la práctica. Configurar PasswordAuthentication no elimina por completo esa categoría de ataques, por lo que aparece en todas las listas de comprobación de hardening. La generación y rotación de claves se explican en Conceptos básicos de la gestión de claves SSH, y la configuración del servidor en reforzar la seguridad de SSH en un VPS.

Por qué la lista de algoritmos de SSH sigue cambiando

Un protocolo por capas permite retirar algoritmos sin crear un protocolo nuevo. OpenSSH ha aprovechado esa flexibilidad de forma constante, y las fechas de las versiones muestran el ritmo.

Ed25519 llegó en OpenSSH 6.5, el 30 de enero de 2014, junto con el cifrado chacha20-poly1305 y un formato de clave privada protegido por bcrypt. Las firmas Ed25519 derivan de forma determinista el nonce de cada firma, por lo que un generador de números aleatorios débil durante la firma no puede filtrar la clave privada. Así es exactamente como se han recuperado claves privadas DSA y ECDSA en incidentes reales.

DSA siguió el camino contrario. OpenSSH 7.0 deshabilitó ssh-dss las claves de host y de usuario en tiempo de ejecución en 2015, porque el algoritmo está limitado a una clave privada de 160 bits y a SHA-1. La versión 9.8, el 1 de julio de 2024, deshabilitó DSA en tiempo de compilación. La versión 10.0, el 9 de abril de 2025, lo eliminó, en palabras del proyecto, "completando el proceso de obsolescencia que comenzó en 2015". Diez años desde su deshabilitación hasta su eliminación.

RSA no desapareció, pero sí lo hizo su formato de firma antiguo. OpenSSH 8.8, el 26 de septiembre de 2021, dejó de aceptar de forma predeterminada firmas RSA realizadas con SHA-1. Las notas de la versión indican claramente el motivo: SHA-1 está comprometido desde el punto de vista criptográfico, y era posible conseguir colisiones con prefijo elegido por menos de 50.000 USD. Si alguna vez ha visto sign_and_send_pubkey: no mutual signature supported al conectarse a un servidor antiguo, este es el cambio correspondiente. Su clave está bien. El algoritmo de firma que solicitó el otro extremo no lo está.

El mismo proceso se aplica ahora al intercambio de claves, esta vez por delante de la amenaza. El tráfico capturado hoy puede almacenarse y descifrarse años después por quien primero disponga de un ordenador cuántico capaz, por lo que el acuerdo de claves tuvo que cambiar antes de que exista una máquina de ese tipo. OpenSSH 9.0, el 8 de abril de 2022, estableció como predeterminado un intercambio de claves híbrido: sntrup761x25519-sha512@openssh.com combina un algoritmo poscuántico con el intercambio X25519, de modo que el resultado no es más débil que la parte clásica si el nuevo algoritmo resulta defectuoso. OpenSSH 9.9, el 19 de septiembre de 2024, añadió mlkem768x25519-sha256, basado en ML-KEM (mecanismo de encapsulación de claves basado en retículos), estandarizado por NIST en 2024. OpenSSH 10.0 lo estableció como predeterminado para el acuerdo de claves, y la página poscuántica del proyecto explica el razonamiento. OpenSSH 10.1, el 6 de octubre de 2025, comenzó a mostrar una advertencia cuando el otro extremo no puede usarlo:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

Esta advertencia está habilitada de forma predeterminada y se controla mediante la opción WarnWeakCrypto en ssh_config. Su significado práctico y las medidas que debe tomar ante un servidor que la activa se explican en los valores predeterminados del intercambio de claves SSH poscuántico.

Qué significa este historial para el servidor que tiene delante

El comando que escribe apenas ha cambiado desde 1995. Casi todo lo que hay debajo se ha reemplazado: la comprobación de integridad, el intercambio de claves, los algoritmos de firma y el código base. Esto sólo fue posible porque cada reemplazo terminaba con una eliminación deliberada, y cada eliminación rompía algo para alguien.

Por eso, la seguridad de SSH depende principalmente de su versión. Los valores predeterminados contienen las decisiones sobre qué algoritmos se ofrecen, cuáles se rechazan y qué advertencias se muestran. Un servidor antiguo sigue ofreciendo todo lo que su versión todavía permitía y seguirá negociando hacia algoritmos más antiguos para adaptarse a un cliente antiguo. En agosto de 2026, la versión actual es OpenSSH 10.5, publicada el 11 de agosto de 2026. La distancia entre esa versión y la instalada en una máquina que nadie ha actualizado en tres años determina la magnitud del problema. Comprobarla forma parte de los primeros diez minutos en un VPS nuevo.

FAQ

¿Quién creó SSH y por qué?

Tatu Ylönen, investigador de Helsinki University of Technology, escribió SSH en 1995 después de un ataque de captura de contraseñas en la red de la universidad. Las herramientas de inicio de sesión remoto de aquella época, telnet y rlogin, enviaban las contraseñas por la red como texto legible. Por tanto, cualquiera que monitorizara un segmento compartido podía recopilar las credenciales mientras circulaban. Publicó el programa como freeware en julio de 1995. A finales de ese año tenía aproximadamente 20,000 usuarios en cincuenta países y, en diciembre de 1995, fundó SSH Communications Security.

¿Cuál es la diferencia entre SSH-1 y SSH-2?

Son protocolos diferentes y no son compatibles por cable. SSH-1 era un protocolo monolítico que usaba CRC-32 para la integridad y hacía que el cliente enviara una clave de sesión cifrada con las claves RSA del servidor. SSH-2 divide el trabajo en una capa de transporte, una capa de autenticación y una capa de conexión (RFCs 4251 a 4254, enero de 2006). Usa un HMAC para la integridad y deriva las claves de sesión con Diffie-Hellman. Por tanto, el tráfico capturado sigue siendo privado aunque la clave del host sea robada posteriormente. SSH-1 se eliminó de OpenSSH por etapas, hasta finalizar con la versión 7.6 en octubre de 2017.

¿Por qué OpenSSH sustituyó la implementación original de SSH?

El desarrollo de la implementación original pasó a un producto comercial con una licencia restrictiva, y la última versión que podía reutilizarse libremente era ssh 1.2.12. A comienzos de 1999, Björn Grönvall recuperó esa versión como OSSH, y el equipo de OpenBSD bifurcó OSSH para crear OpenSSH, que se incluyó en OpenBSD 2.6 el 1 de diciembre de 1999. OpenBSD necesitaba código auditado con una licencia sin restricciones para su sistema base. Esas dos propiedades permitieron que todos los demás sistemas operativos distribuyeran la misma implementación mediante la rama portable.

¿Por qué SSH pregunta por la clave del host la primera vez que me conecto?

Porque el cliente nunca ha visto antes ese servidor y no tiene ninguna clave con la que comparar la suya. El cifrado por sí solo no puede distinguir entre un servidor legítimo y una máquina situada en medio de la ruta. Por eso SSH identifica los servidores mediante su clave y registra lo que ha visto en ~/.ssh/known_hosts. La primera conexión es el único momento en que no hay un valor almacenado que comprobar. Por eso el cliente le pregunta a usted. Compare la huella digital con una obtenida desde la consola del proveedor o desde el propio servidor. Trate cualquier mensaje posterior REMOTE HOST IDENTIFICATION HAS CHANGED como un incidente real hasta que pueda explicar la causa.

¿Por qué algunas claves SSH antiguas dejan de funcionar después de una actualización?

Porque OpenSSH retira los algoritmos conforme a un calendario publicado. Las claves DSA (ssh-dss) se deshabilitaron de forma predeterminada en OpenSSH 7.0 en 2015 y se eliminaron por completo en OpenSSH 10.0 el 9 de abril de 2025. Las claves RSA siguen funcionando, pero las firmas realizadas con SHA-1 se deshabilitaron de forma predeterminada en OpenSSH 8.8 en septiembre de 2021. Esto aparece como sign_and_send_pubkey: no mutual signature supported al conectarse a un servidor antiguo. Una clave Ed25519, disponible desde OpenSSH 6.5 en enero de 2014, evita ambos problemas.