TL;DR — Resumen Rápido

Guía de gestión de claves SSH para sysadmins: genera claves Ed25519, usa ssh-agent, configura ~/.ssh/config, rota y revoca claves y usa certificados SSH.

Las claves SSH son la base del acceso remoto seguro para todo sysadmin y profesional de DevOps. Esta guía de gestión de claves SSH cubre el ciclo de vida completo: generar claves, cachearlas con ssh-agent, organizar múltiples hosts con ~/.ssh/config, desplegar claves públicas, rotar y revocar credenciales comprometidas, escalar con certificados SSH y fortalecer el acceso con llaves de hardware.

Requisitos Previos

  • Linux, macOS o WSL con cliente OpenSSH (ssh, ssh-keygen, ssh-agent, ssh-copy-id).
  • Acceso SSH a al menos un servidor remoto para practicar.
  • Opcional: ssh-audit (pip install ssh-audit) para auditoría de algoritmos.
  • Opcional: YubiKey u otra llave FIDO2 para máxima protección.

Generación de Claves SSH: Ed25519 vs RSA

Ed25519 (recomendado)

ssh-keygen -t ed25519 -C "tu@ejemplo.com"

Ed25519 usa criptografía de curva elíptica sobre Curve25519. Las claves son de 256 bits, las firmas son rápidas y el algoritmo es resistente a ataques de canal lateral. Es la opción predeterminada para todas las claves nuevas.

RSA (compatibilidad heredada)

ssh-keygen -t rsa -b 4096 -C "tu@ejemplo.com"

Usa RSA-4096 solo cuando el sistema remoto no soporte Ed25519, por ejemplo versiones muy antiguas de OpenSSH (< 6.5) o ciertos dispositivos de red. RSA-2048 ya no se recomienda.

Mejores prácticas para contraseñas

  • Siempre establece una contraseña. Cifra tu clave privada en disco. Una clave robada sin la contraseña es inútil.
  • Usa al menos 20 caracteres — una contraseña aleatoria de tu gestor de contraseñas es ideal.
  • Guárdala en tu gestor de contraseñas (1Password, Bitwarden, pass).

SSH Agent: Caché de Claves en la Sesión

# Iniciar el agente
eval "$(ssh-agent -s)"

# Agregar la clave (solicita contraseña una vez)
ssh-add ~/.ssh/id_ed25519

# Listar claves cargadas
ssh-add -l

# Eliminar todas las claves
ssh-add -D

Consejo de seguridad: Pasa -t 3600 a ssh-add para expirar automáticamente la clave después de una hora:

ssh-add -t 3600 ~/.ssh/id_ed25519

Archivo de Configuración SSH: Gestión de Múltiples Hosts

# ~/.ssh/config

# Ajustes predeterminados para todos los hosts
Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Servidor web de producción
Host prod-web
    HostName 203.0.113.10
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519_prod

# Servidor de base de datos interno via jump host
Host db-internal
    HostName 10.0.1.50
    User dbadmin
    ProxyJump prod-web

# GitHub
Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Con esta configuración, ssh prod-web conecta con el usuario y la clave correctos, y ssh db-internal tuneliza automáticamente a través del bastion.

Despliegue de Claves Públicas

ssh-copy-id (más fácil)

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@host

Despliegue manual

cat ~/.ssh/id_ed25519.pub | ssh usuario@host \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && \
   chmod 600 ~/.ssh/authorized_keys"

Permisos de archivos — crítico

RutaPermisoPor qué
~/.ssh/700Solo el propietario puede listar/entrar
~/.ssh/id_ed25519600Clave privada — solo lectura/escritura del propietario
~/.ssh/id_ed25519.pub644Clave pública — legible por todos
~/.ssh/authorized_keys600Solo el propietario puede modificar
~/.ssh/config600Evita que otros lean tu configuración

SSH rechazará usar claves con permisos de lectura universal y fallará silenciosamente.

Estrategias de Rotación de Claves

Rota las claves SSH cuando:

  • Una clave es más antigua que la política de tu organización (comúnmente 1–2 años).
  • Un empleado con acceso a claves abandona la empresa.
  • Una máquina o medio que contenía la clave privada es dado de baja o perdido.
  • Sospechas de compromiso.

Procedimiento seguro de rotación:

  1. Genera un nuevo par de claves: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_nueva.
  2. Despliega la nueva clave pública en todos los hosts sin eliminar la antigua.
  3. Verifica que puedes acceder con la nueva clave: ssh -i ~/.ssh/id_ed25519_nueva usuario@host.
  4. Actualiza ~/.ssh/config para usar la nueva clave.
  5. Elimina la clave pública antigua de todos los archivos authorized_keys.
  6. Borra de forma segura la clave privada antigua: shred -u ~/.ssh/id_ed25519_antigua.

Revocación de Claves Comprometidas

SSH no tiene una lista de revocación integrada para claves públicas, por lo que la revocación es manual:

  1. Elimina la clave inmediatamente de todos los archivos authorized_keys en todos los hosts.
  2. Para infraestructuras de certificados SSH, añade la clave a un archivo RevokedKeys en el servidor (RevokedKeys /etc/ssh/revoked_keys en sshd_config).
  3. Audita los registros de acceso (/var/log/auth.log, journalctl -u ssh) para sesiones usando la clave comprometida.
  4. Rota cualquier secreto o credencial que haya podido ser accedido.

Certificados SSH: Gestión de Flotas a Escala

Cuando tienes decenas o cientos de servidores, gestionar authorized_keys en cada máquina es propenso a errores. Los certificados SSH resuelven esto con una Autoridad Certificadora (CA).

Crear un par de claves CA

ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "org-ssh-ca"

Mantén ca_key privada y fuera de línea. Distribuye ca_key.pub a cada servidor.

Configurar servidores para confiar en la CA

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Firmar una clave de usuario

ssh-keygen -s /etc/ssh/ca_key \
  -I "alice@corp" \
  -n alice,admin \
  -V +30d \
  ~/.ssh/id_ed25519.pub

Ventajas sobre authorized_keys

  • Expiración automática — los certificados expiran sin limpieza manual.
  • Control centralizado — revoca eliminando la confianza en la CA o usando RevokedKeys.
  • Aplicación de principios — un certificado solo puede iniciar sesión como nombres de usuario específicos.

Llaves de Hardware: YubiKey y FIDO2

# Generar clave almacenada en YubiKey/FIDO2 (OpenSSH 8.2+)
ssh-keygen -t ed25519-sk -O resident -C "yubikey@corp"

La clave privada nunca sale del dispositivo. Durante la autenticación, el dispositivo requiere un toque físico, haciendo imposible el robo remoto de claves.

Tabla Comparativa: Ed25519 vs RSA vs ECDSA

CaracterísticaEd25519RSA-4096ECDSA P-256
Tamaño de clave256 bits4096 bits256 bits
Velocidad de firmaMuy rápidaLentaRápida
Velocidad de verificaciónRápidaRápidaRápida
Tamaño del archivo de clave~400 bytes~3.3 KB~600 bytes
Compatibilidad heredadaOpenSSH 6.5+ (2014)UniversalOpenSSH 5.7+ (2011)
Resistencia a ataques de canal lateralExcelenteModeradaDeficiente
Llave FIDO2/hardwareSí (ed25519-sk)NoSí (ecdsa-sk)
RecomendaciónPrimera opciónSolo heredadoEvitar

Escenario Real

Tienes una flota de producción de 40 servidores Linux. Tres desarrolladores abandonaron la empresa el mes pasado. Necesitas revocar su acceso SSH inmediatamente sin interrupciones.

Con authorized_keys: Debes acceder (o usar Ansible) en los 40 servidores, buscar la huella de clave pública de cada usuario saliente, eliminar esas líneas y repetir. Un servidor olvidado es una brecha.

Con certificados SSH: La CA simplemente deja de firmar certificados para esos usuarios. Los certificados existentes expiran naturalmente. Para revocación inmediata, añade sus huellas al archivo RevokedKeys desplegado vía Ansible en segundos:

ssh-keygen -lf usuario-saliente-cert.pub >> /tmp/revocados
ansible all -m copy -a "src=/tmp/revocados dest=/etc/ssh/revoked_keys mode=0644"
ansible all -m service -a "name=sshd state=reloaded"

Hecho en menos de dos minutos en toda la flota.

Configuración SSH en GitHub y GitLab

GitHub

# Con GitHub CLI
gh ssh-key add ~/.ssh/id_ed25519.pub --title "estacion-trabajo-2026"

Prueba: ssh -T git@github.com

GitLab

Añade la clave en GitLab → Configuración de Usuario → Claves SSH.

Prueba: ssh -T git@gitlab.com

Errores Comunes y Casos Límite

  • StrictHostKeyChecking=no en scripts — Deshabilitar la verificación de claves de host elimina la protección contra ataques de hombre en el medio. En su lugar, pre-pobla ~/.ssh/known_hosts con ssh-keyscan durante el aprovisionamiento.
  • Claves compartidas — Nunca compartas una clave privada entre múltiples personas o máquinas. Cada persona y máquina debe tener su propio par de claves.
  • Acceso root — Deshabilita PermitRootLogin yes en sshd_config. Usa un usuario regular con sudo.
  • Nombres de clave no predeterminados — Si creas una clave con nombre no estándar, SSH no la usará automáticamente. Especifícala en ~/.ssh/config o pasa -i explícitamente.

Solución de Problemas

ProblemaSolución
”Permission denied (publickey)“Verifica permisos con ls -la ~/.ssh/. Ejecuta ssh -vvv host para ver qué claves se intentan
El agente no funcionaVerifica con ssh-add -l. Si dice “Could not open connection to agent”, ejecuta eval $(ssh-agent -s)
Se usa la clave incorrecta para el hostAgrega IdentityFile explícito e IdentitiesOnly yes en ~/.ssh/config
”Host key verification failed”La clave del servidor cambió. Elimina la entrada antigua: ssh-keygen -R hostname
Certificado rechazadoVerifica expiración con ssh-keygen -L -f cert.pub. Verifica que el principal coincide con el nombre de usuario
YubiKey no detectadaAsegúrate de que pcscd está activo (systemctl start pcscd). Intenta ssh-add -K para cargar claves residentes

Resumen

  • Genera claves Ed25519 para todos los nuevos pares; usa RSA-4096 solo para compatibilidad heredada.
  • Siempre establece una contraseña y usa ssh-agent para cachearla en la sesión.
  • Usa ~/.ssh/config con ProxyJump para gestionar múltiples hosts y bastiones limpiamente.
  • Despliega claves con ssh-copy-id; nunca compartas claves privadas entre personas o máquinas.
  • Para flotas de más de ~10 servidores, adopta certificados SSH para expiración, principios y revocación centralizada.
  • Almacena claves en hardware FIDO2 (YubiKey) para máxima seguridad.
  • Aplica permisos de archivo correctos (700 en ~/.ssh/, 600 en claves y authorized_keys).
  • Audita regularmente la configuración de tu servidor SSH con ssh-audit.

Artículos Relacionados