Historia de SSH: de telnet a OpenSSH

Dónde comienza la historia de SSH

La historia de SSH comienza con contraseñas robadas. 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 podía leerla, y a principios de la década de 1990 ya había personas que 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 actualmente casi todo el mundo 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 escribe, incluida la contraseña, viaja como bytes sin cifrar que cualquier dispositivo situado en la ruta puede leer.

rlogin surgió en 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 desde un host concreto sin contraseña. El RFC incluye una sección llamada "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 los nombres de host, por lo que un compromiso de DNS (domain name system) o una dirección falsificada la anula.

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 cada trama y debían ignorar las tramas que no estaban dirigidas a ellos. Un equipo que dejaba de ignorarlas, que es lo que significa el modo promiscuo, veía el tráfico de los demás. Si además una universidad proporcionaba cuentas de shell a miles de estudiantes, una sola cuenta comprometida se convertía en un recolector de contraseñas para todo un departamento.

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

El 3 de febrero de 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 que utilizaban ponía la interfaz de red en modo promiscuo y registraba el comienzo 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 recomendaba a los sitios cambiar la contraseña de todas las cuentas accesibles a través de la red. Si se tiene en cuenta el funcionamiento de estos protocolos, el problema resulta evidente: la nueva contraseña atraviesa el mismo cable en texto claro la primera vez que se utiliza. No había ninguna solución dentro de telnet o rlogin, porque ninguno de los dos protocolos tenía un lugar donde incorporarla.

Por qué un ataque de sniffing en Helsinki produjo SSH

En 1995, la red de la Universidad Tecnológica de Helsinki sufrió un ataque de sniffing de contraseñas del tipo que había descrito 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 monitorizara el segmento no obtenía información útil. Además, el servidor demostraba su identidad con una clave, de modo que el cliente podía comprobar si se había conectado a la máquina correcta. Ese era el punto débil que la confianza de 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 exigía adoptar un nuevo hábito, no modificar 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 gratuita 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 había nada inadecuado en ello. Simplemente, la versión de SSH sobre la que podía basarse el resto del mundo dejó de evolucionar, mientras el desarrollo continuaba en un lugar que ese mundo no podía seguir. Las licencias determinan qué código perdura. Es 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 creó una bifurcación de OpenSSH en 1999

A comienzos 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 admitía el protocolo SSH 1.3.

El proyecto OpenBSD adoptó OSSH y lo reconstruyó. Según la propia explicación del 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 proyecto de sistema operativo pequeño terminó presente 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 tanto, el acceso remoto cifrado debía formar parte de ese sistema base y utilizar una licencia sin restricciones. El código auditado con una licencia sin restricciones era precisamente lo que también querían 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.

Después llegó la compatibilidad con la segunda versión del protocolo. 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 simple incremento 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 incluían 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 puede repararse acumula parches, y los parches introducen sus propios errores.

SSH-2 se definió en un grupo de trabajo del IETF llamado secsh y se publicó como 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 por separado. Gran parte del resto de esta historia consiste en aplicar 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 usar Diffie-Hellman. En SSH-1, el cliente elegía la clave de sesión y la enviaba cifrada con las claves RSA del servidor. Por ello, cualquiera que obtuviera posteriormente esas claves privadas podía descifrar una sesión grabada. Diffie-Hellman deriva un secreto nuevo para cada sesión que nunca se transmite. Así, grabar el tráfico y robar después la clave del host no permite obtener información útil. Esta propiedad se denomina secreto hacia adelante.

SSH-2 no comparte compatibilidad de protocolo con SSH-1. Por eso cambió el número de protocolo, en lugar de incrementarse el número decimal.

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

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

Mantenerlo como opción para equipos antiguos habría sido una decisión más compatible, pero el detector de CRC-32 explica por qué se rechazó esa opción. El desbordamiento sólo era accesible 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 puede alcanzarse.

Por qué la primera conexión SSH avisa sobre la clave de host

El cifrado indica que el tráfico es privado. No indica quién está al otro lado. Si un atacante se sitúa en la ruta y responde en lugar del servidor, se establece una sesión perfectamente cifrada con el atacante. Esto se denomina ataque de máquina en el medio. 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 con la que registró la última vez. Si quiere conocer el funcionamiento de la propia conexión, consulte qué sucede 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 almacenado. Si no coincide, se muestra el mensaje de advertencia más importante del programa:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 implica que la primera conexión sólo es tan segura como la red desde la que se realiza. Puede cerrar esa brecha. Lea 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 esto sólo resulta útil si utiliza DNSSEC. Otra opción es 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 acepta el aviso sin comprobarlo. Es importante reconocerlo.

