Quién creó OpenSSH: la historia real del software que protege casi todas las conexiones a un servidor, y por qué importa tanto

Las claves en 30 segundos

• SSH es anterior a OpenSSH. Tatu Ylönen escribió el primer SSH en la primavera de 1995, tras descubrir un sniffer de contraseñas en la red de su universidad, y publicó la versión 1.0 el 12 de julio de 1995.
• OpenSSH nace en 1999 de una versión vieja y libre. Parte del ssh 1.2.12 de Ylönen, la última con una licencia que permitía reutilizarlo, a través de OSSH, el proyecto con el que Björn Grönvall había rescatado ese código a principios de ese año.
• Fue un trabajo de equipo, y a contrarreloj. El código se importó en OpenBSD el 26 de septiembre de 1999 y salió como OpenSSH 1.2.2 con OpenBSD 2.6 el 1 de diciembre. La historia oficial nombra a seis personas: Theo de Raadt, Niels Provos, Markus Friedl, Bob Beck, Aaron Campbell y Dug Song.
• Theo de Raadt fue importante, pero no el autor único. Limpió el código para que fuera más fácil de auditar. El soporte de SSH 2 y del servidor SFTP es de Markus Friedl; la separación de privilegios, de Provos y Friedl; la versión para Linux, de Damien Miller, Philip Hands y otros.
• El proyecto sigue muy vivo. OpenSSH 10.6 salió el 6 de octubre de 2026, con firmas poscuánticas híbridas y la decisión de publicar más a menudo porque los fallos que encuentran las herramientas de IA los acaba encontrando también otra gente.

---

Si administras servidores, ssh es probablemente el comando que más tecleas al día. Entras en una máquina, despliegas con git push, lanzas un playbook de Ansible o copias una copia de seguridad con rsync, y en todos esos casos hay una sesión de OpenSSH debajo. Es tan ubicuo que se ha vuelto invisible, y lo invisible suele tener una historia mal contada.

La versión corta que circula dice que OpenSSH lo creó Theo de Raadt, el fundador de OpenBSD. No es exacto. El propio proyecto publica su historia, con nombres y fechas, y lo que cuenta es una cadena: un investigador finlandés, un desarrollador sueco que rescató una versión olvidada y un grupo de desarrolladores de OpenBSD que la reescribieron en dos meses para llegar a tiempo a una versión del sistema. A esa cadena se sumaron después quienes lo llevaron a Linux, que es donde lo usa casi todo el mundo.

Lo contamos aquí con las fechas comprobadas en las fuentes originales, y añadimos lo que suele faltar en estas historias: por qué SSH importa tanto y qué tiene que ver todo esto con el servidor que tienes en producción.

1995: un sniffer en la red de la universidad

En 1995, la forma normal de entrar en una máquina remota era telnet o rlogin, y la de mover ficheros, ftp. Los tres mandaban las contraseñas en claro por la red. Cualquiera con acceso a un segmento intermedio podía leerlas.

Eso fue exactamente lo que pasó en la red universitaria finlandesa. Según cuenta SSH Communications Security, la empresa que fundó Ylönen, alguien instaló un sniffer en un servidor conectado directamente a la red troncal, y cuando lo descubrieron tenía en su base de datos miles de usuarios y contraseñas. Tatu Ylönen, entonces investigador en la Universidad Tecnológica de Helsinki, se puso a estudiar criptografía para tener una forma segura de conectarse en remoto él mismo.

El resultado fue SSH, Secure Shell. El propio Ylönen ha contado los detalles: el 12 de julio de 1995 anunció la versión 1.0.0 a sus probadores y esa misma tarde la publicó en la lista cypherpunks y en varios grupos de noticias. Antes había escrito a la IANA para pedir un puerto. Eligió el 22 porque estaba libre y quedaba justo entre el de ftp (21) y el de telnet (23), los dos programas que quería sustituir. Ese número sigue siendo hoy el puerto al que apunta cualquier escáner de Internet.

De software libre a licencia restrictiva

