Problema

En entornos con varios servidores y más de un equipo cliente (portátiles, desktop, máquinas de CI), la proliferación de claves SSH rápidamente se vuelve inmanejable. Cada vez que se añade o se pierde un dispositivo, la lista de claves autorizadas en cada servidor debe actualizarse. Sin una estrategia clara, se corre el riesgo de:

  • Dejar claves huérfanas que siguen permitiendo acceso.
  • No poder revocar el acceso de un dispositivo comprometido sin afectar a los demás.
  • Confundir cuál clave corresponde a cuál máquina, lo que dificulta auditorías y rotaciones periódicas.

El desafío es mantener una relación uno‑a‑uno entre dispositivos cliente y sus credenciales, sin que esa relación se vuelva una tabla de Excel imposible de mantener.

Causa

  1. Uso de una única clave maestra
    Copiar la misma clave privada a todos los dispositivos simplifica la configuración inicial, pero cualquier pérdida o robo compromete todo el parque.

  2. Falta de inventario estructurado
    Sin un registro que asocie dispositivo, huella de la clave pública y servidores donde está autorizada, la revocación se vuelve manual y propensa a errores.

  3. Mezcla de claves de usuario y de automatización
    Cuando los scripts de backup o despliegue reutilizan la misma clave que el usuario interactivo, se pierde la granularidad de permisos.

  4. Ignorar la separación entre host keys y user keys
    Confundir la función de la clave del servidor (host key) con la del cliente lleva a prácticas inseguras, como copiar la clave privada del servidor a los clientes.

Solución

Adoptar un modelo de una clave por dispositivo cliente y una clave por cuenta de automatización. Cada clave tiene su propio comentario y passphrase, y se gestiona mediante un inventario sencillo (por ejemplo, un archivo YAML o una hoja de cálculo). El flujo básico es:

  1. Generar una clave única por dispositivo
    Utiliza ed25519 por su tamaño reducido y resistencia criptográfica. Incluye un comentario descriptivo ("alex-laptop").

  2. Distribuir solo la clave pública
    Copia la clave pública a los servidores que necesiten acceso, añadiéndola al archivo ~/.ssh/authorized_keys del usuario correspondiente. Nunca copies la clave privada al servidor.

  3. Mantener un inventario central
    Registra: nombre del dispositivo, huella (ssh-keygen -lf <pubkey>), usuarios/servidores donde está autorizada, fecha de creación y fecha de última rotación.

  4. Rotación periódica
    Cada 6‑12 meses (o al detectar una pérdida) genera una nueva clave, actualiza el inventario y reemplaza la entrada en authorized_keys. Deja la clave antigua en el inventario hasta confirmar que todos los procesos críticos migraron.

  5. Cuentas de servicio separadas
    Para backups, despliegues o CI, crea usuarios dedicados en los servidores y asigna claves exclusivas a esas cuentas. Limita los permisos con authorized_keys (por ejemplo, command="rsync --server ...").

  6. Procedimiento de revocación
    Cuando un dispositivo se pierde, busca su huella en el inventario y elimina la línea correspondiente de authorized_keys en cada servidor. Usa ssh-copy-id -f -i <pubkey> user@host para actualizar de forma automática.

Herramientas útiles

  • ssh-keygen – generación y gestión de claves.
  • ssh-copy-id – copia segura de claves públicas.
  • ansible o fabric – automatiza la inserción/eliminación de claves en varios servidores.
  • git – versiona el archivo de inventario para auditoría.

Cuándo aplicar esta solución

  • Entornos con >2 dispositivos cliente que acceden a varios servidores.
  • Necesidad de revocar acceso rápidamente (pérdida de laptop, compromiso de cuenta).
  • Política de cumplimiento que exige rotación de credenciales y trazabilidad.
  • Automatización donde los scripts requieren permisos limitados y diferenciados.

No es necesario si solo manejas un único servidor y un único cliente; en ese caso una sola clave puede ser suficiente y la sobrecarga de inventario no se justifica.

Código

# 1. Generar clave Ed25519 con comentario y passphrase
ssh-keygen -t ed25519 -C "alex-laptop" -f ~/.ssh/id_ed25519_alex_laptop

# 2. Ver huella de la clave pública (para el inventario)
ssh-keygen -lf ~/.ssh/id_ed25519_alex_laptop.pub

# 3. Copiar la clave pública a un servidor remoto
ssh-copy-id -i ~/.ssh/id_ed25519_alex_laptop.pub [email protected]

# 4. Añadir restricción de comando (ejemplo para backup)
cat <<EOF >> ~/.ssh/authorized_keys
command="/usr/local/bin/backup.sh",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE... backup-key
EOF

Verificación

  1. Conexión con la nueva clave

    ssh -i ~/.ssh/id_ed25519_alex_laptop [email protected] "echo ok"

    Debe devolver ok sin solicitar contraseña.

  2. Comprobar que la clave antigua ya no funciona (si se revocó). Intenta conectar con la clave retirada; la autenticación debe fallar.

  3. Validar inventario
    Ejecuta un script que compare la huella almacenada con la presente en authorized_keys de cada servidor:

    for host in server1.example.com server2.example.com; do
  ssh user@$host "grep -F \"$(ssh-keygen -lf ~/.ssh/id_ed25519_alex_laptop.pub | awk '{print $2}')\" ~/.ssh/authorized_keys && echo present || echo missing"
done

Notas adicionales

  • Passphrase vs. agente SSH: Usa una passphrase fuerte y carga la clave en ssh-agent para evitar escribirla en cada sesión. Si el agente se compromete, revoca la clave inmediatamente.
  • Backup del inventario: Guarda el archivo de inventario en un repositorio privado y cifrado; sin él, la revocación será un proceso manual y propenso a errores.
  • Host key verification: No confundas la gestión de host keys con la de user keys. Mantén el archivo ~/.ssh/known_hosts actualizado y verifica que los fingerprints de los servidores coincidan con los esperados.
  • Múltiples usuarios en el mismo dispositivo: Si varios usuarios comparten una laptop, cada uno debe tener su propio par de claves y su propio registro en el inventario.
  • Herramientas de gestión centralizada: En entornos más grandes, considera soluciones como HashiCorp Vault SSH secrets engine o FreeIPA para delegar la emisión y revocación automática de claves.

Con este enfoque, la gestión de SSH keys deja de ser un dolor de cabeza y se convierte en un proceso repetible, auditable y fácil de escalar.