// GUÍA DE USUARIO

Guía operativa — qué hacer, paso a paso, para sacar el máximo partido a SSHBorg.

⚙⚙⚙

// AÑADIR UN HOST

Pulsa el botón + en la pantalla de hosts para añadir un nuevo servidor.

Campos obligatorios

  • Hostname / IP — la dirección o IP del servidor. Se admiten tanto IPv4 como IPv6.
  • Puerto — valor predeterminado: 22. Cámbialo si tu servidor usa un puerto SSH diferente.
  • Nombre de usuario — el usuario Unix con el que quieres iniciar sesión (p. ej. ubuntu, root, deploy).
  • Autenticación — elige entre contraseña o clave SSH (recomendado).

Verificación de la huella del host

En la primera conexión, SSHBorg muestra la huella del servidor y te pide que la aceptes. Es una comprobación de seguridad: garantiza que te estás conectando a la máquina correcta y no a un impostor. Verifica que la huella coincida con la que te proporcionó el administrador del servidor antes de aceptarla.

Una vez aceptada, la huella se almacena localmente. Si cambia en una conexión futura, SSHBorg te avisará — podría indicar una reinstalación del servidor, una rotación de claves o un ataque man-in-the-middle.

// CONSEJO
Puedes comprobar la huella del servidor en cualquier momento con: 
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

// CLAVES SSH

La autenticación por clave es más segura que las contraseñas y, una vez configurada, no requiere recordar ni escribir nada.

Generar una clave

Ve a Ajustes → Claves SSH → Generar nueva clave. SSHBorg admite:

  • Ed25519 — recomendado. Rápido, compacto y seguro.
  • ECDSA (P-256 / P-384) — buena compatibilidad con servidores más antiguos.
  • RSA (2048 / 4096 bits) — máxima compatibilidad, pero más lento.

Ponle un nombre significativo a la clave (p. ej. mi-vps o servidor-trabajo) para identificarla más adelante.

// NOTA DE SEGURIDAD
SSHBorg no permite intencionalmente exportar claves privadas. La clave nunca sale del dispositivo. Si necesitas la misma clave en otro dispositivo, genera una nueva allí y autorízala por separado en tus servidores — es el enfoque más seguro.

Autorizar la clave en el servidor

Tras generar una clave, pulsa sobre ella para ver la clave pública. Cópiala y pégala en el archivo ~/.ssh/authorized_keys del servidor para el usuario con el que quieres iniciar sesión.

  1. En tu teléfono, abre SSHBorg → Ajustes → Claves SSH → pulsa la clave → copia la clave pública.
  2. Inicia sesión en tu servidor (con contraseña o con otra clave que ya tengas).
  3. Añade la clave pública al archivo de claves autorizadas: 
    mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...tuclavecopiada..." >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
  4. Intenta conectarte con SSHBorg — debería iniciar sesión sin pedir contraseña.
// REQUISITO DEL SERVIDOR
Asegúrate de que tu servidor tenga PubkeyAuthentication yes en /etc/ssh/sshd_config. Es el valor predeterminado en la mayoría de distribuciones, pero algunas imágenes reforzadas lo deshabilitan.

Cifrado adicional de la clave

SSHBorg ofrece una frase de contraseña adicional opcional para tus claves (Ajustes → Claves SSH → pulsa una clave → Activar cifrado). Cuando está activa, la clave se cifra con una frase que SSHBorg no almacena — se te pedirá cada vez que se use la clave.

Es muy recomendable si almacenas credenciales sensibles en tu teléfono o tienes el bloqueo biométrico desactivado.

// SUGERENCIAS DE COMANDOS

SSHBorg muestra una barra de sugerencias sobre el teclado mientras escribes en el terminal. Las sugerencias provienen del historial de shell del usuario con el que te conectaste.

Cómo funciona

Al abrir una sesión de terminal, SSHBorg lee el archivo de historial de shell del servidor remoto. Comprueba las siguientes ubicaciones en orden:

  1. ~/.bash_history — predeterminado para shells Bash
  2. ~/.zsh_history — predeterminado para Zsh (también comprobado como $HISTFILE si está configurado)
  3. ~/.local/share/fish/fish_history — para usuarios de Fish shell

Se usa el primer archivo que existe y es legible. Mientras escribes, los comandos se filtran en tiempo real y se muestran como chips en la barra de sugerencias. Pulsa un chip para insertar el comando.

Solución de problemas

No aparecen sugerencias

  • El archivo de historial puede que aún no exista (primer inicio de sesión o shell no configurada para guardar el historial).
  • Asegúrate de que tu shell esté configurada para guardar el historial. Para Bash, añade a ~/.bashrc: 
    HISTFILE=~/.bash_history
HISTSIZE=10000
HISTFILESIZE=20000
  • Para Zsh, añade a ~/.zshrc: 
    HISTFILE=~/.zsh_history
HISTSIZE=10000
SAVEHIST=10000
setopt APPEND_HISTORY SHARE_HISTORY

