SSHDeck es un nuevo cliente web SSH autoalojado que intenta reunir en una sola interfaz algunas de las funciones habituales de herramientas como MobaXterm o Termius. El proyecto se ejecuta desde un único contenedor Docker y permite guardar sesiones, abrir terminales en pestañas, gestionar archivos mediante SFTP, transferir datos directamente entre dos servidores y consultar métricas básicas de los hosts sin instalar agentes adicionales.
Las claves de SSHDeck en 20 segundos
- Es un cliente SSH web y autoalojado que se despliega mediante Docker.
- Utiliza xterm.js para el terminal y permite organizar hosts, carpetas e identidades.
- Incluye un gestor SFTP de doble panel con transferencias directas entre servidores.
- Recoge CPU, RAM, disco, red y usuarios mediante la propia conexión SSH.
- El desarrollador recomienda utilizarlo únicamente en redes internas o detrás de una VPN.
El proyecto ha sido creado por MD. Ismail Hossain y está publicado en GitHub bajo licencia MIT. Su objetivo no parece ser competir directamente con plataformas empresariales de acceso privilegiado, sino ofrecer una herramienta práctica para homelabs, laboratorios, equipos DevOps y administradores que quieran centralizar sus conexiones SSH sin instalar un cliente de escritorio en cada ordenador.
La instalación refleja esa filosofía. Basta con clonar el repositorio y levantar el stack mediante Docker Compose:
git clone https://github.com/zeeglyismail/sshdeck.git
cd sshdeck
docker compose up -d --buildLenguaje del código: PHP (php)La interfaz queda disponible de forma predeterminada en:
http://localhost:8022Lenguaje del código: JavaScript (javascript)Desde ahí pueden crearse usuarios y añadir servidores manualmente o importar una configuración existente de MobaXterm.
Un terminal SSH completo dentro del navegador
La interfaz de terminal está construida alrededor de xterm.js, una de las bibliotecas más utilizadas para implementar emuladores de terminal en aplicaciones web.
SSHDeck permite mantener varias conexiones abiertas mediante pestañas y está pensado para trabajar con aplicaciones de terminal como tmux, Vim o Nano.
También incorpora algunos comportamientos habituales en clientes de escritorio: selección de texto para copiar, pegado mediante botón central, combinaciones Ctrl+Shift+C y Ctrl+Shift+V, zoom de fuente y soporte de 256 colores.
Una función especialmente práctica aparece cuando un host se reinicia o la conexión se pierde. El proyecto permite intentar reconectar desde la misma pestaña pulsando Enter, conservando el historial visible de la sesión.
El cliente incluye además un sistema de resaltado ejecutado en el navegador que identifica elementos como direcciones IP, MAC o palabras relacionadas con estados UP/DOWN. Esta función se desactiva cuando se utilizan aplicaciones de pantalla completa para evitar interferencias.
Monitorización sin instalar un agente en los servidores
Una de las diferencias respecto a un cliente SSH convencional es la barra de monitorización.
SSHDeck obtiene información básica sobre CPU, memoria, almacenamiento, red, uptime y usuarios conectados utilizando la misma sesión SSH que ya mantiene con el servidor.
No necesita instalar software adicional en cada máquina.
Internamente ejecuta comandos que consultan fuentes habituales de Linux como:
/proc/stat
/proc/meminfo
/proc/net/dev
/proc/uptime
df
whoLos datos se procesan en el servidor donde se ejecuta SSHDeck y posteriormente se envían a la interfaz mediante WebSocket.
El intervalo documentado es de aproximadamente 0,5 segundos.
Para CPU y tráfico de red se muestran gráficas de los últimos 60 segundos. También es posible visualizar los usuarios conectados y el número de sesiones de cada uno.
Este planteamiento tiene una ventaja clara: desplegar SSHDeck no obliga a instalar un agente de monitorización en todos los sistemas.
También tiene límites. No pretende sustituir a Prometheus, Zabbix, Grafana u otras plataformas de observabilidad. Se trata de información operativa rápida mientras el administrador trabaja sobre el host.
Un gestor SFTP con dos servidores abiertos a la vez
Probablemente una de las funciones más interesantes sea el gestor de archivos.
SSHDeck utiliza un diseño de doble panel SFTP, similar al utilizado tradicionalmente por gestores de archivos como Midnight Commander o WinSCP.
Cada panel puede conectarse a un servidor distinto.
Esto permite un escenario bastante útil:
Servidor A Servidor B
/etc/app/ ───────> /backup/app/Lenguaje del código: JavaScript (javascript)El usuario puede arrastrar un archivo o un directorio entre ambos paneles y SSHDeck realiza la transferencia de servidor a servidor.
Los datos no pasan por el ordenador donde está abierto el navegador.
El backend abre sesiones SFTP hacia ambos hosts y transmite los archivos entre ellas en bloques de 1 MB. El navegador únicamente envía la instrucción de transferencia y recibe información sobre su progreso.
Esto resulta especialmente útil al trabajar desde un portátil conectado mediante una línea relativamente lenta. Si ambos servidores se encuentran dentro de un centro de datos con conectividad de varios gigabits, el archivo puede moverse entre ellos sin tener que descargarlo primero hasta el equipo del administrador y volverlo a subir.
El gestor incluye además selección múltiple, creación de directorios, renombrado, modificación de permisos, borrado recursivo y carga mediante drag and drop desde el escritorio.
Una sola conexión SSH compartida entre varias funciones
La arquitectura interna explica varias de estas capacidades.
SSHDeck está desarrollado como un monolito modular mediante FastAPI y utiliza AsyncSSH para gestionar las conexiones.
La estructura descrita por el proyecto incluye componentes separados para autenticación, inventario, credenciales, SFTP, transferencias y portabilidad:
app/
├── main.py
├── db.py
├── crypto.py
├── auth.py
├── ssh_manager.py
├── ws.py
├── mobaconf.py
└── routers/La decisión de no dividir la aplicación en microservicios es deliberada.
El núcleo de SSHDeck es un pool de conexiones SSH. Para cada combinación de usuario y host mantiene una conexión que puede ser reutilizada por terminal, SFTP, monitorización y transferencias.
De esta forma no hace falta abrir una sesión SSH diferente para cada módulo.
Separar esas funciones entre varios procesos obligaría a multiplicar conexiones o añadir una capa RPC para compartir el pool, aumentando la complejidad sin demasiado beneficio para la escala a la que está orientado el proyecto.
Es una elección arquitectónica bastante razonable para una herramienta de este tipo.
Identidades compartidas y claves SSH cifradas
SSHDeck permite guardar una identidad, formada por usuario y contraseña, y asociarla posteriormente a diferentes hosts.
Si esa contraseña cambia puede actualizarse una única vez.
También admite autenticación mediante claves SSH privadas.
Las credenciales se guardan dentro de SQLite y los secretos se cifran mediante Fernet. La clave de cifrado se almacena en el directorio de datos junto con la base de datos.
La estructura básica es:
./data/
├── sshdeck.db
└── secret.keyEsto simplifica enormemente las copias y migraciones de la herramienta: basta con trasladar el directorio completo.
Pero introduce también una consideración de seguridad importante.
El propio proyecto advierte de que disponer simultáneamente de la base de datos y de secret.key permite acceder a los secretos. El cifrado protege la información almacenada, pero no proporciona protección frente a un atacante que comprometa completamente el servidor donde corre SSHDeck.
Por tanto, la seguridad real depende mucho de proteger el host y restringir el acceso al directorio de datos.
Importación desde MobaXterm y backup completo
Para facilitar la migración, SSHDeck puede importar archivos .mobaconf.
Esto permite recuperar marcadores y carpetas utilizados previamente en MobaXterm.
También dispone de exportación al mismo formato y de un sistema propio de backup que genera un JSON con carpetas, hosts, identidades y claves.
El objetivo es poder trasladar la configuración completa entre diferentes instalaciones.
La funcionalidad resulta cómoda, aunque esos backups deben tratarse como información extremadamente sensible. Si incluyen credenciales o claves privadas no deberían almacenarse junto a archivos convencionales sin las correspondientes medidas de protección.
Túneles SSH desde el propio servidor SSHDeck
El proyecto también incorpora local port forwarding.
Un túnel puede exponer un puerto en el servidor donde se ejecuta SSHDeck y dirigir el tráfico a través de uno de los hosts SSH almacenados hasta un servicio remoto.
El flujo sería similar a:
Usuario
|
v
Servidor SSHDeck:15001
|
v
Servidor SSH
|
v
Servicio interno:5432Las definiciones pueden guardarse y activarse o detenerse desde la interfaz.
Docker Compose publica de forma predeterminada un rango entre los puertos 15000 y 15020 para estas conexiones, aunque puede modificarse.
El proyecto no intenta implementar X11 forwarding. La decisión tiene sentido porque un navegador no dispone de un servidor X tradicional sobre el que representar aplicaciones gráficas.
Entre las futuras funciones previstas aparecen túneles remotos y dinámicos mediante SOCKS.
El punto delicado: SSHDeck no verifica todavía las host keys
La advertencia de seguridad más importante se encuentra en la propia documentación del proyecto.
Actualmente SSHDeck configura AsyncSSH con:
known_hosts=NoneEso significa que las claves de host SSH no se verifican.
La autenticación SSH no sirve únicamente para que el servidor compruebe la identidad del usuario. El cliente también debe verificar que realmente está conectándose al servidor esperado.
Normalmente esto se realiza almacenando las claves en known_hosts.
Sin esa comprobación, un atacante capaz de interceptar o redirigir la conexión podría tener más posibilidades de ejecutar un ataque man-in-the-middle.
El desarrollador lo reconoce expresamente y contempla añadir verificación estricta basada en TOFU (Trust On First Use) en el roadmap.
Por este motivo, el propio proyecto recomienda utilizar SSHDeck únicamente en redes internas o detrás de una VPN y nunca exponerlo directamente a Internet.
También recomienda colocar HTTPS mediante un reverse proxy cuando el acceso salga de localhost.
Es una limitación suficientemente importante como para tenerla presente antes de plantear un uso empresarial.
Autoalojado no significa automáticamente más seguro
La idea de centralizar credenciales SSH en una aplicación web tiene ventajas operativas, pero también concentra riesgo.
Un administrador que utiliza claves privadas distribuidas entre diferentes equipos tiene un determinado modelo de amenaza. Al trasladarlas a SSHDeck crea un nuevo punto central que contiene acceso potencial a muchos servidores.
Esto no convierte la herramienta en insegura por definición.
Significa que el servidor SSHDeck pasa a ser infraestructura especialmente crítica.
Debería protegerse como se protegería un bastion host: acceso restringido mediante VPN, HTTPS, sistema actualizado, copias de seguridad protegidas y permisos mínimos.
SSHDeck ofrece cuentas separadas para diferentes usuarios, contraseñas protegidas mediante bcrypt y cookies de sesión firmadas.
Sin embargo, todavía tiene elementos pendientes para un escenario empresarial más exigente. El roadmap incluye autenticación TOTP de dos factores y verificación de claves de los hosts, dos funciones que mejorarían considerablemente el modelo actual.
Tampoco debe confundirse con una plataforma PAM (Privileged Access Management). No incorpora las capacidades de gobierno, grabación de sesiones, aprobación, rotación automática de secretos o auditoría avanzada habituales en productos diseñados para controlar acceso privilegiado a gran escala.
Un proyecto interesante para homelab, DevOps y administración interna
SSHDeck resulta especialmente atractivo como alternativa ligera para quien maneja numerosos sistemas Linux y quiere disponer de sus sesiones desde cualquier navegador dentro de una red controlada.
La combinación de terminal, SFTP, métricas, túneles y transferencias entre servidores cubre muchas de las operaciones que normalmente obligan a utilizar diferentes herramientas.
También tiene una arquitectura sencilla de desplegar y respaldar:
Docker
|
└── SSHDeck
├── FastAPI
├── AsyncSSH
├── SQLite
├── xterm.js
└── ./dataEl hecho de que todo funcione en un único contenedor favorece especialmente homelabs, pequeños equipos técnicos y entornos de administración interna.
Su mayor desafío está ahora en reforzar la seguridad alrededor de algo particularmente sensible: una herramienta que, por diseño, guarda las llaves de acceso a toda una flota de servidores.
La incorporación futura de verificación estricta de host keys y autenticación multifactor elevaría considerablemente su utilidad más allá del laboratorio.
Mientras tanto, el propio desarrollador deja bastante claro dónde debe ejecutarse: detrás de una VPN, en una red interna y sin exposición directa a Internet.
Preguntas frecuentes
¿Qué es SSHDeck?
SSHDeck es un cliente SSH web autoalojado y open source que permite administrar conexiones SSH, archivos SFTP, túneles y métricas básicas desde un navegador.
¿Cómo se instala SSHDeck?
El proyecto está pensado para Docker. Puede clonarse desde GitHub y desplegarse mediante docker compose up -d --build. La interfaz utiliza de forma predeterminada el puerto 8022.
¿Puede transferir archivos directamente entre dos servidores?
Sí. El backend abre conexiones SFTP a ambos hosts y transmite los datos entre ellos. Los archivos no necesitan pasar por el ordenador donde está abierto el navegador.
¿Es recomendable exponer SSHDeck directamente a Internet?
No. El propio proyecto indica que está pensado para homelabs y redes internas y recomienda situarlo detrás de una VPN. Además, actualmente las claves de host SSH no se verifican, una limitación que el desarrollador tiene previsto corregir.