El SSH de Ylönen se extendió muy deprisa, y con él cambió la licencia. La historia oficial de OpenSSH lo resume así: ssh 1.2.12 fue la última versión lo bastante libre para reutilizarla. Las siguientes llegaron con licencias cada vez más restrictivas. La primera prohibía hacer una versión para Windows o DOS. Las posteriores restringían el uso comercial y obligaban a las empresas a comprar una versión de pago a una compañía llamada Datafellows.

Había además un problema jurídico de fondo. Aquellas versiones incluían directamente la biblioteca matemática libgmp, que entonces se distribuía bajo la GPL, y el proyecto OpenSSH sostiene que eso convertía las versiones restrictivas en una violación de la GPL.

Para un sistema operativo libre como OpenBSD, que quería traer soporte de SSH de serie, aquello cerraba la puerta: no podía distribuir un programa con esas condiciones.

1999: Björn Grönvall y OSSH

A principios de 1999, Björn Grönvall redescubrió la vieja versión libre, la 1.2.12, y empezó a corregirle fallos. Llamó a su versión OSSH. Solo hablaba el protocolo SSH 1.3 y nunca llegó a soportar SSH 2. Según la historia de OpenSSH, se integró en algunos productos comerciales en Suecia, y Grönvall dejó de desarrollarlo cuando OpenSSH maduró.

Sin OSSH no habría habido OpenSSH tal y como lo conocemos. Fue el punto de partida concreto del que se hizo el fork, y ese crédito casi nunca aparece en la versión popular de la historia.

Dos meses de esprint: del 26 de septiembre al 1 de diciembre

Los desarrolladores de OpenBSD supieron de OSSH menos de dos meses antes de la salida de OpenBSD 2.6. Querían incluir SSH en esa versión, pero tenía que ser impecable. Decidieron hacer el fork de inmediato y aplicar el mismo proceso de auditoría de código que ya usaban en el resto del sistema.

El código se importó el 26 de septiembre de 1999. Dos meses después, muchos ficheros iban por la revisión 1.34 del control de versiones RCS, y algunos por la 1.66. El resultado salió como OpenSSH 1.2.2 dentro de OpenBSD 2.6, el 1 de diciembre de 1999: sin componentes con patentes ni licencias restrictivas en el propio código, con soporte para contraseñas de un solo uso (S/Key) y con cientos de cambios más.

Quién hizo qué

Esta es la parte que más se simplifica. La historia oficial reparte el trabajo de aquellos dos meses entre seis personas, cada una con una tarea concreta:

A ese grupo hay que añadir a quienes vinieron enseguida. Nada más salir la primera versión, Damien Miller, Philip Hands y otros empezaron a portarlo a Linux y a otros Unix. Damien Miller escribió además el cliente sftp, que llegó en la 2.5.0.

Así que la respuesta a «¿quién creó OpenSSH?» no es un nombre. Es Ylönen por el protocolo y el código original, Grönvall por rescatar la versión libre y el equipo de OpenBSD por convertirla en OpenSSH, cada uno con su parte.

Por qué se le atribuye solo a Theo de Raadt

Tiene una explicación sencilla. De Raadt fundó OpenBSD, es la cara pública del proyecto y lleva décadas siendo una voz muy visible, a menudo polémica, en las discusiones sobre seguridad. Cuando una historia necesita protagonista, se elige al más conocido.

El problema es que eso deja fuera el trabajo que hace funcionar el software. Lo que hoy permite conectarse por SSH 2, transferir ficheros por SFTP o aislar el proceso que habla con la red son contribuciones con autor conocido, y la historia del proyecto se toma la molestia de nombrarlos. No es un detalle de cortesía: en el software libre, quién hizo qué es también una forma de saber a quién preguntar y en quién confiar.

Dos árboles: OpenBSD y el «portable»

Del trabajo de portabilidad salió una decisión de arquitectura que sigue vigente y que explica algo que ves cada vez que ejecutas ssh -V. El equipo de OpenBSD consideraba que incluso el código original de SSH tenía demasiadas dependencias del sistema operativo. Para no meter esa complejidad en el núcleo, separaron el desarrollo en dos:

