SSH3 - un shell seguro más rápido y completo que usa HTTP/3

• SSH3 es un protocolo de shell seguro de nueva generación que funciona sobre HTTP/3 y mejora de forma significativa la velocidad de establecimiento de sesión frente al SSHv2 tradicional
• Forma un canal seguro mediante QUIC y TLS 1.3, y soporta esquemas modernos de autenticación como OAuth 2.0 y OpenID Connect
• Puede ocultar el servidor detrás de una ruta secreta, por lo que resiste mejor ataques como el escaneo de puertos, y además ofrece nuevas funciones como reenvío de puertos UDP y multipath de QUIC
• Ya adoptó varias funciones clave de OpenSSH, pero por ahora está en etapa experimental, así que no se recomienda desplegarlo en entornos reales de producción
• Como mucha gente considera que el nombre SSH3 no es adecuado, el borrador de estandarización cambió a “Remote Terminals over HTTP/3” y el cambio de nombre sigue en proceso

---

Resumen del proyecto SSH3 y su importancia

• SSH3 es una solución de código abierto que rediseña el protocolo SSH existente para adaptarlo a HTTP/3 y a tecnologías web modernas
  • Reconfigura la semántica del protocolo de conexión SSH existente (RFC4254) sobre HTTP/3 Extended CONNECT y un canal QUIC+TLS 1.3
• Fue propuesto como borrador de Internet del IETF, draft-michel-remote-terminal-http3, y ofrece varias ventajas como reducir mucho la velocidad de establecimiento de sesión y ampliar los métodos modernos de autenticación
• Frente a otras implementaciones de SSH, se distingue por ideas innovadoras como el uso de QUIC y la configuración de servidor oculto

Funciones y características principales

• Establecimiento rápido de sesión
  • Mientras que una conexión SSHv2 tradicional requiere en promedio entre 5 y 7 viajes de ida y vuelta de red, SSH3 solo necesita 3 rondas, reduciendo mucho la latencia percibida por el usuario
  • La latencia de escritura de teclas se mantiene en un nivel similar al actual
• Seguridad reforzada
  • Basado en TLS 1.3, QUIC y autenticación HTTP, aprovecha protocolos de seguridad ya validados y usados en comercio electrónico y banca por internet
  • Soporta autenticación con clave pública basada en RSA y EdDSA/ed25519, además de métodos diversos como OAuth 2.0 y OpenID Connect
  • También permite iniciar sesión con cuentas de Google, Microsoft y Github
