Un desarrollador que firma en GitHub como ma-pedreira ha publicado ssh-web, una aplicación de código abierto con licencia MIT que da acceso SSH desde el navegador a servidores locales o publicados y mantiene vivas las sesiones aunque se cierre la pestaña. El repositorio, cuyo primer commit es del 25/08/2026 y que recibió sus últimas correcciones el 07/11/2026, se distribuye para Docker y para Windows y guarda la lista de equipos en el archivo estándar ~/.ssh/config, el mismo que usa el cliente ssh de siempre.
Las claves de ssh-web en 20 segundos
- Terminal SSH en el navegador con sesiones que siguen vivas en el servidor.
- Los hosts se guardan en
~/.ssh/configy las huellas enknown_hosts. - No guarda contraseñas salvo con una bóveda cifrada opcional.
- Es monousuario, sin TLS propio ni segundo factor.
El problema que intenta resolver es concreto: la mayoría de los terminales web atan la conexión SSH a la pestaña del navegador, de modo que cerrarla o perder la wifi mata el proceso. En ssh-web la conexión vive en el proceso del servidor y la pestaña es solo una ventana para mirarla. El README lo ilustra con un caso habitual: dejar un apt upgrade en marcha, cerrar el portátil y seguir la misma sesión desde el móvil. Varias personas, o varios dispositivos, pueden ver la misma sesión a la vez, y al volver se repinta la salida reciente.
Cómo funciona y dónde guarda cada cosa
Un único proceso de Node.js sirve la aplicación web, construida con Next 16 y React 19, y atiende en el mismo puerto el WebSocket del terminal. El navegador usa xterm.js para pintar la consola y la conexión con el servidor remoto la establece la biblioteca ssh2. Un gestor de sesiones conserva cada conexión y guarda la salida reciente en un búfer circular, de 256 KB por defecto, que se reenvía cuando un cliente vuelve a conectarse.
La decisión de diseño más interesante es dónde vive la configuración. La aplicación no mantiene un inventario propio: lee y escribe los bloques Host en ~/.ssh/config y las huellas de los servidores en ~/.ssh/known_hosts. La base de datos SQLite solo guarda la cuenta, las sesiones y el registro de auditoría. Si se pierde, se pierde el historial, pero no un solo host ni una sola clave, y el archivo de configuración sigue sirviendo para ssh, scp o rsync si se deja de usar la herramienta.
En Docker basta con indicar en un archivo .env la carpeta de configuración SSH y la de claves, y levantar el servicio con docker compose up -d --build. El primer usuario que se registra se queda con la cuenta y el registro se cierra a continuación. En Windows, con Node.js 24 instalado, se arranca con el script start.cmd. El proyecto declara 295 pruebas automatizadas, algunas de ellas contra servidores SSH reales, e incluye en el repositorio un archivo CLAUDE.md con las reglas de desarrollo para asistentes de programación con IA.
El modelo de seguridad, punto por punto
Un terminal SSH accesible por web es un objetivo de alto valor: quien comprometa la aplicación tiene una puerta a todos los servidores que gestiona. Por eso merece la pena leer con calma las medidas que describe el autor. Por defecto no se guarda ninguna contraseña: se piden al conectar y solo viven en memoria. Si el usuario prefiere no teclearlas cada vez, puede activar una bóveda cifrada con AES-256-GCM cuya clave se deriva de su contraseña de acceso con scrypt y nunca se escribe en disco. Las claves privadas se leen de un directorio montado en solo lectura y no se copian.
La contraseña de acceso se almacena con scrypt (N=216) y sal aleatoria; de la sesión web solo llega al disco la huella SHA-256 del token; las cookies son HttpOnly y SameSite=Strict; hay protección CSRF con doble envío y comprobación de origen, y el WebSocket exige el mismo origen. Frente a la fuerza bruta, la aplicación limita a cinco intentos por usuario cada 15 minutos. En el lado SSH usa el known_hosts estándar con confianza en el primer uso, y corta la conexión si la clave de un servidor cambia. El contenedor se ejecuta sin root, con el sistema de archivos de solo lectura, sin capacidades del kernel (cap_drop: ALL), con no-new-privileges y con límites de memoria y de procesos.
Hay también una advertencia que el propio autor destaca y que conviene no pasar por alto: apuntar el montaje de claves a todo ~/.ssh es lo más cómodo, pero expone todas las claves privadas del usuario a cualquier fallo de la aplicación, incluidas las de servidores que nunca se gestionan desde ella. Lo recomendable es una carpeta aparte con solo las claves necesarias.
Lo que queda del lado del administrador
El README es transparente con sus límites. La aplicación es monousuario, no permite cambiar la contraseña (porque obligaría a recifrar la bóveda), las sesiones no sobreviven a un reinicio del servidor y, tras reiniciar, hay que volver a iniciar sesión para que la bóveda esté disponible. De ssh_config interpreta el subconjunto habitual (Host, HostName, User, Port, IdentityFile y comodines), mientras que Include, Match y ProxyJump se conservan en el archivo pero no se aplican, lo que importa a quien llega a sus servidores a través de un bastión.
Las dos ausencias más relevantes para la seguridad son el cifrado de transporte y el segundo factor. ssh-web no incluye TLS propio: por defecto escucha solo en 127.0.0.1:3030 y el autor recomienda llegar a él mediante un túnel SSH, por ejemplo con ssh -L 3030:127.0.0.1:3030 usuario@servidor. Si se publica en la red local sin TLS, la contraseña, la cookie de sesión y todo lo que se teclea en el terminal viajan en claro, así que la opción razonable es ponerle delante un proxy inverso con HTTPS y activar SSH_WEB_SECURE_COOKIES=true. El código no incluye autenticación de doble factor, por lo que, si se expone más allá de la red propia, conviene delegarla en el proxy o en una capa de acceso como una VPN.
Como cualquier herramienta que gestiona accesos, también conviene mantener al día los servidores de destino. Para revisar si alguno de ellos está afectado por fallos recientes de OpenSSH, opensecurity.es explicó hace poco cómo comprobar con SSHamble la exposición a SSHHole. El propio autor de ssh-web lo resume en la licencia: el software se ofrece tal cual y quien gestione con él el acceso a sus máquinas debería revisarlo antes de confiarle nada importante.
Preguntas frecuentes
¿Qué es ssh-web?
Una aplicación de código abierto con licencia MIT que da acceso SSH desde el navegador y mantiene las sesiones vivas en el servidor aunque se cierre la pestaña. Se instala con Docker o en Windows.
¿Guarda mis contraseñas o claves privadas?
Por defecto no guarda contraseñas y las claves privadas solo se leen de un directorio en solo lectura. Las contraseñas se pueden guardar en una bóveda opcional cifrada con AES-256-GCM.
¿Es seguro publicarlo en Internet?
No tal cual. No trae TLS ni segundo factor, así que el autor recomienda usarlo en local o con un túnel SSH, y para publicarlo, ponerle delante un proxy inverso con HTTPS.
¿Sirve con un bastión o ProxyJump?
Todavía no. Conserva las directivas ProxyJump, Include y Match en el archivo de configuración, pero no las aplica.
Fuentes:
