Gestión de claves SSH para acceso seguro y sin contraseñas al servidor

El acceso por clave SSH es la base de la administración segura de servidores: elimina contraseñas, reduce el riesgo de ataques por fuerza bruta y facilita la automatización. Esta guía, orientada a administradores y responsables de infraestructuras, explica cómo generar, desplegar, proteger y rotar claves SSH en entornos productivos, con comandos prácticos y recomendaciones basadas en estándares.

Por qué usar claves SSH en lugar de contraseñas

Las claves SSH ofrecen autenticación asimétrica: una clave pública en el servidor y una privada en el cliente. Ventajas clave:

• Mayor seguridad frente a ataques de fuerza bruta y phishing.
• Posibilidad de acceso sin introducir contraseña, ideal para scripts y automatizaciones.
• Control granular mediante autorizaciones de clave y configuraciones de servidor.

Para marcos de seguridad y normativas relacionadas con gestión de credenciales, consulte las recomendaciones del NIST.

Tipos de claves y recomendaciones actuales

No todas las claves SSH son iguales. Elige algoritmos y tamaños seguros:

• ed25519: recomendado por su seguridad, rendimiento y tamaño reducido. Ideal para la mayoría de casos.
• rsa (4096 bits): aún válido cuando ed25519 no está disponible; evite RSA < 2048 bits.
• ecdsa: soportado, pero ed25519 suele ser preferible por simplicidad y seguridad.

Evite algoritmos obsoletos (DSA) y privilegie claves con passphrase fuerte cuando sea posible. Para políticas de uso y almacenamiento seguro de claves, las prácticas en la industria y guías como las de OWASP son útiles.

Generar y configurar claves: pasos prácticos

1. Crear un par de claves en el cliente

En la máquina local, genere una clave ed25519 (recomendada):

ssh-keygen -t ed25519 -C "usuario@equipo" -f ~/.ssh/id_ed25519

O, si necesita RSA por compatibilidad:

ssh-keygen -t rsa -b 4096 -C "usuario@equipo" -f ~/.ssh/id_rsa

Se le pedirá un passphrase. Recomendación: usar un passphrase fuerte y gestionar la clave con un agente (ver más abajo). Si la clave se usa en automatización sin intervención humana, considere el riesgo de dejarla sin passphrase y proteja el archivo con permisos restrictivos.

2. Instalar la clave pública en el servidor

La forma más sencilla es con ssh-copy-id:

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

Si no tiene ssh-copy-id, puede copiar manualmente:

ssh usuario@servidor 'mkdir -p ~/.ssh && chmod 700 ~/.ssh'
cat ~/.ssh/id_ed25519.pub | ssh usuario@servidor 'cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Asegúrese de que el archivo authorized_keys y el directorio .ssh tengan permisos correctos; de lo contrario, OpenSSH rechazará la autenticación.

3. Probar el acceso sin contraseña

Desde el cliente:

ssh usuario@servidor

Si configuró un passphrase, el agente ssh lo manejará si está cargada la clave (ver sección siguiente).

Usar ssh-agent y ssh-add para gestionar claves en sesión

ssh-agent mantiene claves privadas en memoria para evitar introducir el passphrase a cada conexión.

• Iniciar el agente (en bash/zsh): eval "$(ssh-agent -s)"
• Añadir la clave: ssh-add ~/.ssh/id_ed25519

En entornos de escritorio, los gestores de claves integrados (GNOME Keyring, macOS Keychain) pueden integrar ssh-agent automáticamente. Para sesiones CI/CD o contenedores, use agentes dedicados o soluciones de secretos con rotación.

Habilitar seguridad en el servidor: configuración de sshd

Edite /etc/ssh/sshd_config y aplique estas recomendaciones mínimas:

• PubkeyAuthentication yes
• PasswordAuthentication no (desactivar solo después de validar las claves)
• PermitRootLogin no o without-password según su política
• Limite usuarios con AllowUsers o grupos con AllowGroups

Después de cambios: sudo systemctl restart sshd. Pruebe en una sesión separada para evitar quedar bloqueado.

Buenas prácticas operativas y de seguridad

• Asignación y control: mantenga un inventario de claves autorizadas por servidor y usuario.
• Permisos mínimos: ~/.ssh = 700, authorized_keys = 600, archivos privados = 600.
• Rotación regular: planifique rotaciones periódicas (p. ej. cada 6–12 meses) y revoque claves inmediatamente si hay indicios de compromiso.
• Uso de hardware: considere llaves en tokens FIDO/U2F para mayor seguridad física de la clave privada.
• Segmentación y bastión: gestione accesos a través de jump hosts o bastion hosts para auditar y controlar conexiones.
• Registro y auditoría: habilite y monitoree logs SSH para detectar accesos inusuales.

Para diseños avanzados de gestión de llaves y servicios que centralizan credenciales, revise guías y estándares de seguridad como los publicados por NIST y las recomendaciones de la comunidad en OWASP.

Automatización segura y CI/CD

En pipelines es común usar claves SSH para desplegar. Evite almacenar claves privadas en repositorios o texto plano. Opciones seguras:

• Almacenes de secretos (HashiCorp Vault, servicios cloud) con acceso limitado y rotación.
• Agentes temporales para inyección de claves en tiempo de ejecución.
• Claves de despliegue de alcance limitado (usuarios con permisos reducidos).

Para escenarios de despliegue continuo, prefiera mecanismos que emitan credenciales temporales o utilicen certificados SSH con expiración en lugar de claves eternas.

Solución de problemas comunes

• Permisos incorrectos: Permission denied (publickey) suele indicar permisos erróneos o clave pública faltante.
• Clave no cargada: verifique con ssh-add -l.
• SSH verbose: ssh -vvv usuario@servidor muestra negociación y por qué falla la autenticación.
• Formato inválido en authorized_keys: elimine saltos extra o caracteres no UTF-8.

Políticas de rotación y respuesta ante incidentes

Una política mínima incluye:

• Rotación periódica documentada (ej. 6–12 meses) y procesos automatizados cuando sea posible.
• Revocación inmediata y auditoría cuando una clave se sospecha comprometida.
• Uso de certificados SSH (CA interna) para emitir claves temporales y simplificar revocación.

El uso de certificados reduce la necesidad de alterar authorized_keys en cada servidor y facilita la gestión centralizada.

Recursos y referencias

Para profundizar en configuraciones y prácticas avanzadas, consulte documentación técnica y estándares:

• Guías sobre seguridad y autenticación en OWASP.
• Recomendaciones de gestión de identidades y credenciales en NIST.
• Artículos técnicos y tutoriales sobre claves y agents en la documentación de proveedores y proyectos, como la sección de claves en la documentación de Cloudflare Docs.

Conclusión

La gestión de claves SSH es una práctica esencial para asegurar el acceso a servidores: ofrece seguridad superior a las contraseñas, facilita automatización y, con políticas adecuadas de rotación y auditoría, reduce el riesgo operativo. Implemente ed25519 cuando sea posible, proteja claves privadas con passphrase y agentes, desactive la autenticación por contraseña tras verificar accesos, y aplique controles de inventario y rotación. Con estas medidas se logra un acceso seguro, auditable y escalable para infraestructuras modernas.