Las sugerencias pertenecen al usuario equivocado

// LIMITACIÓN CONOCIDA
Si te conectas como un usuario y luego ejecutas sudo su - root (o cambias a otro usuario con su), la barra de sugerencias sigue mostrando el historial del usuario de inicio de sesión original, no de root. Esto es porque SSHBorg lee el archivo de historial antes de que arranque el shell, usando las credenciales con las que te conectaste.

Para obtener sugerencias del historial de root, añade una entrada de host separada en SSHBorg configurada para iniciar sesión directamente como root (si tu servidor lo permite).

// REENVÍO DE AGENTE

El reenvío del agente SSH permite usar las claves almacenadas en SSHBorg para autenticar conexiones adicionales realizadas desde dentro del servidor remoto — por ejemplo, para git clone de un repo privado, o para saltar a una segunda máquina.

Activar el reenvío en SSHBorg

Al añadir o editar un host, activa el interruptor Reenvío de agente. SSHBorg actuará como agente SSH para esa sesión.

Configuración en el servidor

El servidor debe permitir el reenvío de agente. Comprueba /etc/ssh/sshd_config:

AllowAgentForwarding yes

Este es el valor predeterminado en la mayoría de sistemas. Después de modificarlo, reinicia el demonio SSH:

sudo systemctl restart sshd

Configuración de cliente por host (opcional)

Si también te conectas a este servidor desde un portátil o escritorio, puedes configurar el reenvío de forma permanente en tu ~/.ssh/config local:

Host myserver
    HostName 203.0.113.42
    User ubuntu
    ForwardAgent yes
// NOTA DE SEGURIDAD
El reenvío de agente da al servidor remoto acceso temporal al socket de tu agente SSH. Un usuario root (o un proceso comprometido) en ese servidor podría usar tus claves para conectarse a otros sitios mientras tu sesión está activa. Activa el reenvío solo en servidores de confianza.

// CAÍDAS DE CONEXIÓN Y MULTIPLEXORES DE TERMINAL

SSH es una conexión TCP activa entre tu teléfono y el servidor. Si la conexión se interrumpe — aunque sea por un segundo — la sesión y todo lo que se ejecutaba en ella se pierde.

Por qué caen las conexiones en móvil

Las redes móviles son especialmente propensas a las caídas de conexión por varias razones:

  • Cambios de dirección IP — al viajar o cambiar de antena, tu operador puede asignarte una nueva IP pública. Como las conexiones TCP están vinculadas a la dirección IP, la sesión SSH existente se invalida inmediatamente.
  • Cambio Wi-Fi ↔ datos móviles — cambiar entre una red Wi-Fi y datos móviles (o viceversa) cambia tu IP y rompe cualquier conexión TCP abierta.
  • Tiempos de espera por inactividad — los operadores y routers NAT suelen cerrar las conexiones inactivas tras unos minutos. Las sesiones activas pero silenciosas (observar logs, esperar entrada) son vulnerables.
  • Pérdida de señal — túneles, aparcamientos subterráneos o simplemente una señal débil pueden interrumpir brevemente la red, lo que es suficiente para matar una sesión.
// IMPORTANTE
Si estás ejecutando un comando largo (una compilación, una copia de seguridad, una migración de base de datos) directamente en el terminal SSH y la conexión cae, el comando se interrumpe inmediatamente. Cualquier trabajo parcial puede quedar en un estado inconsistente.

La solución: tmux o screen

Un multiplexor de terminal ejecuta una sesión persistente en el servidor, completamente independiente de tu conexión SSH. Si la conexión cae, la sesión y todo lo que ejecuta sigue funcionando. Al reconectarte, te reincorporas y encuentras todo exactamente como lo dejaste.

Es el hábito más útil para quien gestiona servidores desde el teléfono.

Inicio rápido con tmux

tmux está disponible en la mayoría de distribuciones Linux modernas y es la opción recomendada.

# Iniciar una nueva sesión con nombre
tmux new -s work

# Desconectarse de la sesión (dejarla en ejecución)
Ctrl+B, luego D

# Listar sesiones en ejecución
tmux ls

# Reconectarse a una sesión
tmux attach -t work

# Reconectarse a la sesión más reciente
tmux attach

Inicio rápido con screen

screen es más antiguo pero disponible en prácticamente cualquier sistema Unix, incluyendo imágenes mínimas donde tmux puede no estar instalado.

# Iniciar una nueva sesión con nombre
screen -S work

# Desconectarse de la sesión
Ctrl+A, luego D

# Listar sesiones en ejecución
screen -ls

# Reconectarse a una sesión
screen -r work

Flujo de trabajo recomendado en móvil

  1. Conéctate al servidor con SSHBorg.
  2. Inicia o reconéctate inmediatamente a una sesión tmux/screen: tmux attach || tmux new -s main
  3. Ejecuta tus comandos dentro del multiplexor.
  4. Si la conexión cae, simplemente vuelve a conectarte — tu sesión sigue ahí.
