Claves SSH expuestas: por qué una id_rsa filtrada equivale a dar acceso al servidor

Encontrar una clave privada SSH en un servidor durante una auditoría es uno de los hallazgos más valiosos: se parece más a encontrar una llave que a adivinar una contraseña. Si la clave corresponde a una cuenta del sistema (o, mejor, a varias cuentas en varios servidores), el acceso es inmediato, sin necesidad de romper hashes ni probar diccionarios.

En los laboratorios de whoami-labs es una vía muy frecuente para pasar de un usuario a otro o para moverse entre máquinas. Y en situaciones reales, las claves expuestas en repositorios de código, en copias de seguridad olvidadas o en carpetas compartidas son una causa habitual de intrusiones.

En esta lección vas a ver cómo funciona la autenticación por clave en SSH, por qué una clave privada filtrada entrega el acceso, qué buscar en una máquina recién comprometida, qué hacer con una clave privada encontrada y cómo gestionar las claves SSH de forma que un robo no se convierta en un desastre.

Practica solo en sistemas propios o en entornos autorizados, como los laboratorios de whoami-labs. Usar una clave SSH para entrar a un servidor sin permiso es un delito.

Cómo funciona la autenticación por clave en SSH#

SSH permite autenticarse de varias formas; la más segura y más usada es con un par de claves: una clave privada que solo tiene el usuario, y una clave pública que se copia en los servidores a los que quiere acceder.

Al conectarse, el servidor envía un reto al cliente. El cliente lo firma con su clave privada y devuelve la firma. El servidor comprueba esa firma con la clave pública que tiene almacenada en el archivo ~/.ssh/authorized_keys del usuario: si la firma es válida, el acceso se concede. La clave privada nunca viaja por la red.

Un archivo authorized_keys típico contiene una línea por cada clave pública autorizada:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK... usuario@equipo
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... backup@respaldo

Y las claves privadas suelen estar en el directorio ~/.ssh/ con nombres como id_rsa, id_ed25519 o id_ecdsa. Un archivo que empieza por -----BEGIN OPENSSH PRIVATE KEY----- es, directamente, el acceso a una cuenta.

Por qué una clave filtrada equivale al acceso#

A diferencia de una contraseña, no hay ninguna protección añadida: si tienes la clave privada y conoces el usuario, entras. Las dos únicas defensas serían:

• Frase de paso (passphrase): la clave está cifrada con una frase que el usuario debe teclear. Si un atacante encuentra una clave cifrada, puede intentar crackearla sin conexión con john o hashcat.
• Autenticación multifactor (MFA): ciertas configuraciones de SSH combinan la clave con un segundo factor. No es la configuración por defecto.

En la práctica, muchas claves se generan sin frase de paso para facilitar la automatización (copias de seguridad, despliegues, tareas cron entre servidores), y pocas empresas aplican MFA a SSH. Por eso una clave encontrada suele dar acceso inmediato.

Dónde se filtran en la vida real#

Algoritmos y formatos de clave que vas a encontrar#

Reconocer el tipo es útil para elegir las herramientas correctas y para saber qué esperar: las claves RSA son más largas, las Ed25519 ocupan solo unas pocas líneas. Si encuentras una *.pem, es casi seguro una clave de administración de alguna máquina en la nube.

Cómo se enumeran en un laboratorio#

Tras conseguir una shell en un laboratorio autorizado, estas son las búsquedas estándar para encontrar claves y otros archivos relacionados con SSH:

# Tu propia carpeta .ssh
ls -la ~/.ssh

# Claves privadas en todo el sistema (lo que tu usuario puede leer)
find / -name "id_rsa" -o -name "id_ed25519" -o -name "id_ecdsa" 2>/dev/null
find / -name "*.pem" -o -name "*.key" 2>/dev/null

# Archivos que empiecen con la cabecera de una clave privada
grep -r "BEGIN OPENSSH PRIVATE KEY" / 2>/dev/null
grep -r "BEGIN RSA PRIVATE KEY" / 2>/dev/null

# authorized_keys de otros usuarios (indica a qué cuentas se puede llegar)
find / -name "authorized_keys" 2>/dev/null

