Encontrar la clave por su huella
Un comentario como alice@laptop se puede cambiar y no prueba nada, así que busca por huella. Si tienes la clave pública:
ssh-keygen -lf alice.pub
256 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg alice@laptop (ED25519)
Si no la tienes, el registro del servidor muestra qué clave usó cada inicio de sesión:
Accepted publickey for deploy from 203.0.113.10 port 33998 ssh2: ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg
Consulta cómo revisar los inicios de sesión SSH para saber dónde está ese registro.
Buscar en un servidor
Ejecuta esto como root, porque cada ~/.ssh es privado para su propietario:
sudo bash -c '
FP="SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg"
for f in /root/.ssh/authorized_keys* /home/*/.ssh/authorized_keys*; do
[ -f "$f" ] && ssh-keygen -lf "$f" | grep -F "$FP" && echo " found in $f"
done'
Revisa si hay cuentas de servicio con el home en otro sitio, y si hay un AuthorizedKeysFile distinto:
sudo sshd -T | grep -i authorizedkeysfile
getent passwd | cut -d: -f1,6
Buscar en todos los servidores
Guarda la búsqueda anterior como un script en cada servidor, o ejecútala con un bucle desde tu propia máquina. La lista de hosts la pones tú, y aquí sudo no debe pedir contraseña:
while read -r host; do
echo "== $host"
ssh -n "$host" sudo /usr/local/bin/find-ssh-key
done < hosts.txt
No olvides las máquinas que no son servidores en el sentido habitual: alojamiento de Git, dispositivos de red, jump hosts, runners de CI y destinos de copias de seguridad.
Por qué hace falta -n en ese bucle lo explica cómo ejecutar un comando por SSH.
Eliminar la clave
Busca por la clave en sí, no por el comentario, y haz una copia de seguridad:
KEY=$(cut -d' ' -f2 alice.pub)
f=/home/deploy/.ssh/authorized_keys
sudo cp -p "$f" "$f.bak"
sudo grep -vF "$KEY" "$f.bak" | sudo tee "$f" > /dev/null
Borra la copia de seguridad cuando hayas comprobado que los demás aún pueden iniciar sesión. La misma clave puede aparecer en más de una línea, y esto las elimina todas.
Bloquearla con RevokedKeys
Quitar las líneas arregla lo que encontraste. RevokedKeys además bloquea la clave en cualquier cuenta donde no la hayas encontrado, o donde vuelvan a añadirla. La forma más simple es un archivo de claves públicas:
sudo cp alice.pub /etc/ssh/revoked_keys
sudo chmod 644 /etc/ssh/revoked_keys
# /etc/ssh/sshd_config.d/10-revoked.conf
RevokedKeys /etc/ssh/revoked_keys
sudo sshd -t && sudo systemctl reload ssh
El servicio se llama sshd en sistemas Red Hat y Fedora. Un inicio de sesión con esa clave ahora falla, y el registro dice:
Authentication key ED25519 SHA256:NxFS05Q+k1zf9LgrjGPL94UJfFS6B/89THkWACOEJgg revoked by file /etc/ssh/revoked_keys
Crea el archivo antes de añadir el ajuste. Si falta o no se puede leer, sshd rechaza los inicios de sesión con clave pública de todos los usuarios. En nuestra prueba el registro decía Error checking authentication key ... in revoked keys file. Un archivo vacío sirve.
Un KRL para muchas claves
Una Key Revocation List (KRL) es una versión binaria compacta del mismo archivo, y el ajuste es el mismo. Crea una y añade a ella con -u. Sin -u, reemplaza lo que había:
sudo ssh-keygen -k -f /etc/ssh/revoked_keys alice.pub
sudo ssh-keygen -k -u -f /etc/ssh/revoked_keys bob.pub
Comprueba una clave contra ella:
ssh-keygen -Q -f /etc/ssh/revoked_keys alice.pub
alice.pub (alice@laptop): REVOKED
Una clave que no está en la lista muestra ok. El código de salida es 1 cuando una clave está revocada y 0 cuando no lo está, lo cual es útil en scripts. Puedes listar el contenido de un KRL con ssh-keygen -Q -l -f /etc/ssh/revoked_keys.
Cerrar las sesiones ya abiertas
Una clave revocada solo detiene los inicios de sesión nuevos. En nuestra prueba, una sesión abierta antes de quitar la clave siguió funcionando y terminó con normalidad. Busca sesiones abiertas con who, y si es la cuenta de esa persona, ciérralas:
sudo pkill -KILL -u alice
Esto mata todo lo que esa cuenta esté ejecutando, así que no lo uses en una cuenta compartida sin mirar antes.
Cerrar la cuenta
Algunos comandos habituales hacen menos de lo que esperarías. Probamos cada uno con una clave que funcionaba:
| Comando | ¿Puede la clave seguir entrando? |
|---|---|
passwd -l alice | Sí. Bloquea solo la contraseña. |
usermod -s /usr/sbin/nologin alice | No obtiene shell, pero los túneles ssh -L siguen funcionando. |
chage -E 0 alice | No. El registro dice Access denied for user alice by PAM account configuration. |
Usa chage -E 0 para bloquear la cuenta de inmediato, y bórrala más tarde con userdel cuando sepas que nada depende de ella.
Todo lo demás que la persona conocía
Si la persona tenía acceso a una cuenta compartida o al root de un servidor, una clave puede ser solo una parte. Revisa:
- Cuentas compartidas: cambia sus claves y contraseñas.
- Claves privadas que pudiera leer, como las deploy keys: cámbialas y revoca las antiguas.
- Crontabs y archivos
sudoersque la mencionen. - Claves añadidas en otras cuentas. Compara lo que hay en cada archivo
authorized_keyscon lo que esperas que haya.
Para facilitarlo la próxima vez: certificados de corta vida
Con certificados SSH no hay una lista de claves en cada servidor. El servidor confía en una autoridad de certificación, y cada certificado caduca solo. Esto firma una clave durante ocho horas, para la cuenta deploy:
ssh-keygen -s user_ca -I alice@example.com -n deploy -V +8h -z 1001 alice.pub
Cuando alguien se va, deja de firmar para esa persona. El último certificado deja de funcionar por sí solo, y el registro dice Certificate invalid: expired. Para cortar un certificado antes, revócalo por identidad o por número de serie. Escribe un archivo pequeño llamado spec:
id: alice@example.com
serial: 1001
sudo ssh-keygen -k -u -f /etc/ssh/revoked_keys -s user_ca.pub spec
Consulta certificados SSH explicados para la configuración.
Preguntas
¿Borrar un usuario de Linux quita su acceso SSH?
Borrar la cuenta con userdel impide entrar en ella. Bloquear solo la contraseña con passwd -l no basta: una clave sigue entrando. Su clave también puede estar en otras cuentas, así que busca por huella.
¿Se cierran las sesiones SSH abiertas al quitar una clave?
No. Quitar o revocar una clave solo frena los accesos nuevos. Cierra las sesiones ya abiertas, por ejemplo con pkill sobre la cuenta de la persona.
¿Qué es una KRL de OpenSSH?
Una Key Revocation List: un archivo binario compacto de claves y certificados revocados, creado con ssh-keygen -k e indicado con RevokedKeys en sshd_config.