// CONSEJO
Puedes añadir tmux attach || tmux new -s main a tu ~/.bashrc o ~/.zshrc en el servidor para que una sesión de multiplexor se inicie automáticamente cada vez que inicies sesión a través de SSHBorg.

// JUMP HOSTS

Un jump host (también llamado bastion host) es un servidor intermedio a través del cual debes pasar para llegar a un servidor de destino no accesible directamente desde internet. SSHBorg admite cadenas de salto simples y multi-salto de forma nativa.

Configurar un jump host en SSHBorg

  1. Añade el servidor bastión como host normal en SSHBorg (p. ej. bastion).
  2. Añade el servidor de destino como otro host.
  3. En los ajustes del host de destino, establece Jump host en el bastión creado.
  4. Activa Reenvío de agente en la entrada del bastión — esto permite que tu clave se reenvíe a través del bastión para autenticarse en el destino.
// CÓMO FUNCIONA
SSHBorg establece primero una conexión SSH al bastión y luego abre un canal TCP reenviado a través de él hacia el servidor de destino. La clave privada nunca sale del teléfono — el bastión solo actúa como proxy del flujo cifrado.

Cadenas multi-salto

Si necesitas saltar a través de más de un servidor intermedio (p. ej. internet → bastión → dmz → destino), crea una entrada para cada salto y encadénalas:

  • bastion — sin jump host, reenvío de agente activo
  • dmz — jump host = bastion, reenvío de agente activo
  • target — jump host = dmz
// IMPORTANTE
El reenvío de agente debe estar activado en cada salto intermedio, no solo en el primero. Sin él, la cadena de autenticación se rompe y la conexión al servidor final fallará con un error "permission denied".

Configuración manual equivalente (como referencia)

La configuración equivalente en un ~/.ssh/config de escritorio tiene este aspecto:

Host bastion
    HostName bastion.example.com
    User admin
    ForwardAgent yes

Host target
    HostName 10.0.1.50
    User ubuntu
    ProxyJump bastion
    ForwardAgent yes

Con esta configuración, ssh target en tu portátil salta de forma transparente a través del bastión.

Requisitos del cortafuegos

  • Tu teléfono debe poder llegar al bastión en su puerto SSH (normalmente el 22).
  • El bastión debe poder llegar al destino en su puerto SSH.
  • El destino no necesita ser accesible directamente desde tu teléfono.

// SESIONES MÚLTIPLES

SSHBorg te permite mantener abiertas varias sesiones de terminal SSH y gestor de archivos SFTP al mismo tiempo, incluso hacia servidores diferentes.

  • Abre una sesión desde la pantalla de hosts pulsando Terminal o SFTP.
  • Cambia entre sesiones abiertas usando el selector de sesiones en la parte superior de la pantalla.
  • Las sesiones permanecen activas en segundo plano mientras se mantenga la conexión de red.
  • La lista de hosts muestra un pequeño indicador junto a cada host con el número de sesiones SSH y SFTP activas, para ver de un vistazo qué está abierto.
// CONSEJO
Los comandos de larga duración (compilaciones, copias de seguridad, seguimiento de logs) siguen ejecutándose aunque cambies a otra sesión. Usa un multiplexor de terminal como tmux o screen en el servidor si quieres que sobrevivan incluso a una caída de la conexión SSH.

// SEGURIDAD DE LA APP

Bloqueo biométrico

Activa el bloqueo biométrico en Ajustes → Seguridad → Bloqueo biométrico. Cuando está activo, SSHBorg requiere huella dactilar o reconocimiento facial antes de mostrar cualquier host, credencial o dato de sesión.

Puedes establecer un tiempo de espera por inactividad — tras ese número de minutos en segundo plano, la app se bloquea automáticamente.

Protección de capturas de pantalla

Por defecto, SSHBorg bloquea las capturas de pantalla y la grabación de pantalla para evitar que el contenido sensible del terminal se filtre a través de la pantalla de apps recientes o herramientas de captura.

Si necesitas hacer una captura (p. ej. para compartir una salida del terminal), puedes desactivar temporalmente la protección en Ajustes → Seguridad → Permitir capturas.

Almacenamiento de credenciales

Todas las credenciales (contraseñas, claves privadas, frases de contraseña) se almacenan cifradas usando el Android Keystore — un enclave seguro respaldado por hardware disponible en Android 10+. Nunca se escriben en almacenamiento externo ni se transmiten a ningún lugar.

// NOTA SOBRE COPIAS DE SEGURIDAD
Como las claves se almacenan en el Android Keystore, no pueden incluirse en la copia de seguridad en la nube de Android y no se transferirán automáticamente a un nuevo teléfono. Antes de cambiar de dispositivo, asegúrate de autorizar una nueva clave generada en el nuevo dispositivo en todos tus servidores.
⚙⚙⚙