# El archivo known_hosts dice a qué servidores se ha conectado la cuenta
cat ~/.ssh/known_hosts
cat /home/*/.ssh/known_hosts 2>/dev/null

# Configuraciones personales de SSH: atajos, claves asociadas, puertos
cat ~/.ssh/config 2>/dev/null

En muchos laboratorios, el camino es: encontrar una clave privada legible en el /home de otro usuario, o en una copia de seguridad que algún script dejó accesible, y usarla para entrar como ese usuario.

Qué hacer con una clave privada encontrada#

Paso 1: identificar a quién pertenece#

Si la clave encontrada es de otro usuario (no la tuya), el comentario al final de la clave pública del usuario te suele indicar el dueño (maria@servidor, backup@). También puede aparecer en el entorno o en scripts que la usen.

Paso 2: copiarla a un archivo con permisos correctos#

SSH se niega a usar claves privadas que cualquiera pueda leer. Al usar la clave desde tu equipo:

# En tu equipo del laboratorio
nano clave_maria   # pega aquí el contenido
chmod 600 clave_maria

Si los permisos son más abiertos, SSH responderá con un error como «Permissions are too open».

Paso 3: conectarse#

ssh -i clave_maria maria@IP_DEL_LAB

Paso 4: si la clave tiene frase de paso#

Si al conectar SSH pide una frase y no la sabes, puedes intentar crackearla sin conexión. Primero extrae el formato que entiende John the Ripper:

ssh2john.py clave_maria > clave_maria.hash
john --wordlist=/usr/share/wordlists/rockyou.txt clave_maria.hash

Con hashcat, el modo 22921 corresponde a claves OpenSSH protegidas por frase de paso. Si el diccionario encuentra la frase, ya puedes conectar.

Paso 5: añadir tu propia clave como persistencia#

Una vez dentro, si quieres volver a entrar aunque cambien la clave original, puedes añadir tu clave pública al authorized_keys de ese usuario (solo en el laboratorio autorizado):

echo 'ssh-ed25519 AAAA... auditor@mi-equipo' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

En una auditoría real, cualquier cambio de este tipo debe documentarse para que el cliente lo revierta al terminar.

Reutilización y movimiento lateral#

Las claves SSH son especialmente peligrosas porque se reutilizan. Una misma clave se usa muchas veces para:

• Conectarse desde un servidor de respaldo a decenas de servidores de producción.
• Desplegar aplicaciones desde una máquina de CI/CD a muchos entornos.
• Automatizar tareas entre servidores internos.

Cuando encuentras una clave en un laboratorio, prueba a usarla contra otros usuarios y contra otros servidores de la red interna: es la forma más rápida de movimiento lateral. Revisa ~/.ssh/known_hosts (puede estar «hashed», pero a veces no) y la configuración de SSH del usuario comprometido para saber a dónde solía conectarse.

Cómo gestionar las claves de forma segura#

Una clave por rol, no una clave para todo#

Separa las claves según su función: una clave para tu cuenta personal, otra para cada automatización, otra para despliegues. Si una se filtra, el daño queda limitado.

Siempre con frase de paso#

Protege las claves personales con una frase de paso robusta. Si necesitas que una clave funcione sin interacción (para una tarea cron entre servidores), restringe lo que esa clave puede hacer con las opciones del authorized_keys del destino:

command="/usr/local/bin/respaldo",no-port-forwarding,no-x11-forwarding,no-pty ssh-ed25519 AAAA...

Con command=, esa clave solo puede ejecutar ese programa concreto en el servidor. Aunque alguien la robe, no podrá hacer nada más.

No almacenar claves en repositorios#

Añade .ssh/, *.pem, *.key y variantes al .gitignore global, y usa herramientas como gitleaks o trufflehog para detectar secretos en los repositorios antes de publicarlos.

Rotación y vencimiento#

Crea una política para rotar las claves periódicamente. SSH no tiene fecha de caducidad en las claves normales, pero sí en los certificados OpenSSH, que son el mecanismo más adecuado en empresas grandes: un certificado firmado por una autoridad, con vencimiento corto, que sustituye a los archivos authorized_keys manuales.

Deshabilitar contraseñas en el servidor#

Con la autenticación por clave bien configurada, lo coherente es desactivar las contraseñas:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin prohibit-password

Así se evita la mitad de los intentos de intrusión que ves en cualquier servidor expuesto a internet.

Errores comunes#

• Generar claves sin frase de paso «por comodidad». Si la clave se filtra, el impacto es total.
• Copiar ~/.ssh a otros servidores. Una misma clave para todo multiplica el impacto de cualquier filtración.
• Dejar authorized_keys escribible. Un atacante puede añadir su propia clave y conservar acceso.
• Olvidar que known_hosts revela información. Enseña a qué servidores se conecta la cuenta.
• Usar la cuenta root para administración remota. Es preferible un usuario normal con sudo.

Preguntas frecuentes#

¿Qué diferencia hay entre id_rsa e id_ed25519?#

id_rsa usa el algoritmo RSA; id_ed25519 usa curvas elípticas Ed25519. Ed25519 produce claves más cortas, más rápidas y consideradas más seguras: es la recomendación actual para claves nuevas.

¿La clave pública es secreta?#

No. La clave pública se puede compartir sin problema (se copia en authorized_keys de cada servidor al que quieras acceder). La que debe mantenerse en secreto es la privada.

¿Cómo sé si una clave encontrada tiene frase de paso?#

Si al abrirla ves Proc-Type: 4,ENCRYPTED o DEK-Info:, está cifrada con una frase. En el formato OpenSSH moderno, intentar usarla con ssh-keygen -y -f clave te la pedirá si la tiene.

¿Qué son los certificados SSH?#

Un mecanismo donde una autoridad firma una clave pública con un vencimiento, de forma que el servidor solo necesita confiar en la autoridad. Permite rotar accesos sin tocar cada authorized_keys.

¿Dónde practico?#

En los laboratorios de whoami-labs enlazados al final de esta lección, donde encontrar y usar claves SSH es parte del recorrido para resolver el reto.

Resumen#

• SSH se autentica con un par de claves: la privada queda en el cliente y la pública se copia en authorized_keys del servidor.
• Una clave privada filtrada entrega el acceso: no hay segundo factor por defecto, y muchas claves no tienen frase de paso.
• Se buscan con find sobre nombres típicos y con grep sobre la cabecera BEGIN ... PRIVATE KEY.
• Al encontrarlas: permisos 600, intentar la conexión, y si tienen frase, crackearla sin conexión con john o hashcat (modo 22921).
• Para defenderse: una clave por rol, frase de paso, restricciones con command=, rotación, certificados y sin contraseñas en SSH.

Fuentes y lecturas recomendadas#

• Página de manual de ssh
• Página de manual de ssh-keygen
• Página de manual de sshd_config
• Hashcat: modos de ataque y ejemplos de hash
• MITRE ATT&CK T1552.004: Private Keys