Problema

En entornos con varios VPS o servidores bare‑metal, la tendencia es desplegar un agente de monitorización (Prometheus node‑exporter, Zabbix agent, etc.). Cada agente implica instalación, mantenimiento de paquetes, apertura de puertos y, a menudo, exposición de datos a un backend externo. Cuando los recursos son escasos o la política de seguridad prohíbe procesos adicionales, esa aproximación resulta poco práctica. El desafío consiste en obtener métricas de estado (CPU, memoria, uso de disco, tráfico de red) y, de paso, ejecutar comandos o gestionar contenedores sin tocar el servidor con software adicional, todo desde un dispositivo móvil.

Causa

  1. Sobrecarga de recursos – Un agente consume RAM y CPU, lo que en VPS de 256 MiB puede afectar la carga de trabajo principal.
  2. Superficie de ataque – Cada daemon abre al menos un puerto adicional; cualquier vulnerabilidad del agente amplía la zona de exposición.
  3. Complejidad operativa – Gestionar versiones, reinicios y configuraciones de agentes en cientos de nodos genera fricción administrativa.
  4. Dependencia de servicios externos – Herramientas SaaS requieren que los datos salgan del perímetro, lo que rompe la política de “datos nunca salen”.

Solución

Utilizar SSH como canal de telemetría y control. El protocolo ya está presente, está cifrado y permite ejecutar scripts arbitrarios sin instalar nada más. La solución se divide en tres capas:

  1. Recopilación de métricas mediante comandos estándar

    • top -b -n1 o vmstat para CPU y memoria.
    • df -h para uso de discos.
    • cat /proc/net/dev o ss -s para tráfico de red.
    • Los resultados se parsean en el cliente móvil y se almacenan localmente para graficar tendencias.

  2. Terminal interactivo sin dependencias

    • Un emulador de terminal que interprete secuencias ANSI mediante una máquina de estados propia.
    • Permite lanzar htop, nano, vim o cualquier binario disponible en el host sin necesidad de túneles adicionales.

  3. Control de Docker sin API remota

    • Ejecutar docker ps, docker start/stop/restart y docker logs -f a través de SSH.
    • Al no exponer el socket de Docker, la única superficie de ataque sigue siendo el puerto SSH ya protegido por claves.

Implementación práctica en Android

  • Almacenamiento seguro: claves privadas y contraseñas se guardan en Android Keystore usando AES‑GCM.
  • Persistencia de datos: métricas históricas se guardan en una base SQLite local; la app muestra gráficos de 1, 2 y 5 min.
  • Notificaciones: umbrales configurables disparan notificaciones locales; se agrupan y se debouncean para evitar spam.
  • Bastiones: si el objetivo no tiene IP pública, se configura una cadena phone → bastion → target usando ProxyCommand en el archivo de configuración SSH temporal.

Cuándo aplicar esta solución

  • Entornos con recursos limitados: VPS con < 512 MiB RAM o servidores embebidos donde cada proceso cuenta.
  • Políticas de “cero agente”: organizaciones que prohíben la instalación de software adicional en producción.
  • Necesidad de acceso móvil: cuando el ingeniero necesita una vista rápida de estado y la posibilidad de intervenir sin abrir una laptop.
  • Escenarios con bastiones: infraestructuras donde los nodos internos solo son accesibles a través de un salto SSH.

No es la mejor opción cuando:

  • Se requiere alertas centralizadas (PagerDuty, Slack) o correlación de eventos a gran escala.
  • Se necesita alta frecuencia de muestreo (segundos) porque el coste de abrir una sesión SSH cada minuto puede ser prohibitivo.
  • Los servidores están detrás de firewalls que bloquean conexiones SSH externas.

Código

# Script minimalista para extraer métricas clave vía SSH
ssh -i ~/.ssh/id_rsa user@host <<'EOF'
echo "CPU=$(top -bn1 | grep 'Cpu(s)' | awk '{print $2+$4}')"
echo "MEM=$(free -m | awk '/Mem:/ {printf "%.2f", $3/$2 * 100 }')"
echo "DISK=$(df -h / | awk 'NR==2 {print $5}')"
cat /proc/net/dev | awk 'NR>2 {print $1,$2,$10}'
EOF

Este fragmento devuelve CPU (% de uso), MEM (% usado), DISK (porcentaje de ocupación) y tráfico de red por interfaz. El cliente móvil puede ejecutar el bloque y parsear la salida con expresiones regulares.


## Verificación
1. **Conexión SSH** – Ejecutar `ssh user@host uptime` y confirmar que la respuesta llega sin pedir contraseña (clave pre‑cargada).  
2. **Métricas visibles** – En la app, abrir la tarjeta del servidor y comprobar que los valores de CPU, MEM y DISK coinciden con los mostrados por `top`, `free` y `df` en la terminal.  
3. **Notificación de umbral** – Configurar un umbral bajo (p. ej., CPU > 5 %). Generar carga con `yes > /dev/null &` y observar que la notificación aparece después del intervalo configurado.  
4. **Control Docker** – Desde la app, detener un contenedor con `docker stop <id>` y validar que `docker ps` ya no lo lista.

## Notas adicionales
- **Reuso de conexiones**: habilitar `ControlMaster` y `ControlPersist` en la configuración SSH reduce la latencia al mantener la sesión abierta entre polls.  
- **Gestión de claves**: si el dispositivo no soporta hardware keystore (teléfonos no certificados), la app desactiva la importación de claves privadas por seguridad.  
- **Backup**: exportar la base SQLite a Google Drive cifrada con una contraseña maestra garantiza que ni Google ni terceros puedan leer credenciales.  
- **Limitaciones de Android**: versiones anteriores a Android 14 pueden presentar restricciones de ejecución en segundo plano; la monitorización continua debe activarse explícitamente por el usuario.  
- **Escalado**: para más de 20 servidores, agruparlos en “grupos” dentro de la app ayuda a reducir el número de conexiones simultáneas y a organizar la vista de métricas.  

Con este enfoque, la monitorización y el control de servidores Linux se reducen a un único canal seguro, eliminando la necesidad de agentes, puertos extra y dependencias externas. La solución es particularmente útil para administradores que gestionan entornos ligeros o que requieren acceso inmediato desde dispositivos móviles.