Cómo agregar claves SSH a un VPS nuevo o existente

Las claves SSH son pares de claves criptográficas — una clave pública almacenada en el servidor y una clave privada guardada en su máquina local — que autentican su identidad sin transmitir una contraseña a través de la red. Cuando se conecta, el servidor emite un desafío criptográfico que solo su clave privada puede resolver, otorgando acceso si la respuesta es válida. Este mecanismo hace que la autenticación mediante claves SSH sea fundamentalmente más resistente a ataques de fuerza bruta, relleno de credenciales e interceptación de tipo man-in-the-middle que cualquier esquema basado en contraseñas.

Esta guía cubre el proceso completo de generación, implementación y refuerzo de la autenticación mediante claves SSH tanto en instancias VPS nuevas como existentes — incluyendo casos límite, problemas de permisos y gestión de múltiples claves que la mayoría de los tutoriales omiten por completo.

Por Qué las Claves SSH Son Arquitectónicamente Superiores a las Contraseñas

La autenticación por contraseña envía un secreto (o su hash) a través de la red y depende de que el servidor almacene una credencial verificable. La autenticación de clave pública SSH nunca expone la clave privada — ni durante la generación, ni durante el inicio de sesión, ni en ningún momento. La clave privada nunca abandona su máquina local.

Más allá de la seguridad básica, las claves SSH desbloquean capacidades operativas que las contraseñas no pueden ofrecer:

• Automatización desatendida — Los pipelines CI/CD, los playbooks de Ansible y los trabajos rsync programados con cron requieren autenticación no interactiva. Las contraseñas rompen esto por completo.
• Control de acceso granular — Cada entrada authorized_keys puede llevar restricciones command=, from= y no-pty, limitando exactamente lo que una clave determinada tiene permitido hacer.
• Auditabilidad — Las claves individuales pueden revocarse sin cambiar una contraseña compartida y sin interrumpir a todos los demás usuarios o scripts.
• Resistencia al phishing — No hay contraseña que robar a través de una página de inicio de sesión falsa.

Requisitos Previos

Antes de continuar, confirme lo siguiente:

• Tiene un VPS en funcionamiento o está en proceso de aprovisionar uno.
• Su máquina local ejecuta Linux, macOS o Windows con OpenSSH instalado (Windows 10/11 incluye OpenSSH por defecto; verifíquelo con ssh -V).
• Tiene acceso root o sudo al servidor de destino.
• Comprende que perder su clave privada sin un método de inicio de sesión alternativo (acceso por consola, clave de recuperación) puede bloquearlo permanentemente.

Elegir el Algoritmo de Clave Correcto

El comando original ssh-keygen -t rsa -b 4096 es sólido pero no es la única opción. Comprender las ventajas y desventajas le ayuda a tomar la decisión correcta para su entorno.

Ed25519 es el algoritmo recomendado para cualquier servidor que ejecute OpenSSH 6.5 o posterior (lanzado en 2014). Use RSA 4096 solo cuando se conecte a sistemas heredados que no admitan claves de curva elíptica.

Parte 1: Agregar Claves SSH a un Nuevo VPS

Muchos paneles de control de alojamiento permiten inyectar una clave pública en el momento del aprovisionamiento, antes de que la instancia arranque por primera vez. Este es el enfoque más limpio — la clave se integra en la imagen y es posible que la autenticación por contraseña nunca necesite habilitarse.

Paso 1: Generar su Par de Claves SSH

Abra una terminal en su máquina local. Genere un par de claves Ed25519:

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

Si necesita RSA por razones de compatibilidad:

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

Cuando se le solicite una ubicación de archivo, presione Enter para aceptar el valor predeterminado (~/.ssh/id_ed25519 o ~/.ssh/id_rsa). Cuando se le solicite una frase de contraseña, establezca una — cifra la clave privada en el disco, de modo que incluso si le roban el portátil, la clave es inútil sin la frase de contraseña. Su agente SSH (ssh-agent) almacenará en caché la clave descifrada en memoria para que solo escriba la frase de contraseña una vez por sesión.

Verifique los archivos generados:

ls -la ~/.ssh/

Verá:

• id_ed25519 — su clave privada (los permisos deben ser 600; nunca comparta este archivo)
• id_ed25519.pub — su clave pública (segura para copiar en cualquier lugar)

Muestre la clave pública para copiarla:

cat ~/.ssh/id_ed25519.pub

La salida tiene este aspecto:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com

Copie esta cadena completa — la pegará en su panel de alojamiento.

Paso 2: Agregar la Clave Pública Durante el Aprovisionamiento del VPS

Inicie sesión en su panel de control de alojamiento. Durante el flujo de trabajo de creación del VPS:

1. Seleccione su sistema operativo (Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9, etc.).
2. Localice la sección Clave SSH o Autenticación.
3. Pegue el contenido completo de id_ed25519.pub en el campo proporcionado.
4. Complete la configuración restante (plan, región, nombre de host).

Una vez que el VPS arranque, el sistema de aprovisionamiento escribe su clave pública en /root/.ssh/authorized_keys automáticamente. No se requiere inicio de sesión con contraseña.

Paso 3: Conectarse al VPS Recién Aprovisionado

ssh root@your_vps_ip

Si utilizó un nombre de archivo de clave no predeterminado, especifíquelo explícitamente:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Una conexión exitosa sin solicitud de contraseña confirma que la clave fue inyectada correctamente. Si estableció una frase de contraseña, su agente SSH o una solicitud de frase de contraseña la gestionará localmente.

Parte 2: Agregar Claves SSH a un VPS Existente

Si su VPS ya está en funcionamiento con autenticación por contraseña, necesita implementar la clave pública manualmente. Este es un proceso de dos fases: copiar la clave y luego, opcionalmente, reforzar el demonio SSH.

Paso 1: Generar un Par de Claves (Si No Tiene Uno)

Siga el mismo proceso que el Paso 1 de la Parte 1 anterior. Si ya tiene un par de claves, recupere su clave pública:

cat ~/.ssh/id_ed25519.pub

Paso 2: Copiar la Clave Pública al Servidor

Método A — ssh-copy-id (Recomendado)

La utilidad ssh-copy-id gestiona automáticamente la creación de directorios, la adición de archivos y la configuración de permisos:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip

Introduzca su contraseña cuando se le solicite. La herramienta agrega la clave a ~/.ssh/authorized_keys en el servidor remoto y establece los permisos correctos. Este es el método más seguro porque evita sobrescrituras accidentales de claves existentes.

Método B — Implementación Manual

Utilice esto cuando ssh-copy-id no esté disponible (por ejemplo, en algunos entornos Windows o redes restringidas):

cat ~/.ssh/id_ed25519.pub | ssh root@your_vps_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Este pipeline único es más seguro que abrir un editor de texto en el servidor remoto porque agrega en lugar de sobrescribir.

Método C — Manual mediante Editor de Texto (Alternativa)

Inicie sesión en el servidor con su contraseña:

ssh root@your_vps_ip

Cree el directorio .ssh si no existe:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Abra authorized_keys en un editor de texto:

nano ~/.ssh/authorized_keys

Pegue su clave pública en una nueva línea. Guarde con Ctrl+X, luego Y, luego Enter. Establezca los permisos:

chmod 600 ~/.ssh/authorized_keys

Cierre la sesión:

exit

Paso 3: Verificar el Inicio de Sesión Basado en Clave

Pruebe la conexión antes de realizar cualquier cambio adicional en el demonio SSH. Abra una nueva ventana de terminal (no cierre su sesión existente todavía):

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

Si se conecta sin solicitud de contraseña, la clave está funcionando. Solo proceda a los pasos de refuerzo a continuación después de confirmar esto.

Problema crítico: Si deshabilita la autenticación por contraseña antes de verificar el acceso por clave, y la implementación de la clave falló por alguna razón, se bloqueará el acceso. Pruebe siempre primero.

Paso 4: Reforzar la Configuración del Demonio SSH

Una vez confirmado el acceso basado en clave, abra el archivo de configuración del demonio SSH:

nano /etc/ssh/sshd_config

Aplique la siguiente configuración:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
UsePAM yes

Notas clave sobre estas directivas:

• PermitRootLogin prohibit-password permite el inicio de sesión root mediante clave pero bloquea el inicio de sesión root con contraseña — un punto intermedio mejor que PermitRootLogin no cuando todavía está configurando un usuario sudo no root.
• ChallengeResponseAuthentication no deshabilita la autenticación interactiva de teclado, que puede eludir PasswordAuthentication no en algunas configuraciones PAM.
• En Ubuntu 22.04+, el archivo /etc/ssh/sshd_config.d/50-cloud-init.conf puede anular su configuración. Verifíquelo y edítelo si es necesario.

Valide la sintaxis de configuración antes de reiniciar:

sshd -t

Si no se reportan errores, reinicie el servicio SSH:

systemctl restart sshd

En sistemas que usan ssh.service en lugar de sshd.service:

systemctl restart ssh

Gestión de Múltiples Claves SSH y Usuarios