• OpenSSH a secas, que se desarrolla para OpenBSD y busca ser pequeño, seguro y fácil de mantener.
• OpenSSH portable, que mantiene un equipo aparte y añade el código necesario para funcionar en Linux, macOS, AIX, HP-UX y otros sistemas. La autenticación es justo donde más difieren los Unix entre sí, y ahí se concentra buena parte de ese código.

Por eso las versiones que instalan las distribuciones Linux llevan una p al final: OpenSSH_10.0p2, OpenSSH_9.6p1. La p es de portable. Y por eso, cuando aparece un fallo, conviene leer si afecta a las dos ramas o solo a la portable, como ocurrió con regreSSHion en 2024.

La cronología, de 1995 a hoy

Por qué SSH importa tanto

Decir que SSH «sirve para conectarse a un servidor» se queda muy corto. El protocolo resuelve tres cosas a la vez, y por eso acabó siendo la base de tantas herramientas:

1. Autentica al servidor. La primera vez que te conectas, el servidor te enseña su huella y tu cliente la guarda en known_hosts. Si otro día la huella cambia, el cliente se niega a seguir. Esa comprobación es la que impide que alguien se haga pasar por tu servidor.
2. Autentica al usuario con algo mejor que una contraseña: claves públicas, certificados firmados por una autoridad propia o llaves físicas FIDO2.
3. Cifra un canal sobre el que se puede montar casi cualquier cosa: una consola, una copia de ficheros, un túnel a un puerto, otra conexión SSH.

Lo tercero es lo que lo ha vuelto omnipresente. Buena parte de lo que un equipo técnico hace cada día va por SSH aunque no lo parezca:

Por eso es también uno de los servicios más atacados. El puerto 22 recibe intentos de acceso constantes en cualquier IP pública, y un servidor con contraseñas débiles y SSH abierto a Internet tiene muchas papeletas de acabar comprometido. No es un problema del protocolo; es la consecuencia de que sea la puerta principal.

Por qué importa que sea OpenSSH

SSH es el protocolo; OpenSSH es la implementación que usa casi todo el mundo. Viene de serie en las distribuciones Linux, en los BSD y en macOS, y desde 2018 es una característica opcional de Windows; en Windows Server 2025 ya viene instalado, aunque desactivado. Que la misma base de código esté en tantos sitios tiene dos caras.

La buena: las mejoras llegan a todos. Algunas de las que más han cambiado la seguridad de SSH salieron de este proyecto:

• La separación de privilegios (2002). El proceso que habla con la red y procesa datos de un desconocido corre sin privilegios y aislado; solo una parte mínima conserva los permisos de root. Si alguien encuentra un fallo en el código que parsea lo que llega de fuera, no obtiene root sin más. OpenBSD la cita entre sus innovaciones, y el concepto se extendió después a muchos otros programas del sistema.
• Valores por defecto que mejoran solos. El acceso de root con contraseña está cerrado por defecto desde OpenSSH 7.0 (2015). El protocolo SSH 1 desapareció en la 7.6 (2017). Y desde la 10.0 (abril de 2025) el intercambio de claves predeterminado es mlkem768x25519-sha256, híbrido poscuántico, pensado para que el tráfico que alguien grabe hoy no se pueda descifrar con un ordenador cuántico dentro de unos años.
• Un código pensado para auditarse. Es la herencia directa de lo que hizo De Raadt en 1999: código simple, para que los fallos se vean.

La mala: un fallo en OpenSSH afecta a millones de servidores a la vez. regreSSHion (CVE-2024-6387), que encontró Qualys en 2024, era una condición de carrera en sshd que reintroducía un fallo corregido en 2006 y permitía ejecutar código como root. Afectaba a la rama portable entre la 8.5p1 y la 9.7p1; OpenBSD no era vulnerable. La explotación demostrada en laboratorio requería de media entre 6 y 8 horas de conexiones continuas en sistemas Linux de 32 bits con glibc.

