Cómo crear claves SSH con OpenSSH en macOS o Linux

La autenticación SSH basada en claves es el método estándar de la industria para proteger el acceso remoto a servidores. En lugar de transmitir una contraseña a través de la red, su cliente prueba su identidad resolviendo un desafío criptográfico que solo el titular de la clave privada puede responder — el servidor nunca ve la clave privada en sí.

Un par de claves SSH consiste en dos archivos matemáticamente vinculados: una clave privada (almacenada exclusivamente en su máquina local, nunca compartida) y una clave pública (implementada en cada servidor al que necesita acceder). Cuando inicia una conexión, OpenSSH utiliza un protocolo de desafío-respuesta para verificar que su clave privada corresponde a la clave pública en el servidor, otorgando acceso sin solicitud de contraseña.

Por qué las claves SSH son estrictamente superiores a la autenticación por contraseña

Las contraseñas son vulnerables a ataques de fuerza bruta, relleno de credenciales, phishing e interceptación en redes mal configuradas. Las claves SSH eliminan todos esos vectores de ataque simultáneamente.

• Fortaleza criptográfica: Una clave RSA de 4096 bits o una clave Ed25519 es computacionalmente inviable de descifrar por fuerza bruta con el hardware actual.
• Ningún secreto transmitido por la red: La clave privada nunca abandona su máquina. El protocolo de autenticación prueba la posesión sin divulgación.
• Lista para automatización: Los pipelines CI/CD, los playbooks de Ansible, los trabajos rsync y las copias de seguridad basadas en cron requieren autenticación no interactiva. Las claves SSH hacen esto posible sin incrustar contraseñas en texto plano en los scripts.
• Auditabilidad: Cada par de claves puede identificarse de forma única por su huella digital, lo que facilita revocar una sola clave comprometida sin rotar credenciales en todas partes.
• Compatibilidad con ACLs authorized_keys: Puede restringir una clave pública específica para ejecutar solo un comando, vincularla a una IP de origen, o evitar el reenvío de puertos — controles que la autenticación por contraseña no puede replicar.

Si está administrando un VPS o un servidor dedicado, deshabilitar la autenticación por contraseña por completo y aplicar el inicio de sesión solo con clave es uno de los pasos de refuerzo de seguridad de mayor impacto que puede tomar.

Elegir el algoritmo de clave correcto

La documentación original de OpenSSH y la mayoría de los tutoriales heredados utilizan RSA por defecto. El campo ha avanzado. Aquí hay una comparación precisa de cada algoritmo que ssh-keygen admite hoy:

Ed25519 es el valor predeterminado correcto en 2024. Produce claves más cortas, firma más rápido y su tamaño de clave fijo elimina el riesgo de generar accidentalmente una clave de tamaño insuficiente. RSA a 4096 bits sigue siendo aceptable para entornos que deben interoperar con sistemas más antiguos anteriores al soporte de Ed25519 (OpenSSH < 6.5, lanzado en 2014).

Requisitos previos

• Una estación de trabajo macOS o Linux con OpenSSH instalado. Ambos sistemas operativos incluyen OpenSSH por defecto. Verifique con:

ssh -V

• Acceso de red a un servidor remoto donde tenga una cuenta (root o sin privilegios).
• Familiaridad básica con una terminal.

En distribuciones Linux que incluyen una instalación mínima (Alpine, algunas instalaciones de red de Debian), instale las herramientas del cliente con:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Paso 1: Abrir una terminal

macOS: Presione Cmd + Space, escriba Terminal y presione Enter. Alternativamente, navegue a Aplicaciones > Utilidades > Terminal. Los usuarios avanzados pueden usar iTerm2 o la terminal integrada en VS Code.

Linux: Presione Ctrl + Alt + T en la mayoría de los entornos de escritorio, o inicie el emulador de terminal de su distribución desde el menú de aplicaciones.

Paso 2: Generar el par de claves SSH

Generar una clave Ed25519 (recomendado)

ssh-keygen -t ed25519 -C "your_email@example.com"

El indicador -C agrega un comentario legible por humanos a la clave pública. Use su dirección de correo electrónico, un nombre de host o una etiqueta descriptiva como "deploy-key-prod" — no tiene función criptográfica pero es invaluable al auditar archivos authorized_keys que acumulan docenas de entradas.