Los entornos del mundo real raramente implican una sola clave y un solo usuario. A continuación se explica cómo manejar escenarios más complejos.

Agregar Claves para Múltiples Usuarios

Cada cuenta de usuario tiene su propio archivo ~/.ssh/authorized_keys. Para agregar una clave para un usuario no root llamado deploy:

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
echo "ssh-ed25519 AAAAC3... deploy@ci-server" >> /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

El paso chown se omite con frecuencia y causa fallos de autenticación — tanto SELinux como OpenSSH verifican que el archivo authorized_keys sea propiedad del usuario que se autentica.

Restringir lo que una Clave Puede Hacer

Puede anteponer opciones a cualquier línea en authorized_keys para limitar sus capacidades. Esto es especialmente útil para claves de implementación o automatización de copias de seguridad:

command="/usr/bin/rsync --server --daemon .",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3... backup@monitoring

Esta clave solo puede ejecutar rsync en modo demonio — nada más.

Usar ~/.ssh/config para Conexiones más Limpias

En lugar de escribir comandos ssh largos, defina alias de host en su máquina local:

Host myserver
    HostName 203.0.113.45
    User root
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Después de guardar esto en ~/.ssh/config, conéctese simplemente con:

ssh myserver

Usar ssh-agent para Almacenar en Caché las Frases de Contraseña

Si su clave privada tiene una frase de contraseña (debería tenerla), agréguela al agente para no tener que introducirla repetidamente:

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

En macOS, agregue --apple-use-keychain para persistir entre reinicios:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Problemas Comunes y Solución de Problemas

Problema: Sigue solicitando contraseña después de agregar la clave

Ejecute la conexión con salida detallada para diagnosticar:

ssh -vvv root@your_vps_ip

Busque líneas como Offering public key y Server accepts key. Si la clave se ofrece pero es rechazada, el problema casi siempre son los permisos de archivo en el servidor.

Verifique los permisos en el servidor:

ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

Permisos requeridos:

• ~/.ssh/ — 700 (drwx——)
• ~/.ssh/authorized_keys — 600 (-rw——-)
• Directorio home ~/ — no debe tener permisos de escritura para todos (755 o 750)

Problema: SELinux bloqueando la autenticación en RHEL/Rocky/AlmaLinux

restorecon -Rv ~/.ssh

Problema: El archivo authorized_keys tiene finales de línea de Windows (CRLF)

Si editó el archivo en Windows y lo transfirió, los finales de línea pueden estar dañados. Corrija con:

sed -i 's/r//' ~/.ssh/authorized_keys

Problema: Se está ofreciendo la clave incorrecta

Si tiene múltiples claves, especifique la correcta explícitamente:

ssh -i ~/.ssh/id_ed25519 root@your_vps_ip

O configúrelo en ~/.ssh/config como se muestra anteriormente.

Claves SSH en el Contexto de su Infraestructura de Alojamiento

La autenticación mediante claves SSH no es solo una preocupación de un único servidor — escala a toda su infraestructura. Si gestiona una flota de servidores dedicados, es esencial un enfoque centralizado que utilice herramientas como Ansible, Puppet o un gestor de secretos (HashiCorp Vault, AWS Secrets Manager) para distribuir y rotar las claves autorizadas.

Para equipos que ejecutan aplicaciones web en VPS con cPanel, la interfaz de Acceso SSH de cPanel en la sección de Seguridad proporciona una GUI para generar y gestionar pares de claves — útil para desarrolladores que no se sienten cómodos con la línea de comandos pero aún necesitan acceso seguro.

Si ejecuta cargas de trabajo intensivas en GPU en infraestructura de alojamiento GPU, la autenticación mediante claves SSH es especialmente crítica porque estas instancias a menudo ejecutan trabajos de larga duración y desatendidos. Una credencial comprometida en un servidor GPU puede resultar en costos de cómputo no autorizados significativos además de la exposición de datos.

Combinar el refuerzo SSH con un certificado SSL válido en cualquier servicio orientado a la web que se ejecute en el mismo servidor cierra simultáneamente los dos vectores de ataque más comunes — acceso shell no autenticado y tráfico HTTP sin cifrar.

Para proyectos que utilizan alojamiento web compartido que también necesitan acceso SSH, verifique si su proveedor admite la inyección de claves SSH a través del panel de alojamiento, ya que los entornos compartidos a menudo restringen SSH a usuarios específicos con acceso shell limitado.

Rotación de Claves y Gestión de Claves a Largo Plazo

Las claves SSH no caducan automáticamente. Sin una política de rotación, una clave comprometida hace años puede seguir otorgando acceso. Establezca estas prácticas:

• Rote las claves anualmente o inmediatamente ante sospecha de compromiso.
• Audite los archivos authorized_keys en todos los servidores regularmente. Elimine las claves pertenecientes a exempleados o servicios dados de baja.
• Use claves separadas por dispositivo — no copie la misma clave privada en múltiples portátiles o servidores. Si se pierde un dispositivo, solo revoca esa clave.
• Use claves separadas por rol — su clave de acceso personal, su clave de implementación CI/CD y su clave de automatización de copias de seguridad deben ser todas distintas.
• Documente la propiedad de las claves — mantenga un registro que mapee cada huella digital de clave pública a su propietario, propósito y fecha de vencimiento.

Para mostrar la huella digital de una clave para auditoría:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Lista de Verificación de Decisiones Técnicas

Use esta matriz antes de finalizar su configuración de claves SSH:

• Algoritmo: Use Ed25519 a menos que se conecte a sistemas anteriores a OpenSSH 6.5; use RSA 4096 como alternativa.
• Frase de contraseña: Establezca siempre una en las claves privadas utilizadas por personas; las claves de servicio utilizadas por la automatización pueden omitirla si se almacenan en un gestor de secretos.
• Método de implementación: Use ssh-copy-id para configuraciones interactivas; use gestión de configuración (Ansible, Puppet) para implementaciones en flota.
• Verificación de permisos: Confirme 700 en ~/.ssh/, 600 en authorized_keys, y la propiedad correcta antes de deshabilitar la autenticación por contraseña.
• Pruebe antes de bloquear: Verifique siempre el inicio de sesión por clave en una sesión de terminal separada antes de establecer PasswordAuthentication no.
• Validación de configuración del demonio: Ejecute sshd -t antes de reiniciar el servicio SSH para detectar errores de sintaxis.
• Deshabilitar autenticación por contraseña: Establezca PasswordAuthentication no y ChallengeResponseAuthentication no juntos — uno solo es insuficiente en sistemas con PAM habilitado.
• Política de inicio de sesión root: Prefiera PermitRootLogin prohibit-password sobre PermitRootLogin yes; migre a un usuario sudo no root y establezca PermitRootLogin no como estado final reforzado.
• Rotación de claves: Programe rotación anual; revoque inmediatamente ante pérdida de dispositivo o cambio de personal.
• Auditoría: Ejecute periódicamente grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys para revisar todas las claves autorizadas en el sistema.

Preguntas Frecuentes

¿Puedo agregar múltiples claves SSH al mismo servidor?

Sí. Cada línea en ~/.ssh/authorized_keys representa una clave pública autorizada. Puede agregar tantas claves como necesite — una por línea. Esto permite que múltiples administradores o múltiples dispositivos se autentiquen de forma independiente, y puede revocar cualquier clave individual eliminando su línea sin afectar a las demás.

¿Qué sucede si pierdo mi clave privada después de deshabilitar la autenticación por contraseña?

Quedará bloqueado fuera de SSH. La recuperación requiere acceder al servidor a través de un método fuera de banda: la consola web de su proveedor de alojamiento, VNC o un entorno de arranque de rescate/recuperación. Desde allí puede volver a habilitar la autenticación por contraseña o agregar una nueva clave pública. Por eso es esencial mantener las credenciales de acceso a la consola seguras y separadas.

¿Es Ed25519 compatible con todos los servidores?

Ed25519 requiere OpenSSH 6.5 o posterior, lanzado en enero de 2014. Cualquier servidor que ejecute una distribución Linux moderna (Ubuntu 18.04+, Debian 9+, CentOS 7+, Rocky Linux 8+) lo admite. El único escenario que requiere RSA es conectarse a sistemas genuinamente heredados o dispositivos embebidos con versiones de OpenSSH desactualizadas.

¿Agregar una clave SSH deshabilita automáticamente el inicio de sesión por contraseña?

No. Agregar una clave a authorized_keys habilita el inicio de sesión basado en clave pero no deshabilita la autenticación por contraseña. Debe establecer explícitamente PasswordAuthentication no en /etc/ssh/sshd_config y reiniciar el demonio SSH para imponer el acceso solo con clave.

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

Técnicamente sí, pero no se recomienda para entornos de producción. Usar una sola clave en muchos servidores significa que comprometer una clave privada otorga acceso a todos ellos. La mejor práctica es usar claves por dispositivo (una clave por estación de trabajo o portátil) de modo que perder un dispositivo requiera revocar solo esa clave en toda su flota de servidores, en lugar de reemplazar claves en todas partes simultáneamente.