Cómo cargar una clave pública SSH en un VPS existente

Una clave pública SSH es una credencial criptográfica almacenada en ~/.ssh/authorized_keys en un servidor remoto que otorga acceso a cualquier cliente que posea la clave privada correspondiente, sin transmitir una contraseña a través de la red. Subir tu clave pública a un VPS existente reemplaza o complementa la autenticación basada en contraseñas con criptografía asimétrica, eliminando la superficie de ataque explotada por campañas de fuerza bruta y relleno de credenciales.

Esta guía cubre cada etapa del proceso: generación de claves, métodos de carga manual y automatizada, refuerzo de permisos, ajuste de sshd_config, gestión de múltiples claves y modos de fallo comunes que incluso los administradores experimentados suelen encontrar.

Por qué la autenticación con claves SSH supera a las contraseñas

Antes de ejecutar un solo comando, vale la pena entender la mecánica criptográfica. Cuando te autenticas con un par de claves, el servidor emite un desafío cifrado con tu clave pública. Solo el titular de la clave privada correspondiente puede descifrar y firmar la respuesta. Nunca se transmite ningún secreto — contrasta esto con la autenticación por contraseña, donde la credencial en sí viaja a través de la red (incluso si está envuelta en TLS).

La conclusión práctica: en cualquier entorno de VPS Hosting expuesto a internet público, las claves SSH no son un refuerzo opcional — son la línea base.

Requisitos previos

• Un VPS existente accesible mediante SSH (actualmente funciona el inicio de sesión por contraseña o clave existente)
• Una máquina local con Linux, macOS o Windows con OpenSSH o PuTTY
• Privilegios suficientes en el VPS para escribir en el directorio home del usuario objetivo
• Comodidad básica con una terminal y un editor de texto como nano o vim

Paso 1: Generar un par de claves SSH

Si ya tienes un par de claves en ~/.ssh/id_ed25519 o ~/.ssh/id_rsa, salta al siguiente paso. De lo contrario, genera uno ahora.

Elegir el algoritmo correcto

Ed25519 es el estándar moderno. Usa RSA 4096 solo cuando te conectes a servidores heredados que no admitan Ed25519.

Generar un par de claves Ed25519:

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

Generar un par de claves RSA 4096 (sistemas heredados):

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

Durante la generación de claves se te pedirá una ruta de guardado y una frase de contraseña opcional. Aceptar la ruta predeterminada (~/.ssh/id_ed25519) está bien para la mayoría de los usuarios. Establece siempre una frase de contraseña — cifra la clave privada en disco usando AES-256, de modo que un portátil robado no signifique automáticamente un servidor comprometido.

El proceso produce dos archivos:

~/.ssh/id_ed25519 — tu clave privada. Nunca la compartas, nunca la copies a un servidor, nunca la incluyas en control de versiones.
~/.ssh/id_ed25519.pub — tu clave pública. Es seguro distribuirla libremente.