Generar una clave RSA (compatibilidad heredada)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Use -b 4096 explícitamente. El valor predeterminado histórico de 2048 bits sigue siendo técnicamente aceptable pero proporciona menos margen frente a futuros avances en algoritmos de factorización. Nunca use -b 1024 o -b 2048 para claves nuevas si 4096 está disponible.

Generar una clave con nombre para un host específico

Al administrar múltiples servidores o roles, use archivos de clave distintos en lugar de reutilizar una sola clave en todas partes. Una clave comprometida entonces solo afecta a los sistemas donde fue implementada:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Paso 3: Elegir una ubicación de almacenamiento

Después de ejecutar ssh-keygen, verá:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Presione Enter para aceptar el valor predeterminado (~/.ssh/id_ed25519 para Ed25519, ~/.ssh/id_rsa para RSA), o escriba una ruta personalizada. La ubicación predeterminada está bien para una sola clave de propósito general. Para claves específicas de rol, siempre especifique un nombre de archivo descriptivo como se muestra en el paso anterior.

Nota crítica sobre permisos de archivos: El directorio ~/.ssh/ debe tener el modo 700 y los archivos de clave privada deben tener el modo 600. OpenSSH se negará a usar claves con permisos demasiado permisivos y mostrará una advertencia. Si alguna vez copia claves entre máquinas, verifique los permisos inmediatamente:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Paso 4: Establecer una frase de contraseña

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Una frase de contraseña cifra el archivo de clave privada en disco usando AES-256-CBC (en OpenSSH moderno). Si un atacante obtiene su archivo de clave privada — a través de una laptop robada, una copia de seguridad comprometida o una instantánea de nube mal configurada — una frase de contraseña fuerte es la última línea de defensa que les impide usarla.

Cuándo omitir la frase de contraseña: Las cuentas de servicio automatizadas (pipelines de implementación, agentes de copia de seguridad) que se ejecutan de forma desatendida legítimamente necesitan claves sin frase de contraseña. En ese caso, restrinja los permisos de la clave en el lado del servidor usando opciones authorized_keys (consulte la sección avanzada a continuación) y almacene la clave privada en un gestor de secretos en lugar de en un sistema de archivos compartido.

Después de confirmar la frase de contraseña, OpenSSH muestra la huella digital de la clave y una imagen de arte aleatorio:

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Registre la huella digital. La usará para verificar la identidad de la clave al auditar servidores.

Paso 5: Copiar la clave pública al servidor remoto

Método 1: ssh-copy-id (el más rápido)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

El indicador -i especifica explícitamente qué clave pública copiar, evitando que ssh-copy-id cargue todas las claves de su agente. Se le pedirá la contraseña del servidor una vez. La herramienta maneja la creación de directorios, la adición de archivos y la configuración de permisos automáticamente.

Método 2: Implementación manual (cuando ssh-copy-id no está disponible)

Este es el enfoque correcto cuando el sistema remoto es Windows, un dispositivo de red o un contenedor sin ssh-copy-id en la ruta.

Primero, muestre su clave pública:

cat ~/.ssh/id_ed25519.pub

Copie toda la salida — es una sola línea que comienza con ssh-ed25519 (o ssh-rsa). Luego inicie sesión en el servidor y agréguelo:

ssh user@your-server.com

Una vez conectado:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Error común: Usar > en lugar de >> sobrescribe todo el archivo authorized_keys, bloqueando todas las demás claves. Siempre use >> para agregar.

Método 3: Canalizar a través de SSH en un solo comando

Si ya tiene acceso por contraseña y desea implementar sin iniciar sesión de forma interactiva:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Paso 6: Probar la conexión

ssh -i ~/.ssh/id_ed25519 user@your-server.com

Una conexión exitosa sin solicitud de contraseña (o solo con una solicitud de frase de contraseña para su clave local) confirma que la configuración es correcta. Si la conexión falla, ejecute con salida detallada para diagnosticar:

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

El indicador -vvv imprime el registro completo de negociación, mostrando exactamente qué clave se ofreció, si el servidor la aceptó y dónde falló el protocolo de enlace.

Paso 7: Configurar ~/.ssh/config para perfiles de host persistentes

Escribir el ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 completo cada vez es propenso a errores y lento. El archivo de configuración del cliente SSH elimina esto:

nano ~/.ssh/config

Agregue un bloque de host:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Ahora conéctese simplemente con:

ssh prod-web

Este patrón escala limpiamente a docenas de servidores y es esencial para cualquier ingeniero que administre infraestructura a escala. La directiva ServerAliveInterval 60 envía un paquete keepalive cada 60 segundos, evitando que los firewalls descarten las conexiones inactivas — una frustración común en los proveedores de nube.

Administrar múltiples claves con el agente SSH

El agente SSH mantiene las claves privadas descifradas en memoria durante la duración de su sesión, de modo que ingresa la frase de contraseña una vez en lugar de en cada conexión.

Inicie el agente y agregue una clave:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

En macOS, puede persistir las claves entre reinicios agregando lo siguiente a ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

La directiva UseKeychain yes se integra con el Llavero de macOS, almacenando la frase de contraseña de forma segura para que sobreviva a los reinicios del sistema.

Liste todas las claves actualmente cargadas en el agente:

ssh-add -l

Elimine una clave específica del agente:

ssh-add -d ~/.ssh/id_ed25519

Avanzado: Restringir claves en authorized_keys

El archivo authorized_keys admite opciones por clave que reducen drásticamente el radio de impacto de una clave comprometida. Estas se colocan antes del tipo de clave en la misma línea:

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

Estas opciones son particularmente valiosas para las claves de implementación en servidores dedicados donde una sola clave CI/CD comprometida no debería otorgar acceso completo al shell.

Reforzar el demonio SSH después de la implementación de claves

Una vez que la autenticación basada en claves esté funcionando, deshabilite la autenticación por contraseña por completo en el servidor. Edite /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Establezca las siguientes directivas:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Recargue el demonio sin desconectar su sesión actual:

sudo systemctl reload sshd

No cierre su sesión SSH existente antes de probar una nueva conexión en una terminal separada. Una mala configuración que lo bloquee es recuperable desde la consola, pero es disruptiva y evitable.

Para servidores que ejecutan entornos cPanel VPS, tenga en cuenta que algunas versiones de cPanel administran su propia configuración SSH. Verifique que los cambios en sshd_config persistan después de las actualizaciones de cPanel comprobando /etc/ssh/sshd_config.d/ en busca de archivos de anulación.

Rotar y revocar claves SSH

La rotación de claves es una práctica de higiene de seguridad que limita la ventana de exposición si una clave es comprometida silenciosamente. Un calendario de rotación práctico es cada 12 meses para claves personales y cada 90 días para claves de cuentas de servicio.

Para revocar una clave: Elimine su línea de ~/.ssh/authorized_keys en cada servidor donde fue implementada. No existe un mecanismo central de revocación en OpenSSH estándar — por eso es importante mantener un inventario de dónde está implementada cada huella digital de clave.

Para rotar una clave:

1. Genere un nuevo par de claves.
2. Implemente la nueva clave pública en todos los servidores de destino.
3. Pruebe la conectividad con la nueva clave.
4. Elimine la clave pública antigua de todos los archivos authorized_keys.
5. Elimine o archive la clave privada antigua localmente.

Para entornos con hosting VPS en múltiples regiones, una herramienta de gestión de configuración como Ansible es la solución práctica para propagar rotaciones de claves a escala.

Transferir claves entre máquinas

Cuando configure una nueva estación de trabajo, necesita migrar sus claves privadas existentes en lugar de generar nuevas (lo que requeriría volver a implementar claves públicas en todas partes).

Copie la clave privada de forma segura usando scp o rsync a través de SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Alternativamente, use una unidad USB cifrada o un gestor de contraseñas que admita almacenamiento de claves SSH (1Password, Bitwarden y HashiCorp Vault admiten esto). Nunca envíe claves privadas por correo electrónico ni las almacene en almacenamiento en la nube sin cifrar.

Después de la transferencia, verifique inmediatamente los permisos en la nueva máquina:

chmod 600 ~/.ssh/id_ed25519

Verificar la huella digital de la clave de host de un servidor