• Función para ocultar el servidor
  • El servidor puede colocarse detrás de una URL secreta específica (por ejemplo: https://192.0.2.0:443/M3MzkxYWMx...) y responder solo cuando las solicitudes de autenticación lleguen a esa URL
  • A las demás solicitudes devuelve 404 Not Found, impidiendo que atacantes o crawlers en internet detecten la existencia del servidor
  • Aun así, la ruta secreta no reemplaza la autenticación, por lo que se recomienda usar siempre un mecanismo adicional de autenticación, como clave pública, contraseña u OIDC
• Proyecto experimental en desarrollo continuo
  • Por su estructura, requiere una verificación rigurosa y confiable de seguridad, y no se recomienda introducirlo en servidores de producción
  • Actualmente recopila retroalimentación de la comunidad en entornos de prueba o redes cerradas
• Compatibilidad con OpenSSH y funciones adicionales
  • Soporta parseo de ~/.ssh/authorized_keys y known_hosts, integración con ssh-agent, reenvío de puertos TCP/UDP y Proxy Jump
  • El soporte de reenvío UDP permite acceso a servicios basados en UDP como DNS, RTP y QUIC, usando una ruta de QUIC datagram
  • Ofrece autenticación de servidor a nivel HTTPS mediante certificados X.509
  • Autenticación sin llaves (Keyless): con OpenID Connect es posible conectarse sin copiar claves públicas, usando solo SSO corporativo o cuentas externas como Google o GitHub

Conclusión

• SSH3 es un proyecto experimental de código abierto que hace evolucionar el entorno SSH al incorporar protocolos de red y autenticación modernos
• Refuerza de forma importante la velocidad, la flexibilidad y la seguridad, pero antes de una validación suficiente conviene ser prudente con su uso en producción
• Ofrece una experiencia de usuario similar a OpenSSH y también incorpora abundantes funciones nuevas
• Con una evaluación de seguridad adecuada y participación de la comunidad, tiene potencial para consolidarse como la próxima generación de SSH

[GN⁺]

Opiniones en Hacker News

• La verdad, el nombre ssh3 no me gustó nada, así que me alegró ver en la parte superior del repo que dice: “SSH3 cambiará de nombre. Por ahora funciona como el protocolo de conexión SSH (RFC4254) sobre HTTP/3 Extended Connect, pero requiere muchos cambios y es demasiado distinto del SSH existente como para integrarse fácilmente. El borrador de la especificación ya se cambió a ‘Remote Terminals over HTTP/3’, y necesitamos tiempo para pensar en un mejor nombre permanente”
  • Ese nombre se siente tan fuera de lugar como si alguien hubiera creado un repo llamado “Windows 12” o “Linux 7”
  • Propongo algo como Secure Hypertext Interactive TTY en lugar de SSH3
  • Pensé en SSH/3 (como mezcla de SSH + HTTP/3)
  • Este thread es una verdadera obra maestra de discusión de bike-shedding
  • También pensé que algo como SSH2/3 podría funcionar, porque en su mayoría es SSH2 pero montado sobre HTTP/3
• SSH sí es lento, y en mi experiencia el mayor cuello de botella está en el establecimiento de la sesión. Ya sea por PAM o por la política de OpenBSD, da igual si reutilizas una conexión SSH o creas una nueva: cada vez la fase de setup de la sesión es terriblemente lenta. En sesiones largas no importa tanto, pero incluso para ejecutar un solo comando sencillo siempre hay sobrecarga; por eso nunca me convenció el rendimiento de Ansible y terminé haciendo mi propio mini ansible para ejecutar comandos remotos sin la sobrecarga de sesión
• Dudé con eso de “¿de verdad es más rápido que SSH tradicional?”, pero al leer el README entendí que solo acelera la fase de establecimiento de conexión y que, después de conectar, la velocidad real es la misma. Aun así, ya me parece una mejora válida
  • En realidad, no es más rápido en ese sentido. Cuando reenvías tráfico de varios puertos sobre una sola conexión SSH aparece bloqueo por head-of-line, y los protocolos QUIC/HTTP3 pueden resolver ese problema
  • Apostaría a que este protocolo será muchísimo más rápido que SSH en enlaces de alta latencia, porque al estar basado en UDP puede enviar grandes volúmenes de datos de forma continua sin esperar ack, así que al hacer scp de archivos grandes desde distintas partes del mundo esperaría una mejora importante
  • Sobre una VPN sí podría ser realmente más rápido, porque evita la trampa de “TCP dentro de TCP”
  • La gran ventaja principal de HTTP/3 y QUIC en general es precisamente la reducción de round trips frente a lo anterior, así que encaja totalmente con que el establecimiento de conexión sea más rápido
• La explicación era: “SSHv2 necesita unas 5 a 7 idas y vueltas para inicializar la sesión, mientras que SSH3 solo necesita 3. Durante la sesión real, la latencia de entrada (tiempo entre teclear y ver respuesta) es la misma”. Como usuario, la velocidad de conexión nunca me ha preocupado tanto como para verlo atractivo. SSH además tiene una estabilidad probada en batalla, y aunque esta herramienta nueva fuera realmente apta para producción, confiar en ella todavía se siente riesgoso
  • El túnel UDP es una función clave; es mucho más ligero que wireguard y además tiene cosas como autenticación OpenID
  • La “velocidad de conexión” siempre me ha molestado un poco. Especialmente me frustraba lo lento que se siente al ejecutar comandos rápidos en remoto
  • En ssh3 probablemente ya se resolvió el bloqueo por head-of-line, así que al multiplexar varios puertos o conexiones sobre una sola conexión física debería ir más rápido
  • Si necesitas una experiencia de usuario más fluida, recomiendo Mosh
• No sé por qué me da una sensación tan triste que todos los protocolos de capa de aplicación terminen siendo absorbidos por http
  • Si de verdad esa es la dirección, sí sería triste. El modelo típico de HTTP es demasiado restrictivo y complicado para muchos casos. Pero HTTP/2 y QUIC (el transporte de HTTP/3) son tan genéricos que el propio nombre HTTP parece ir perdiendo significado. Al menos QUIC sí se posiciona de forma bastante clara como reemplazo de TCP
  • En realidad, que todos estos protocolos se estandaricen también me parece positivo, porque dificulta cosas como traffic shaping y censura. Al final, si el tráfico es HTTP o un flujo aleatorio de bytes (es decir, no llama la atención), se vuelve más difícil vigilarlo o bloquearlo. Si vas a crear un protocolo nuevo, salvo que el operador te dé alguna ventaja especial, disfrazarlo como HTTP es la manera de lograr que circule bien sin penalización
  • Este fenómeno también existe porque los equipos de seguridad corporativa tienen la costumbre de bloquear o interceptar absolutamente todo. Sí, les hablo a ustedes, equipos que usan Zscaler o modo TLS middleman
  • Ese tipo de bloqueos también se ve en wifi de aeropuertos y hoteles de todo el mundo. Por ejemplo, a veces Apple Mail no puede enviar correo porque, como política corporativa, bloquean el puerto 25. Con la excusa del spam también bloquean 143, 587, 993 y demás, y al final solo dejan pasar 80 y 443. Ojalá IPv6 mejore un poco esto. Y ojalá se detengan cosas como el impulso de ChatControl en la UE. De verdad quisiera que escucharan más a gente que sí sabe de IT
  • Entiendo también que la complejidad de la inicialización de la conexión de red, o sea connection init, haya aumentado tanto que al final uno termine apoyándose en mejores prácticas basadas en protocolos probados en batalla. Pero cuando la transferencia real ya no tiene nada de hypertext, sigue sintiéndose raro seguir llamándolo http
• Está buenísimo que la funcionalidad de SSH evolucione, pero si al final prácticamente lo están rehaciendo desde cero, me habría gustado que añadieran funciones nuevas más experimentales. Por ejemplo, alguna comodidad al estilo de Mosh para “roaming/inestabilidad temporal de red” sería genial https://mosh.org/
  • La ventaja de Mosh es que la respuesta al teclear es rapidísima y se siente casi como trabajar directamente en una shell local. Me pregunto si SSH3 mejora algo de eso. QUIC quizá ayude un poco, pero no es lo mismo que Mosh
  • Según entiendo, connection migration y soporte multipath son propiedades básicas de QUIC, y respecto a la diferencia entre la función de roaming y un “tmux integrado”, no estoy seguro de que el verdadero valor esté en que eso venga incorporado directamente al sistema
• Me intriga la gente que se obsesiona con nombres cortos o siglas; me parece terrible. Hoy en día no pasa nada si un comando es largo, así que deberíamos usar nombres largos lo más técnicos y claros posible. Deberíamos usar el nombre completo por defecto, y dejar que algunos administradores de sistemas o distribuciones lo abrevien si quieren. A la gente hay que enseñarle el nombre completo. Por ejemplo, Set-Location me parece preferible a cd, y algo como remote-terminals-over-http3 sería mejor que ssh3
• El último commit fue hace un año. ¿Alguien sabe si ha habido avances recientes en el proyecto?
• Me da curiosidad el plan del proyecto. No ha habido noticias en más de un año, ni en lanzamientos ni en actividad de GitHub. Como parece haber empezado a partir de un paper, imagino que quizá hayan seguido con investigación relacionada u otros trabajos paralelos
  • Gracias por señalar ese punto. Personalmente, yo ya doy este proyecto por terminado. Con unas 239 commits, en realidad sigue siendo más bien un proof of concept y todavía no parece algo serio para usar. En cambio, del lado de OpenBSD (OpenSSH) siguen activísimos, así que todavía no parece que vaya a ser reemplazado pronto https://github.com/openbsd/src/commits/master/
• La idea del proyecto está bien. Si pudiera proxearse mediante un proxy H3 genérico, sería especialmente prometedor. Y si además resuelve multipath/migration y los problemas de bloqueo relacionados con TCP, ya sería un avance enorme