Muestra la clave pública para poder copiarla:
cat ~/.ssh/id_ed25519.pub
La salida será similar a:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
Copia la cadena completa de una sola línea, incluyendo el prefijo del algoritmo y el comentario al final.
Paso 2: Iniciar sesión en tu VPS
Conéctate al VPS usando tu método de autenticación actual:
ssh root@your_vps_ip
Reemplaza your_vps_ip con la dirección IPv4 o IPv6 real de tu servidor. Si estás gestionando una cuenta de usuario no root, sustituye root con el nombre de usuario apropiado. En Servidores Dedicados donde puedas tener múltiples cuentas de usuario, siempre prefiere implementar claves en un usuario no root y usar sudo para la escalada de privilegios.
Paso 3: Preparar el directorio .ssh
Una vez conectado, verifica o crea el directorio .ssh para el usuario objetivo:
mkdir -p ~/.ssh
chmod 700 ~/.ssh
El permiso 700 (rwx------) es obligatorio. OpenSSH rechazará silenciosamente el uso de authorized_keys si el directorio .ssh tiene permisos de escritura para el grupo o para todos. Esta es una de las razones más comunes por las que la autenticación con clave falla después de una configuración aparentemente correcta.
Paso 4: Añadir la clave pública a authorized_keys
Método A: Pegado manual (universal)
Abre o crea el archivo authorized_keys:
nano ~/.ssh/authorized_keys
Pega tu clave pública en una nueva línea. Cada línea de este archivo representa una clave autorizada. Guarda con Ctrl+X, luego Y, luego Enter.
Establece los permisos correctos:
chmod 600 ~/.ssh/authorized_keys
El permiso 600 (rw-------) garantiza que solo el propietario del archivo pueda leerlo o escribirlo. OpenSSH aplica esto estrictamente.
Método B: ssh-copy-id (recomendado por velocidad)
Si tu máquina local tiene ssh-copy-id disponible (estándar en Linux y macOS), este único comando gestiona automáticamente la creación del directorio, la adición de la clave y la configuración de permisos:
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@your_vps_ip
Se te pedirá la contraseña SSH actual una vez. Después de eso, el inicio de sesión basado en clave estará activo. El indicador -i especifica explícitamente qué clave pública subir, evitando cargas accidentales de la clave incorrecta.
Método C: Comando único mediante cat y tubería (automatizable)
Útil en flujos de automatización o cuando ssh-copy-id no está disponible:
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 enfoque es seguro en cuanto a idempotencia, ya que añade en lugar de sobrescribir, preservando cualquier clave autorizada existente.
Paso 5: Verificar la propiedad correcta del archivo
Un problema frecuentemente ignorado: si creaste el directorio .ssh o el archivo authorized_keys como root mientras configurabas la cuenta de otro usuario, la propiedad será incorrecta y SSH rechazará la clave silenciosamente.
Comprueba la propiedad:
ls -la ~/.ssh/
La salida debe mostrar el nombre de usuario objetivo como propietario y grupo tanto para el directorio como para el archivo:
drwx------ 2 alice alice 4096 Jan 15 10:00 .ssh
-rw------- 1 alice alice  571 Jan 15 10:00 .ssh/authorized_keys
Si la propiedad es incorrecta, corrígela (ejecutar como root):
chown -R alice:alice /home/alice/.ssh
Paso 6: Probar el inicio de sesión con clave SSH
Sal de la sesión actual:
exit
Vuelve a conectarte especificando explícitamente la clave para confirmar la configuración:
ssh -i ~/.ssh/id_ed25519 root@your_vps_ip
Si el inicio de sesión se realiza correctamente sin solicitar contraseña (o solo solicita la frase de contraseña de tu clave local), la configuración es correcta. Si sigue pidiendo la contraseña del servidor, consulta la sección de solución de problemas a continuación.
Paso 7: Reforzar la configuración del demonio SSH
Una vez confirmado el inicio de sesión basado en clave, deshabilita la autenticación por contraseña para eliminar por completo el vector de ataque de fuerza bruta.
Abre el archivo de configuración del demonio SSH:
nano /etc/ssh/sshd_config
Localiza y establece las siguientes directivas. Si una línea está comentada con #, elimina el # y establece el valor:
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
Una nota sobre PermitRootLogin prohibit-password: esta configuración permite el inicio de sesión root exclusivamente mediante clave, bloqueando el acceso root basado en contraseña mientras aún permite sesiones root autenticadas con clave. Para el máximo refuerzo, establécelo en no y usa un usuario no root con sudo.
En algunas distribuciones, un archivo de configuración secundario puede anular tu configuración. Comprueba si hay anulaciones:
grep -r "PasswordAuthentication" /etc/ssh/sshd_config.d/
Si algún archivo en ese directorio establece PasswordAuthentication yes, edítalo o elimínalo.
Valida la sintaxis de la configuración antes de reiniciar:
sshd -t
Una salida limpia (sin errores) significa que es seguro recargar. Aplica los cambios:
systemctl restart sshd
Advertencia crítica: No cierres tu sesión SSH existente antes de abrir una segunda terminal y confirmar que aún puedes iniciar sesión con tu clave. Reiniciar sshd con un archivo mal configurado o antes de que tu clave funcione te dejará sin acceso. La mayoría de los Paneles de Control VPS proporcionan una consola de emergencia (acceso KVM/VNC) para la recuperación, pero es mucho mejor evitar la situación por completo.
Paso 8: Gestionar múltiples claves y servidores con ~/.ssh/config
Cuando se gestionan varios servidores — algo común en entornos de staging/producción o al administrar múltiples Servidores Dedicados — el archivo de configuración del cliente SSH elimina la necesidad de recordar direcciones IP, nombres de usuario y rutas de claves.
Crea o edita ~/.ssh/config en tu máquina local:
nano ~/.ssh/config
Ejemplo de configuración para múltiples hosts:
Host production-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host staging-vps
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_staging
    Port 2222

Host legacy-server
    HostName 203.0.113.30
    User admin
    IdentityFile ~/.ssh/id_rsa_legacy
    PubkeyAcceptedKeyTypes +ssh-rsa