La versión de esta semana añade un aviso que merece leerse. En las notas de OpenSSH 10.6, el equipo explica que está recibiendo muchos informes de seguridad hechos con modelos de IA o con su ayuda, y que ha visto varios casos en los que un fallo detectado con IA lo encontraba después, por su cuenta, otro investigador. De ahí deducen que quien no reporta fallos a los proyectos libres probablemente también es capaz de encontrarlos, y que por eso van a publicar versiones con más frecuencia en lugar de esperar a la siguiente planificada. Traducido a operaciones: las actualizaciones de OpenSSH van a llegar más a menudo, y conviene no dejarlas acumular.

La propia 10.6 trae un ejemplo de por qué. Desactiva el codificador por diccionario LZ77 en la compresión de SSH, porque un trabajo de investigación de 2026 demuestra que se pueden recuperar secretos de un canal interactuando con el diccionario de compresión compartido desde otro canal de la misma sesión. También activa las firmas poscuánticas híbridas ssh-mldsa44-ed25519 y hace que sshd registre en el log cuándo un cliente usa un intercambio de claves que no es seguro frente a ataques cuánticos.

xz: la puerta trasera que no estaba en OpenSSH

En marzo de 2024, Andres Freund, ingeniero de Microsoft que trabaja en PostgreSQL, notó que las conexiones SSH a una máquina de pruebas con Debian inestable tardaban medio segundo más de lo normal. Tirando de ese hilo descubrió una puerta trasera en las versiones 5.6.0 y 5.6.1 de xz/liblzma, una biblioteca de compresión.

Se suele contar como «la puerta trasera de SSH», y no lo fue. El código malicioso estaba en xz. Llegaba a sshd por un camino indirecto: varias distribuciones parchean OpenSSH para que avise a systemd cuando arranca, ese parche enlaza con libsystemd, y libsystemd carga liblzma. OpenSSH tal como lo publica el proyecto no usa ni systemd ni xz. Las versiones estables de Debian, Ubuntu o Red Hat Enterprise Linux, además, no llegaron a incluir las versiones comprometidas: se detectó cuando aún estaba en ramas de pruebas.

La lección para quien opera servidores es doble. Primero, que la seguridad de un servicio depende de todo lo que enlaza, incluidos los parches que añade tu distribución. Segundo, que la confianza en el software libre se apoya en personas concretas: un mantenedor solo y agotado fue la puerta de entrada del ataque a xz, y un ingeniero que se fijó en medio segundo de más lo paró. Es la misma idea que recorre la historia de OpenSSH: el software que da seguridad lo sostiene gente con nombre y apellidos.

Qué hacer con esto en tu servidor

La historia tiene consecuencias prácticas. Cinco, en orden de importancia:

1. Actualiza OpenSSH con el resto del sistema, sin retrasos. Con el ritmo de publicaciones que anuncia el proyecto, una máquina que pasa meses sin parches acumula fallos conocidos. ssh -V en el cliente y sshd -V en el servidor te dicen qué versión tienes; la distribución decide qué correcciones lleva.
2. No fijes a mano los algoritmos de cifrado. Una línea Ciphers o KexAlgorithms copiada de una guía antigua congela el servidor y le impide recibir mejoras como el intercambio poscuántico. Lo explicamos con pruebas en la línea base de hardening para Debian y Ubuntu.
3. Claves, no contraseñas. Desactiva PasswordAuthentication y KbdInteractiveAuthentication, y comprueba el valor efectivo con sshd -T, porque un fichero de cloud-init puede reactivarlas sin que lo veas.
4. No expongas el puerto 22 a todo Internet si no hace falta. Un bastión, una VPN como WireGuard o una lista de IP permitidas reducen el ruido y el riesgo.
5. Revisa lo que heredas. En un servidor que no has montado tú, las claves en authorized_keys, las configuraciones en sshd_config.d/ y los usuarios con acceso son lo primero que hay que mirar. Tenemos una guía para auditar un servidor Linux heredado.

En Cloud Privado las plataformas que entregamos llevan el acceso SSH cerrado a claves, detrás de red privada y con actualizaciones de seguridad gestionadas. Si tienes servidores con SSH expuesto y no tienes claro quién puede entrar, es una buena conversación para empezar.

Preguntas frecuentes

