El reenvío de agente SSH mediante el parámetro -A o la directiva ForwardAgent yes permite utilizar claves privadas locales en un servidor intermedio sin copiarlas en él. Sin embargo, este mecanismo crea un socket UNIX que cualquier usuario con privilegios de administrador en la máquina de salto puede secuestrar para autenticarse hacia otros servidores.
El mecanismo del secuestro de socket en SSH agent forwarding
OpenSSH almacena el socket de comunicación del agente en una ruta temporal definida por la variable de entorno SSH_AUTH_SOCK en el host remoto, habitualmente bajo el directorio /tmp/ssh-XXXXXXXXXX/agent.<ppid>. Aunque este descriptor de archivo pertenece exclusivamente al usuario que inició la sesión y cuenta con permisos restrictivos, el usuario root o cualquier proceso con capacidades administrativas en dicho servidor intermedio tiene acceso completo para leer y escribir sobre él.
Cuando un atacante obtiene control sobre la máquina intermedia (frecuentemente llamada bastion host o salto), no necesita extraer tu clave privada, ya que esta nunca abandona la memoria del cliente local. Al atacante le basta con secuestrar la variable de entorno para realizar peticiones de firma criptográfica directamente hacia tu agente local mientras tu sesión permanezca abierta:
# Enumeración de sockets activos de otros usuarios en el servidor intermedio
ls -la /tmp/ssh-*/agent.*
# Secuestro del agente para autenticarse contra un servidor interno
export SSH_AUTH_SOCK=/tmp/ssh-AbCdEf1234/agent.5678
ssh [email protected]El proceso ssh-agent en tu equipo cliente firmará los desafíos de autenticación enviados por el servidor de destino creyendo que provienen de tus propias acciones. Este vector es crítico si el salto intermedio es compartido por varios operadores, si está expuesto directamente a Internet o si aloja servicios adicionales que aumentan su superficie de ataque.
Comparativa de seguridad entre Agent Forwarding y ProxyJump
La directiva ProxyJump, introducida en versiones modernas de OpenSSH y accesible con el parámetro -J, elimina por completo la necesidad de exponer un agente de autenticación en el host intermedio. Con ProxyJump, el cliente local establece un canal TCP directo cifrado de extremo a extremo hacia el servidor final a través de ProxyCommand o stdio, tratando al intermediario como un mero enrutador sin visibilidad de las credenciales ni acceso al socket de firmas.
| Criterio de análisis | Agent Forwarding (-A) | ProxyJump (-J) |
|---|---|---|
| Exposición del socket | Crea socket UNIX accesible por root remoto. | No crea sockets en el nodo intermedio. |
| Cifrado de la sesión | Punto a punto por cada salto individual. | Cifrado extremo a extremo hasta el destino. |
| Superficie ante intrusiones | Compromete accesos a toda la infraestructura. | Aísla el tráfico del host intermedio comprometido. |
| Compatibilidad nativa | Soportado en todas las versiones históricas. | Estándar recomendado en OpenSSH moderno. |
Al utilizar ProxyJump, incluso si un atacante obtiene privilegios de root en la máquina de salto mientras estás conectado, solo observará paquetes de datos cifrados dirigidos al puerto TCP 22 del nodo final, sin capacidad de ordenar firmas arbitrarias a tu agente.
Configuración segura en ~/.ssh/config para entornos bastion
OpenSSH espera permisos estrictos de 700 para el directorio ~/.ssh y 600 para el archivo config y las claves privadas. En lugar de activar ForwardAgent yes de manera global —lo que representa un riesgo crítico de seguridad—, la configuración recomendada define saltos seguros de forma transparente para el operador:
# Configuración recomendada en ~/.ssh/config
Host bastion
HostName bastion.ejemplo.com
User admin
Port 22
IdentityFile ~/.ssh/id_ed25519
ForwardAgent no
Host servidor-interno
HostName 10.0.1.50
User deploy
IdentityFile ~/.ssh/id_interno
ProxyJump bastionCon este bloque configurado, ejecutar simplemente ssh servidor-interno iniciará la conexión SSH hacia el destino pasando a través de bastion de forma cifrada y autónoma. OpenSSH admite claves modernas Ed25519 desde la versión 6.5 (enero de 2014) y claves FIDO2 hardware ed25519-sk desde la versión 8.2 (febrero de 2020), mientras que desde OpenSSH 8.8 (septiembre de 2021) el algoritmo inseguro ssh-rsa con SHA-1 está desactivado por defecto.
Gestión de saltos y sesiones seguras desde el móvil
En dispositivos móviles, las claves SSH generadas en la terminal SSH para iOS y Android termi1 se guardan exclusivamente en el almacén seguro del sistema (Secure Enclave o Keystore), garantizando que la clave privada nunca sale del dispositivo ni se transmite a servidores externos. Cuando se gestionan infraestructuras desde redes móviles inestables, el protocolo Mosh resulta ideal al mantener la sesión activa al cambiar de Wi-Fi a datos mediante UDP (habitualmente en los puertos 60000-61000).
Sin embargo, Mosh no admite port forwarding ni túneles TCP. Si necesitas alcanzar máquinas en subredes privadas sin IP pública ni puertos abiertos, una alternativa sólida a los bastiones SSH tradicionales consiste en integrar redes privadas en malla basadas en WireGuard como redes privadas en malla sin abrir puertos (Prialo) o Tailscale. Con esta topología, cada servidor y dispositivo móvil cuenta con una IP directa dentro de la malla, haciendo innecesario el uso de intermediarios o configuraciones de ForwardAgent.
Si debes operar directamente sobre servidores remotos mediante un salto clásico, contar con herramientas móviles especializadas mitiga riesgos operativos: el teclado con plano fn y teclas Ctrl y Esc evita errores tipográficos en consolas críticas, y funciones como Production Guard impiden la ejecución automática accidental de comandos destructivos en hosts de producción.
Preguntas frecuentes
¿Cuándo es aceptable utilizar ssh -A con agent forwarding?
El parámetro ssh -A solo es admisible de forma puntual hacia servidores totalmente confiables de un único usuario. En cualquier escenario con servidores intermedios compartidos, hosts públicos o máquinas cuya administración recaiga en terceros, el reenvío de agente representa una vulnerabilidad crítica que debe evitarse a favor de ProxyJump.
¿Puede un atacante robar mi clave privada a través del socket secuestrado?
La clave privada nunca se transmite a través del socket de ssh-agent ni se almacena en el host remoto. El atacante únicamente puede secuestrar el socket para firmar peticiones de autenticación en tiempo real mientras el cliente mantenga la sesión SSH abierta hacia dicho servidor.
¿Cómo reemplaza ProxyJump al parámetro ForwardAgent en la línea de comandos?
El parámetro ProxyJump se invoca directamente en la consola mediante la opción -J sin necesidad de modificar archivos. Ejecutar ssh -J usuario@bastion usuario@destino conecta directamente con el servidor final tunelizando la autenticación en origen, lo que elimina el socket intermedio y protege las credenciales locales.
¿Es compatible Mosh con el reenvío de agentes y túneles SSH?
El protocolo Mosh no es compatible con el reenvío de agentes, port forwarding ni túneles TCP porque opera exclusivamente sobre paquetes UDP tras el inicio de sesión inicial. Para administrar redes internas mediante Mosh, se debe utilizar una red en malla como Prialo o abrir una sesión SSH estándar previa.