Área de cliente
Linux•24 de julio de 2026• 1 vista

Claves SSH: generar, instalar y asegurar el acceso a su servidor

Claves SSH: generar, instalar y asegurar el acceso a su servidor

La contraseña es el eslabón más débil de cualquier servidor expuesto en Internet. Puede ser adivinada, reutilizada, interceptada o quebrantada por fuerza bruta. La autenticación por clave SSH resuelve el problema en su raíz: en lugar de un secreto que se teclea, se utiliza un par de claves criptográficas casi imposibles de adivinar. Es más seguro, y en el día a día, también es más práctico: no hay más contraseña que ingresar en cada conexión.

Esta guía cubre todo el ciclo de vida de una clave SSH en un VPS Linux: entender el principio, generar un par de claves modernas con ssh-keygen, instalarlo en el servidor, conectarse, usar el agente SSH y luego desactivar completamente la autenticación por contraseña para bloquear el acceso.

¿Cómo funciona un par de claves SSH?

La autenticación por clave se basa en dos archivos complementarios:

  • La clave privada permanece en su computadora. Nunca debe salir de su máquina ni ser compartida. Es su secreto.
  • La clave pública se deposita en el servidor. Puede circular libremente: conocer la clave pública no permite reconstruir la clave privada.

Al conectarse, el servidor envía un desafío que solo la clave privada correspondiente puede resolver. Si la prueba es válida, se concede el acceso sin que ningún secreto transite por la red. Esto es lo que hace que el método sea tanto más seguro que una contraseña como resistente a la escucha.

Requisitos previos

  • Acceso a su VPS bajo Linux (Ubuntu, Debian...), por SSH.
  • Un terminal en su computadora: Terminal en macOS/Linux, o PowerShell / Windows Terminal en Windows (OpenSSH está integrado desde Windows 10).
  • Unos minutos. Este es el tutorial más simple del recorrido de seguridad, y el más rentable.

Generar un par de claves SSH con ssh-keygen

La generación se realiza en su computadora, no en el servidor. Abra su terminal y ejecute:

ssh-keygen -t ed25519 -C "[email protected]"

Algunas explicaciones:

  • -t ed25519 elige el algoritmo. Ed25519 es hoy el estándar recomendado: claves cortas, muy rápidas y muy seguras. Si debe lidiar con un sistema antiguo que no lo soporta, recurra a -t rsa -b 4096.
  • -C añade un comentario (típicamente su correo electrónico) para identificar la clave más tarde.

ssh-keygen luego hace dos preguntas:

  1. La ubicación del archivo: valide la ruta por defecto (~/.ssh/id_ed25519) presionando Enter.
  2. Una frase secreta (passphrase): es una contraseña que cifra su clave privada en el disco. Elija una. Así, incluso si su computadora es comprometida, la clave robada sigue siendo inutilizable. El agente SSH (ver más abajo) le evitará tener que volver a escribirla en cada conexión.

Se crean dos archivos en ~/.ssh/:

id_ed25519        → su clave privada (mantener en secreto)
id_ed25519.pub    → su clave pública (depositar en el servidor)

Instalar la clave pública en el servidor

El objetivo es añadir su clave pública al archivo ~/.ssh/authorized_keys de su usuario en el VPS. El método más simple es ssh-copy-id:

ssh-copy-id usuario@IP_DEL_SERVIDOR

El comando le pide una última vez su contraseña (la del servidor), luego copia y configura todo automáticamente, con los permisos correctos. Ha terminado.

Si ssh-copy-id no está disponible (en Windows, por ejemplo), el método manual funciona en todas partes:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh usuario@IP_DEL_SERVIDOR "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

En macOS/Linux, el equivalente:

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

Conectarse con su clave

Pruebe inmediatamente la conexión por clave, antes de tocar nada más:

ssh usuario@IP_DEL_SERVIDOR

Si ha definido una frase secreta, se le pedirá (es la de la clave, no la del servidor). Está conectado sin la contraseña del servidor: la clave funciona. No pase a la etapa de desactivación de la contraseña hasta que esta conexión esté confirmada.

Usar el agente SSH para no volver a escribir la passphrase

Ingresar la frase secreta en cada conexión se vuelve rápidamente tedioso. El agente SSH mantiene su clave desbloqueada en memoria durante la duración de su sesión. Inícielo y luego añada su clave:

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

Solo ingresa la passphrase una vez; las conexiones siguientes son transparentes. En macOS, puede guardar la clave en el llavero del sistema con ssh-add --apple-use-keychain. En Windows, active el servicio ssh-agent (Get-Service ssh-agent | Set-Service -StartupType Automatic) y luego ssh-add.