¿Creó Theo de Raadt OpenSSH?

No él solo. Theo de Raadt fundó OpenBSD y participó en el desarrollo inicial de OpenSSH quitando código no portable para que fuera más fácil de leer y auditar. Pero OpenSSH lo hicieron en 1999 varios desarrolladores de OpenBSD a partir del código de Tatu Ylönen y del proyecto OSSH de Björn Grönvall.

¿Quién inventó SSH?

Tatu Ylönen, investigador de la Universidad Tecnológica de Helsinki, que lo escribió en la primavera de 1995 tras un robo masivo de contraseñas con un sniffer en la red universitaria finlandesa. Publicó la versión 1.0 el 12 de julio de 1995 y fundó después SSH Communications Security.

¿Qué aportó Björn Grönvall a OpenSSH?

A principios de 1999 rescató ssh 1.2.12, la última versión de Ylönen con una licencia libre, y empezó a corregirle fallos con el nombre de OSSH. OpenBSD hizo el fork de OpenSSH a partir de OSSH.

¿Qué significa la «p» en versiones como OpenSSH_9.6p1?

Que es la versión portable. OpenSSH se desarrolla para OpenBSD, y un equipo aparte le añade el código necesario para funcionar en Linux, macOS y otros sistemas. Las distribuciones Linux usan siempre la versión portable.

¿Por qué SSH usa el puerto 22?

Porque Ylönen lo pidió a la IANA en 1995: estaba libre y quedaba entre el 21 de ftp y el 23 de telnet, los dos programas que SSH venía a sustituir.

¿La puerta trasera de xz estaba en OpenSSH?

No. Estaba en la biblioteca de compresión xz/liblzma. Llegaba a sshd en algunas distribuciones Linux porque parchean OpenSSH para integrarlo con systemd, y libsystemd cargaba liblzma. OpenSSH tal como lo publica el proyecto no dependía de xz.

¿Cuál es la última versión de OpenSSH?

A 9 de octubre de 2026, OpenSSH 10.6, publicada el 6 de octubre. Las distribuciones suelen llevar una versión anterior con las correcciones de seguridad incorporadas, así que lo que cuenta es tener el sistema actualizado.

Fuentes

• OpenSSH, Project History: la fuente principal. Licencia de ssh 1.2.12, OSSH, la importación del 26 de septiembre de 1999, el reparto del trabajo entre los seis desarrolladores, la salida con OpenBSD 2.6, el portado a Linux, SSH 2 y SFTP.
• OpenSSH, Portable Release: la separación entre la versión de OpenBSD y la portable.
• OpenSSH, Goals: el objetivo del proyecto (que todos los sistemas incluyan SSH porque telnet y rlogin son inseguros), las diferencias entre SSH 1 y SSH 2, y la fecha en que SSH 2 fue usable.
• OpenSSH, Release Notes: fechas de las versiones 7.0, 7.6, 9.8, 10.0 y 10.6, regreSSHion, el intercambio poscuántico por defecto y el aviso sobre los informes de seguridad hechos con IA.
• OpenBSD, Innovations: la separación de privilegios de Provos y Friedl en marzo de 2002, publicada con OpenBSD 3.2.
• Tatu Ylönen en SSH Communications Security, SSH port: cómo consiguió el puerto 22 y la publicación de ssh 1.0 el 12 de julio de 1995.
• SSH Communications Security, What is SSH: el incidente del sniffer que dio origen a SSH.
• IETF, RFC 4251: The Secure Shell (SSH) Protocol Architecture (enero de 2006).
• Microsoft, OpenSSH for Windows overview: disponibilidad desde Windows 10 1809 y Windows Server 2019, y estado de instalación por versión.
• Qualys, regreSSHion: Remote Unauthenticated Code Execution in OpenSSH server (1 de julio de 2024).
• Andres Freund, backdoor in upstream xz/liblzma leading to ssh server compromise (oss-security, 29 de marzo de 2024): el aviso original, con la explicación de cómo llegaba a sshd a través de libsystemd.
• NIST, CVE-2024-3094: ficha de la vulnerabilidad de xz.