Establece los permisos correctos en el archivo de configuración:
chmod 600 ~/.ssh/config
Ahora puedes conectarte con alias limpios:
ssh production-vps
ssh staging-vps
La directiva PubkeyAcceptedKeyTypes +ssh-rsa en la entrada heredada es importante: los clientes OpenSSH más nuevos (8.8+) deshabilitan RSA-SHA1 por defecto. Sin esta anulación, las conexiones a servidores más antiguos fallarán con un críptico error de “no matching host key type”.
Solución de problemas: por qué falla la autenticación con clave SSH
Incluso con una configuración correcta, varios factores ambientales pueden hacer que la autenticación con clave vuelva silenciosamente a solicitar contraseña:
Permisos incorrectos en .ssh o authorized_keys:
Ejecuta ls -la ~/.ssh/ en el servidor. El directorio debe ser 700 y el archivo debe ser 600. Cualquier permiso más permisivo hace que OpenSSH ignore el archivo.
Desajuste de contexto SELinux o AppArmor:
En sistemas RHEL/CentOS/AlmaLinux con SELinux en modo de aplicación, el archivo authorized_keys puede tener el contexto de seguridad incorrecto. Restáuralo con:
restorecon -Rv ~/.ssh
Directorio home del usuario incorrecto:
Si el directorio home del usuario no es escribible solo por el propietario, SSH rechazará la autenticación con clave. Comprueba con:
ls -ld ~
El directorio home en sí no debe tener permisos de escritura para el grupo o para todos.
Directiva AuthorizedKeysFile apuntando a otro lugar:
Algunas distribuciones configuran AuthorizedKeysFile para usar una ruta no estándar (p. ej., /etc/ssh/authorized_keys/%u). Verifica la configuración activa:
sshd -T | grep authorizedkeysfile
Múltiples claves y conflictos con ssh-agent:
Si ssh-agent está en ejecución con varias claves cargadas, el servidor puede rechazar la conexión después de demasiados intentos fallidos con claves antes de probar la correcta. Usa -i para especificar la clave explícitamente, o configura IdentitiesOnly yes en ~/.ssh/config.
Firewall o fail2ban bloqueando tu IP:
Si anteriormente has fallado múltiples intentos de inicio de sesión, fail2ban o las reglas de ufw/iptables pueden haber bloqueado temporalmente tu IP. Comprueba con:
fail2ban-client status sshd
Rotación y revocación de claves SSH
La rotación de claves es una práctica de higiene de seguridad que a menudo se descuida. Para revocar una clave específica, abre ~/.ssh/authorized_keys en el servidor y elimina la línea correspondiente. Cada línea es una clave — eliminarla revoca inmediatamente el acceso al titular de esa clave privada sin afectar a ninguna otra clave autorizada.
Para fines de auditoría, usa comentarios distintos en cada clave (la parte después del material de la clave, p. ej., alice@workstation-2024) para poder identificar qué clave pertenece a qué persona o dispositivo. Cuando un empleado se va o un dispositivo se da de baja, localiza su clave por comentario y elimínala.
Para rotar tu propia clave, genera un nuevo par, añade la nueva clave pública a authorized_keys, verifica que el inicio de sesión funciona con la nueva clave y luego elimina la entrada de la clave antigua.
Lista de verificación práctica

Genera claves Ed25519 por defecto; usa RSA 4096 solo para compatibilidad con servidores heredados
Protege siempre tu clave privada con una frase de contraseña fuerte
Usa ssh-copy-id para una implementación de claves rápida y sin errores cuando sea posible
Verifica que los permisos del directorio .ssh sean 700 y que authorized_keys sea 600

Preguntas frecuentes

¿Puedo añadir múltiples claves públicas SSH a la misma cuenta de usuario VPS?

Sí. Cada línea en ~/.ssh/authorized_keys es una clave autorizada independiente. Añade una clave por línea. Este es el enfoque estándar para conceder acceso a múltiples administradores o desde múltiples dispositivos — cada persona o dispositivo tiene una clave privada única, y la revocación es por línea.

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

Quedarás bloqueado fuera de SSH. La recuperación requiere usar el acceso a consola fuera de banda de tu proveedor de hosting (KVM/VNC), disponible a través de la mayoría de los paneles de control de VPS Hosting. Desde la consola, vuelve a habilitar PasswordAuthentication yes en /etc/ssh/sshd_config, reinicia sshd y sube una nueva clave. Por eso probar el inicio de sesión con clave antes de deshabilitar las contraseñas es innegociable.

¿Es Ed25519 compatible con todos los servidores?

Ed25519 requiere OpenSSH 6.5 o posterior (lanzado en 2014). Cualquier distribución Linux moderna — Ubuntu 18.04+, Debian 9+, CentOS 7+, AlmaLinux 8+ — lo admite de forma nativa. Solo los sistemas genuinamente antiguos requieren el uso de RSA como alternativa.

¿Debo usar el mismo par de claves SSH para cada servidor que gestiono?

Es operativamente conveniente, pero crea un único punto de compromiso. Una mejor práctica es usar un par de claves por rol o entorno (p. ej., una clave para servidores personales, otra para infraestructura de clientes). Esto limita el radio de impacto si alguna vez se expone una clave privada.

¿Subir una clave SSH afecta a mis Certificados SSL o a la configuración del servidor web?

No. Las claves SSH controlan el acceso por terminal al sistema operativo y son completamente independientes de los certificados TLS/SSL utilizados por los servidores web (Apache, Nginx) para HTTPS. Usan puertos diferentes (22 frente a 443), formatos de clave diferentes y cadenas de confianza diferentes. Cambiar uno no tiene ningún efecto sobre el otro.