Para listar las claves actualmente cargadas en el agente:

ssh-add -l

El archivo de configuración SSH (bonus práctico)

Para no tener que teclear la IP y el usuario, cree un acceso directo en ~/.ssh/config en su computadora:

Host monvps
    HostName 203.0.113.10
    User monusuario
    IdentityFile ~/.ssh/id_ed25519

Un simple comando ssh monvps será suficiente para conectarse.

Desactivar la autenticación por contraseña

Este es el paso que realmente bloquea su servidor: una vez confirmada la conexión por clave, se prohíbe totalmente la contraseña. Así, incluso el mejor ataque por fuerza bruta no sirve de nada.

Advertencia: no haga esto hasta haber verificado que la conexión por clave funciona. Idealmente, mantenga una segunda sesión SSH abierta durante la manipulación, como red de seguridad.

En el servidor, edite la configuración del demonio SSH:

sudo nano /etc/ssh/sshd_config

Asegúrese de tener estas directivas (descoméntelas y ajuste los valores):

PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password

PermitRootLogin prohibit-password permite a root solo por clave (o lo desactiva con no si siempre pasa por un usuario sudo, lo cual es preferible). Guarde y luego recargue el servicio:

sudo systemctl restart ssh

En algunas distribuciones recientes, la configuración puede ser sobreescrita por un archivo en /etc/ssh/sshd_config.d/. Si PasswordAuthentication no parece ser ignorado, verifique esta carpeta. Luego pruebe una nueva conexión: la contraseña ya no debe ser aceptada.

Buenas prácticas

  • Una clave por dispositivo. Genere un par distinto en cada máquina desde la que se conecta, en lugar de copiar la misma clave privada en todas partes. En caso de pérdida de un dispositivo, simplemente retira su clave pública del servidor.
  • Proteja la clave privada con una passphrase. Una clave privada sin frase secreta ofrece acceso total a cualquiera que tenga el archivo.
  • No comparta nunca la clave privada. Solo se transmite el archivo .pub.
  • Haga copias de seguridad de sus claves en un lugar seguro: perder su clave privada es perder el acceso configurado.
  • Combine con un firewall. Restringir el puerto SSH y abrir solo lo necesario refuerza todo, vea la etapa UFW del recorrido a continuación.

Solución de problemas: « Permission denied (publickey) »

Este es el error más frecuente, y casi siempre proviene de los permisos de archivos. SSH se niega a usar una carpeta o un archivo de claves con permisos demasiado amplios. En el servidor, corrija:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Otras pistas comunes:

  • Usuario o clave incorrectos: verifique que se está conectando con la cuenta correcta y que la clave privada correspondiente está presente (ssh -i ~/.ssh/id_ed25519 usuario@IP).
  • Diagnóstico detallado: añada -v (incluso -vvv) a su comando ssh para ver exactamente qué clave se está ofreciendo y dónde se bloquea.
  • authorized_keys mal formado: la clave pública debe estar en una sola línea.

Preguntas frecuentes

¿Ed25519 o RSA? Ed25519 para cualquier servidor moderno: más corta, más rápida, igual de segura. RSA 4096 sigue siendo una opción válida para sistemas antiguos.

¿Qué hacer si pierdo mi clave privada? No podrá conectarse con ella. Conéctese por otro medio (otra clave, consola de recuperación del VPS), luego retire la antigua clave pública de authorized_keys y añada una nueva.

¿Puedo usar la misma clave en varios servidores? Técnicamente sí: solo necesita depositar la misma clave pública en cada uno. Pero prefiera una clave por estación de trabajo en lugar de una clave única duplicada en todas sus máquinas.

¿Las claves SSH funcionan en Windows? Sí, OpenSSH está integrado en Windows 10 y 11. Todos los comandos de esta guía funcionan en PowerShell o Windows Terminal.

El recorrido de seguridad de su servidor

La autenticación por clave es el primer ladrillo de un servidor bien defendido, el que cierra la puerta de entrada. Para completar el proceso en su VPS Linux, continúe con el resto del recorrido:

  1. Claves SSH reemplazar la contraseña por una autenticación por claves (está aquí).
  2. UFW cerrar todos los puertos innecesarios con un firewall simple (guía por venir).
  3. Fail2ban prohibir automáticamente a los atacantes que insisten (guía por venir).
  4. Certbot cifrar sus servicios con un certificado SSL Let's Encrypt (guía por venir).

Encuentre todos nuestros tutoriales en la documentación de Linux. En menos de diez minutos, transformará el acceso a su servidor: de « contraseña vulnerable » a « clave criptográfica imposible de adivinar ».

Volver a la documentación