El ecosistema de acceso remoto seguro tiene un nuevo actor —todavía en pruebas, pero con ambición de calado—: SSH3. Se trata de una revisión completa del protocolo SSH que mapea su semántica sobre HTTP/3 y apoya su canal cifrado en QUIC (UDP) y TLS 1.3, mientras que delega la autenticación en los mecanismos de autorización HTTP. El proyecto, fruto de un trabajo de investigación propuesto como Internet-Draft (draft-michel-remote-terminal-http3-00, renombrado a “Remote Terminals over HTTP/3”), acaba de publicar su primera versión experimental de cliente y servidor, escrita en Go y distribuida bajo licencia Apache 2.0.
La promesa de SSH3 puede resumirse en una frase: establecimientos de sesión más rápidos, nuevos métodos de autenticación (como OAuth 2.0 y OpenID Connect) junto a los clásicos de contraseña y clave pública, reenvío de puertos UDP además del TCP tradicional y todas las capacidades modernas de QUIC, incluida la migración de conexión (próximamente) y las conexiones multirruta. Todo ello, envuelto en tráfico que se confunde con el resto de HTTP/3 y TLS en la red.
¿Qué es exactamente SSH3?
Los desarrolladores explican que no se trata de un parche incremental sobre SSHv2, sino de una relectura de fondo: la semántica SSH clásica (canales, port forwarding, autenticación) se implementa encima de HTTP mediante HTTP/3 Extended CONNECT, y el cifrado lo aporta TLS 1.3 funcionando sobre QUIC. Esta decisión persigue dos metas:
- Apoyarse en protocolos robustos y auditados que ya aseguran e-commerce, banca y aplicaciones críticas en Internet (TLS 1.3/QUIC/HTTP).
- Integrarse con el ecosistema web (mecanismos de autorización HTTP, certificados X.509, despliegues en puerto 443) y ocultar la actividad SSH entre el resto del tráfico.
Entre las mejoras que la especificación y el prototipo declaran frente a SSHv2/OpenSSH, destacan:
- Arranque de sesión más rápido: SSH3 reduce los viajes de ida y vuelta de 5–7 a 3 para establecer una sesión (el throughput no cambia, pero la percepción de latencia al conectar sí).
- Nuevos métodos de autenticación basados en HTTP: OAuth 2.0 y OpenID Connect (OIDC), además de contraseña y clave pública (RSA y EdDSA/ed25519).
- Resistencia a escaneos de puertos: el servidor puede “ocultarse” tras una ruta secreta (URL) y responder 404 a otras peticiones, volviéndose indetectable para scanners y bots.
- Reenvío de puertos UDP: además del clásico TCP forwarding, SSH3 encapsula UDP (p. ej., QUIC, DNS, RTP) mediante QUIC datagrams.
- Certificados X.509 para el servidor: posibilidad de autenticar el host con certificados HTTPS (p. ej., de Let’s Encrypt), un mecanismo que evita el problema de la primera conexión de SSHv2 (riesgo de MITM al “aceptar huella”).
- Capacidades QUIC: migración de conexión (cambiar de red sin perder la sesión) y multipath (múltiples rutas), entre otras.
Además, el prototipo conserva funciones populares de OpenSSH: análisis de ~/.ssh/authorized_keys en el servidor; soporte de known_hosts cuando no se usa X.509; uso automático de ssh-agent para autenticación de clave pública; agent forwarding; direct TCP port forwarding (el reverse llegará más adelante); proxy jump; y parsing básico de ~/.ssh/config (opciones Hostname, User, Port e IdentityFile, más opciones nuevas como URLPath o UDPProxyJump propias de SSH3).
Importante: los autores insisten en que SSH3 es experimental. Aunque la base criptográfica sea la de TLS 1.3 y QUIC, el protocolo y su implementación requieren revisión y maduración antes de plantear un uso en producción.
Sesiones que abren antes: 3 viajes frente a 5–7
Uno de los argumentos prácticos es el tiempo hasta ver un prompt. Con un ping de 100 ms, SSHv2 puede necesitar 5–7 round trips; SSH3, 3. La latencia por pulsación en una sesión ya establecida no cambia, pero esa fricción inicial sí. Para entornos con latencias no triviales (sucursales, clouds lejanos), la diferencia es perceptible.
Autenticación: de la clave pública a “entra con tu Google/Microsoft/GitHub”
SSH3 no rompe con lo conocido: contraseñas (desactivadas por defecto) y claves públicas (RSA, ed25519) siguen ahí. Pero añade un esquema HTTP-native: OAuth 2.0/OpenID Connect. En la práctica, el administrador puede delegar la autenticación en un IdP (el SSO de la empresa, Google Identity, Microsoft Entra, GitHub, etc.) y evitar el baile de copiar claves entre máquinas.
- Lado cliente: un fichero
~/.ssh3/oidc_config.jsondefine issuer_url, client_id y client_secret del proveedor; es posible activar PKCE. - Lado servidor: el fichero
~/.ssh3/authorized_identitiesadmite entradas oidc (issuer y client_id) además de las authorized_keys clásicas.
Esta vía sin llave (keyless) es atractiva para SSO corporativo, aunque los autores la marcan como experimental y sujeta a cambios en configuración.
Servidores “invisibles” y protección frente a escaneos
Otra novedad práctica es la posibilidad de ocultar el servidor tras una ruta secreta. El binario admite:
ssh3-server -bind 0.0.0.0:443 -url-path /<ruta-larga-secreta>
Lenguaje del código: HTML, XML (xml)Así, solo responderá a peticiones que incluyan esa URL; al resto, devolverá 404. A ojos de un atacante, parece un servidor web anodino. Aviso: los desarrolladores recuerdan que esto no sustituye a la autenticación; es una medida para evitar descubrimiento, no un mecanismo de acceso.
X.509: certificando el servidor (y adiós al “acepta la huella”)
Porque SSH3 se apoya en TLS 1.3, el servidor necesita un certificado y su clave privada. Hay tres opciones:
- Let’s Encrypt (recomendado): el servidor puede autogenerar y renovar certificados públicos para un dominio con
-generate-public-cert. - Certificado existente: pasar rutas de
-cert/-key. - Autofirmado:
-generate-selfsigned-cert(equivale a la seguridad de la host key de SSHv2, con el mismo problema de MITM inicial si no se valida fuera de banda).
Usar ACs públicas evita el clásico “¿aceptas esta huella?” y mejora la experiencia y seguridad en la primera conexión.
“UDP inside”: port forwarding para QUIC, DNS, RTP…
SSH3 habilita UDP port forwarding (además de TCP). Para quien lidia con QUIC, DNS o RTP accesibles solo desde un host intermedio, es una mejora sustancial: el túnel viaja como datagramas QUIC y se gestiona desde el cliente con los parámetros -forward-udp/-forward-tcp.
El Proxy Jump también funciona con dos servidores SSH3 (B como gateway hacia C): B reenvía UDP de A a C, pero no puede descifrar el tráfico A↔C (es end-to-end).
Instalación y pruebas: binarios, go install o compilación
Aviso de nuevo: no se recomienda un despliegue público en producción. Si se va a probar, mejor en redes privadas, sandbox o, si se expone a Internet, con la ruta secreta y cautela.
Opciones de instalación:
- Binarios de la última release.
- Go install:
go install github.com/francoismichel/ssh3/cmd/...@latest
- Compilar desde fuente (requiere Go moderno y, para el servidor, CGO/gcc):
git clone https://github.com/francoismichel/ssh3
cd ssh3
go build -o ssh3 cmd/ssh3/main.go
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go
Lenguaje del código: PHP (php)Con privilegios de root, se pueden copiar a /usr/bin/. Si no, añadir la ruta a PATH.
Arrancar un servidor público en 443 con Let’s Encrypt y ruta /ssh3:
ssh3-server -generate-public-cert mi-dominio.ejemplo.org -url-path /ssh3
Lenguaje del código: PHP (php)Usar un cert existente:
ssh3-server -cert /ruta/a/cert.pem -key /ruta/a/priv.key -url-path /ssh3
Como en OpenSSH, para permitir el login de otros usuarios, el servidor debe ejecutarse con privilegios.
Archivos relevantes:
- Servidor:
~/.ssh/authorized_keysy~/.ssh3/authorized_identities. - Cliente:
~/.ssh/config(parsing parcial) y~/.ssh3/oidc_config.jsonpara OIDC.
Cliente, ejemplos básicos:
- Clave privada:
ssh3 -privkey ~/.ssh/id_rsa [email protected]/mi-ruta-secreta
Lenguaje del código: JavaScript (javascript)- Contraseña (si el servidor la permite explícitamente):
ssh3 -use-password usuario@mi-servidor.ejemplo.org/mi-ruta-secreta
Lenguaje del código: CSS (css)- Agent forwarding y salto por proxy:
ssh3 -forward-agent -proxy-jump bastion@bastion.ejemplo.org [email protected]/mi-ruta
Lenguaje del código: CSS (css)- Forward UDP/TCP:
ssh3 -forward-udp 5353/10.0.0.53@53 -forward-tcp 8443/10.0.0.10@443 usuario@host/ssh3
Estado del proyecto y advertencias
SSH3 no es una implementación “oficial” de los equipos de OpenSSH ni de otros proyectos SSH clásicos. Es un prototipo libre y abierto para fomentar el análisis y la revisión de la comunidad. Los autores lo dicen sin rodeos:
- Precisa una revisión criptográfica extensa antes de extraer conclusiones de seguridad.
- No recomiendan su despliegue público en producción; si se expone, usar medidas defensivas (como la ruta secreta) no sustituye a la autenticación robusta.
- El nombre SSH3 podría cambiar; la especificación ya se renombró como Remote Terminals over HTTP/3: los cambios requeridos son profundos y lejanos a la filosofía de implementaciones SSH populares.
Qué aporta (y qué no) a día de hoy
Aporta:
- Menor tiempo de establecimiento de sesión (3 RTT frente a 5–7).
- Autenticación moderna (OAuth/OIDC) y SSO corporativo sin copiar claves.
- UDP forwarding nativo.
- Certificados X.509 (Let’s Encrypt) para autenticar el servidor y evitar MITM de primer contacto.
- Camuflaje entre el tráfico HTTP/3/TLS y ruta secreta para reducir ruido de scanners.
- Puerta a migración de conexión y multipath vía QUIC.
No aporta (todavía):
- Garantías de seguridad equivalentes a implementaciones maduras (OpenSSH).
- Soporte completo de todas las opciones y flujos de OpenSSH (aunque cubre los más populares).
- Recomendación para entornos críticos: su sitio es el laboratorio, no la producción.
Conclusión
SSH3 es, ante todo, una propuesta valiente: retirar capas de un protocolo venerable para reaprovechar TLS 1.3, QUIC y HTTP, y encajar SSH en el mundo actual —más webizado, con SSO omnipresente y UDP como primera clase. Acelera el handshake, amplía la autenticación y abre la puerta a nuevas rutas como el UDP forwarding y la migración de conexiones. A cambio, exige cautela: está verde, busca revisión y no quiere hacerse pasar por lo que no es.
Para administradores y equipos de seguridad, la recomendación es doble: experimentar (en sandbox) para entender sus ventajas, y esperar a que el proyecto supere la prueba del tiempo antes de ponerlo entre sus sistemas críticos. La comunidad tiene la palabra.
Preguntas frecuentes (FAQs)
¿Cómo instalar y probar SSH3 en un entorno de pruebas paso a paso?
Para un entorno de laboratorio, puede usar go install:
go install github.com/francoismichel/ssh3/cmd/...@latest
o compilar desde fuente (requiere Go reciente; para el servidor, CGO/gcc). Inicie el servidor con certificado (Let’s Encrypt con -generate-public-cert o autofirmado) y una ruta secreta con -url-path. Conéctese desde el cliente usando clave privada o OIDC (configurando ~/.ssh3/oidc_config.json). Recuerde: no lo despliegue en producción.
¿Cómo funciona la autenticación con Google/Microsoft/GitHub (OpenID Connect) en SSH3?
SSH3 permite delegar la autenticación en un IdP OIDC. En el cliente, defina issuer_url, client_id y client_secret en ~/.ssh3/oidc_config.json y ejecute ssh3 -use-oidc https://accounts.google.com usuario@host/ruta. En el servidor, añada una entrada oidc en ~/.ssh3/authorized_identities. Es una función experimental y puede requerir registrar una app en el proveedor para obtener credenciales.
¿Cómo ocultar un servidor SSH3 para mitigar ataques de escaneo de puertos?
Ejecute el servidor en 443/QUIC con una ruta secreta (-url-path /cadena-aleatoria-larga). Solo responderá a peticiones en esa URL (el resto verá 404). Ojo: esto reduce descubrimiento, pero no sustituye a la autenticación. Mantenga claves/SSO y políticas como en cualquier servicio expuesto.
¿Qué ventajas prácticas ofrece el “UDP port forwarding” de SSH3 y cómo se usa?
Permite túneles UDP para servicios como QUIC, DNS o RTP accesibles solo desde el host SSH3. Se activa con -forward-udp en el cliente, que encapsula los datagramas a través de QUIC. Es útil para administración remota de servicios UDP o para pruebas sin abrir puertos adicionales en la red.
¿Por qué usar certificados X.509 (Let’s Encrypt) para el servidor en lugar de claves de host SSHv2?
Con X.509, el primer contacto evita el dilema de “aceptar huella” y el riesgo de MITM asociado. Además, puede automatizar obtención/renovación con Let’s Encrypt (-generate-public-cert). En SSH3, el canal ya usa TLS 1.3, por lo que es natural aprovechar la infraestructura de certificación pública.
vía: SSH3 GitHub