Cómo las claves públicas relegaron las contraseñas

La autenticación mediante clave pública existía 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 aritmética. Cualquier servidor con el puerto 22 abierto en una dirección pública recibe intentos de inicio de sesión automatizados las 24 horas, 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 toda esa categoría de ataques, por lo que aparece en todas las listas de comprobación de hardening. También elimina el mecanismo alternativo que antes podía ayudarte cuando una clave fallaba, así que aprende a distinguir los distintos fallos que muestran Permission denied (publickey) antes de quedarte sin acceso. Prescindir de las contraseñas también implica acumular claves, y un agente que contiene una docena de ellas ofrece cada una por turnos hasta que el servidor alcanza su límite de intentos y cierra la conexión; por eso un inicio de sesión puede fallar con Too many authentication failures aunque la clave correcta esté cargada. La generación y rotación de claves se explica en Conceptos básicos de la gestión de claves SSH, y la configuración del servidor en Refuerzo de la seguridad de SSH en un VPS.

Por qué la lista de algoritmos de SSH cambia constantemente

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

Ed25519 llegó con 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 su nonce por firma de forma determinista, 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 antiguo formato de firma. 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á criptográficamente roto y se podían conseguir colisiones de prefijo elegido por menos de 50,000 USD. Si alguna vez has visto sign_and_send_pubkey: no mutual signature supported al conectarte a un servidor antiguo, este es el cambio responsable. Tu clave es válida. El algoritmo de firma que solicitó el otro extremo no lo es.

El mismo proceso se aplica ahora al intercambio de claves, esta vez antes de que exista la amenaza. El tráfico capturado hoy puede almacenarse y descifrarse años después por quien consiga primero un ordenador cuántico capaz, por lo que el acuerdo de claves tuvo que cambiar antes de que exista una máquina así. OpenSSH 9.0, el 8 de abril de 2022, convirtió en predeterminado un intercambio de claves híbrido: sntrup761x25519-sha512@openssh.com combina un algoritmo poscuántico con el intercambio X25519, por lo que el resultado no es más débil que la parte clásica si el algoritmo nuevo resulta deficiente. 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 convirtió en el valor predeterminado para el acuerdo de claves, y la página poscuántica del proyecto explica los motivos. 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á activada de forma predeterminada y se controla mediante la opción WarnWeakCrypto en ssh_config. En la práctica, su significado y las medidas que se deben tomar ante un servidor que la activa se explican en los valores predeterminados del intercambio de claves poscuántico de SSH.

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 sustituido: la comprobación de integridad, el intercambio de claves, los algoritmos de firma y la propia base de código. Esto sólo fue posible porque cada sustitución terminaba con una eliminación deliberada, y cada eliminación rompía algo para alguien.

Por eso, la seguridad de SSH depende sobre todo 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 permitía y seguirá negociando una configuración inferior 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 tocado durante tres años indica 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 la 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 esa é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 a nivel de red. SSH-1 era un único 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 separa 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. Así, el tráfico capturado sigue siendo confidencial aunque la clave de 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 se podía reutilizar libremente era ssh 1.2.12. A principios de 1999, Björn Grönvall recuperó esa versión como OSSH, y el equipo de OpenBSD creó OpenSSH a partir de OSSH. OpenSSH 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 los demás sistemas operativos distribuyeran la misma implementación mediante la rama portable.

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

Porque el cliente nunca había visto ese servidor y no tiene ninguna clave con la que comparar la recibida. El cifrado por sí solo no puede distinguir un servidor legítimo de 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 directamente. Compare la huella con la que haya obtenido desde la consola del proveedor o desde el propio servidor. Trate cualquier mensaje posterior REMOTE HOST IDENTIFICATION HAS CHANGED como un evento real hasta que pueda explicarlo.

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

Porque OpenSSH retira los algoritmos según 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 todavía funcionan, pero las firmas generadas con SHA-1 se deshabilitaron de forma predeterminada en OpenSSH 8.8 en septiembre de 2021. Al conectarse a un servidor antiguo, esto aparece como sign_and_send_pubkey: no mutual signature supported. Una clave Ed25519, disponible desde OpenSSH 6.5 en enero de 2014, evita ambos problemas.