La primera vez que se conecta a un servidor, OpenSSH presenta la huella digital de la clave de host del servidor y le pide que la confirme:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Nunca escriba yes a ciegas. Obtenga la huella digital esperada a través de un canal fuera de banda — el panel de control de su proveedor de hosting, un colega que aprovisionó el servidor, o la salida de la consola del servidor. Este paso previene los ataques de intermediario. Para entornos de hosting compartido, la huella digital esperada generalmente se encuentra en el panel de control en la configuración de acceso SSH.

Una vez aceptada, la huella digital se almacena en ~/.ssh/known_hosts. Si la huella digital cambia inesperadamente en una conexión posterior, OpenSSH se negará a conectarse y mostrará una advertencia — trátelo como un evento de seguridad grave que requiere investigación antes de continuar.

Matriz de decisión y lista de verificación técnica

Use esta lista de verificación antes de considerar que su configuración de claves SSH está lista para producción:

• [ ] El algoritmo de clave es Ed25519 (o RSA 4096 para compatibilidad heredada) — DSA y ECDSA 256 no son aceptables para nuevas implementaciones
• [ ] Los permisos del archivo de clave privada son 600; los permisos del directorio ~/.ssh/ son 700
• [ ] Se ha establecido una frase de contraseña fuerte en todas las claves de usuario interactivas
• [ ] Las claves de cuentas de servicio sin frases de contraseña están restringidas mediante opciones authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no está configurado en /etc/ssh/sshd_config en todos los servidores
• [ ] PermitRootLogin prohibit-password o PermitRootLogin no está aplicado
• [ ] Las huellas digitales de las claves de host del servidor han sido verificadas fuera de banda
• [ ] Existe un inventario de claves que mapea cada huella digital a los servidores donde está implementada
• [ ] El calendario de rotación de claves está definido y programado
• [ ] Los bloques de host ~/.ssh/config están configurados para evitar el uso manual del indicador -i
• [ ] Se usa el agente SSH para evitar la entrada repetida de frases de contraseña durante las sesiones de trabajo
• [ ] Las entradas known_hosts se revisan periódicamente en busca de entradas obsoletas o inesperadas

Preguntas frecuentes

¿Cuál es la diferencia entre las claves SSH Ed25519 y RSA?

Ed25519 utiliza criptografía de curva elíptica con una clave fija de 256 bits que proporciona aproximadamente 128 bits de seguridad, firma operaciones más rápido que RSA y produce cadenas de clave más cortas. RSA a 4096 bits proporciona seguridad comparable pero es más lento y genera más material de clave. Use Ed25519 para todas las claves nuevas a menos que deba conectarse a un sistema que ejecute OpenSSH anterior a la versión 6.5.

¿Puedo usar el mismo par de claves SSH para múltiples servidores?

Sí, técnicamente. Sin embargo, la mejor práctica es usar pares de claves distintos por rol o entorno (acceso personal desde la estación de trabajo, implementación CI/CD, mantenimiento de base de datos). Esto limita el impacto de una sola clave comprometida y hace que la revocación sea sencilla sin interrumpir sistemas no relacionados.

¿Qué sucede si pierdo mi clave privada?

Pierde la capacidad de autenticarse usando ese par de claves. La clave pública en el servidor se vuelve inútil. Debe acceder al servidor a través de un método alternativo — acceso por consola, una clave secundaria, o el acceso de emergencia de su proveedor de hosting — luego eliminar la clave pública huérfana de authorized_keys e implementar un nuevo par de claves.

¿Por qué SSH sigue pidiendo una contraseña después de copiar mi clave pública?

Las causas más comunes son: permisos incorrectos en ~/.ssh/ (debe ser 700) o ~/.ssh/authorized_keys (debe ser 600) en el servidor; el directorio home siendo escribible por todos; SELinux o AppArmor bloqueando el acceso al directorio .ssh; o PubkeyAuthentication no configurado en /etc/ssh/sshd_config. Ejecute ssh -vvv para identificar exactamente qué método de autenticación se está intentando y rechazando.

¿Cómo elimino una clave SSH de un servidor al que ya no tengo acceso?

Si no tiene ningún otro método de autenticación, contacte al equipo de soporte de su proveedor de hosting o use el acceso por consola fuera de banda (disponible para clientes de VPS y servidor dedicado) para iniciar sesión y editar ~/.ssh/authorized_keys directamente. Por eso mantener las credenciales de acceso por consola separadas de las claves SSH es un requisito operativo innegociable.