Abrir un terminal SSH directamente en el navegador es práctico: sin instalar un cliente, sin configurar claves en cada equipo y con acceso incluso desde el móvil. La duda natural es: ¿es seguro? La respuesta corta: depende por completo de cómo esté construida la plataforma. Veamos qué ocurre por detrás y qué debes exigir.
Cómo funciona un terminal SSH web
El navegador no habla SSH directamente. La arquitectura típica tiene tres partes:
- Navegador: muestra el terminal (normalmente con la biblioteca xterm.js) y envía lo que escribes.
- Gateway de la plataforma: recibe la conexión por WebSocket seguro (WSS) y abre la sesión SSH real con el servidor.
- Tu servidor: recibe una conexión SSH normal, cifrada como cualquier otra.
Es decir, el punto crítico es el gateway: es el que guarda las credenciales y decide quién puede abrir cada sesión.
Los riesgos reales
- Filtración de credenciales si la plataforma almacena contraseñas en texto plano o las envía al navegador.
- Secuestro de cuenta: sin 2FA, quien descubra la contraseña de tu panel obtiene acceso a todos los servidores.
- Acceso entre clientes (cross-tenant) en plataformas que no aíslan correctamente los datos de cada cuenta.
- Sesiones reutilizables: URLs o tokens de conexión que siguen siendo válidos después de usarse.
- Falta de trazabilidad: no saber quién ejecutó qué, ni cuándo.
Checklist: 7 controles que debe tener la plataforma
| # | Control | Por qué importa |
|---|---|---|
| 1 | Credenciales cifradas en reposo | Una filtración de la base de datos no expone tus contraseñas ni tus claves. |
| 2 | Credenciales que nunca se envían al navegador | Las extensiones maliciosas o un XSS no pueden capturarlas. |
| 3 | HTTPS + WSS en todo el trayecto | Nada viaja en texto plano. |
| 4 | 2FA obligatorio | La contraseña del panel por sí sola no basta para entrar. |
| 5 | Ticket de sesión de un solo uso y corta duración | Un enlace copiado o interceptado no abre otra sesión. |
| 6 | Aislamiento por cuenta y permisos por servidor | Cada usuario solo accede a lo suyo o a lo que se ha compartido con él. |
| 7 | Auditoría de comandos | Trazabilidad para incidentes y cumplimiento normativo. |
Cómo implementa EzServer cada punto
- Las contraseñas y claves SSH se guardan cifradas y solo se usan en el servidor de la plataforma.
- Para abrir el terminal, el navegador o la app recibe un ticket de un solo uso, válido durante unos instantes, y no las credenciales.
- La autenticación en dos factores protege la cuenta.
- Uso compartido por servidor: los colaboradores usan su propia cuenta y nunca ven la contraseña.
- Los comandos quedan registrados en un log de auditoría.
- Conexiones con keepalive y reconexión automática; con tmux, la sesión se retoma donde se quedó.
Buenas prácticas en tu servidor
La plataforma es una capa; el servidor también debe estar protegido:
# /etc/ssh/sshd_config
PermitRootLogin prohibit-password # root solo con clave
PasswordAuthentication no # cuando todos usen clave
MaxAuthTries 3
ClientAliveInterval 60Complétalo con fail2ban para bloquear intentos de fuerza bruta y mantén el sistema actualizado (apt update && apt upgrade).
En resumen: un terminal en el navegador no es menos seguro que el SSH local, siempre que las credenciales no salgan del servidor de la plataforma, la cuenta tenga 2FA y cada sesión use un ticket desechable.