Por qué usar llaves en lugar de contraseña

La autenticación por contraseña es vulnerable a ataques de fuerza bruta — miles de bots están intentando entrar a tu servidor cada día probando combinaciones. Una llave pública/privada es prácticamente imposible de adivinar (son 2048 o 4096 bits aleatorios) y mejora la experiencia: entras sin teclear nada.

Cómo funciona por dentro

Generas un par de llaves: una privada que se queda en tu computadora y nunca sale de ahí, y una pública que copias al servidor. Cuando conectas, el servidor te pide que demuestres tener la llave privada correspondiente a la pública instalada — un intercambio criptográfico que nadie puede falsificar sin tener el archivo de la privada.

Paso 1 — Generar el par de llaves

En tu computadora (Windows con OpenSSH, macOS o Linux) abre terminal y ejecuta:

ssh-keygen -t ed25519 -C "tu-email@ejemplo.com"

ed25519 es un algoritmo moderno más rápido y seguro que RSA. Si tu cliente es muy viejo y no lo soporta, usa -t rsa -b 4096 como alternativa.

El comando te pregunta dónde guardar el archivo — acepta el default (~/.ssh/id_ed25519). Te pide una passphrase — es opcional pero recomendada: cifra la llave privada en tu disco con otra contraseña. Si alguien roba tu computadora, no podrá usar la llave sin ella.

Después tendrás dos archivos:

• ~/.ssh/id_ed25519 — llave privada. Nunca la compartas, ni siquiera con soporte técnico.
• ~/.ssh/id_ed25519.pub — llave pública. Esta sí se puede compartir.

Paso 2 — Copiar la llave pública al servidor

Forma fácil (si tienes acceso con contraseña primero)

ssh-copy-id usuario@ip-del-servidor

Te pide la contraseña una última vez y copia todo solo.

Forma manual

Si ssh-copy-id no está disponible:

1. Muestra el contenido de la llave pública: cat ~/.ssh/id_ed25519.pub
2. Copia todo el texto (empieza con ssh-ed25519 y termina con tu email).
3. Entra al servidor con contraseña por última vez: ssh usuario@servidor
4. Ejecuta en el servidor:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   echo "LA_LLAVE_PUBLICA_COMPLETA" >> ~/.ssh/authorized_keys
   chmod 600 ~/.ssh/authorized_keys

Paso 3 — Probar el login sin contraseña

Sal del servidor (exit) y vuelve a entrar:

ssh usuario@ip-del-servidor

Si configuraste passphrase, te la pedirá una vez por sesión. Si no, entras directo. Si te sigue pidiendo la contraseña del usuario del servidor, algo salió mal — revisa permisos y la ubicación del archivo authorized_keys.

Paso 4 — Deshabilitar login con contraseña (cuando todo funciona)

Una vez confirmado que el login por llave funciona desde todas las máquinas que necesitas, deshabilita las contraseñas para cerrar el vector de ataque:

1. En el servidor, edita /etc/ssh/sshd_config:

   sudo nano /etc/ssh/sshd_config

2. Cambia o agrega estas líneas:

   PasswordAuthentication no
   PubkeyAuthentication yes
   ChallengeResponseAuthentication no
   PermitRootLogin prohibit-password

3. Guarda y reinicia SSH:

   sudo systemctl restart sshd

Importante: antes de cerrar la sesión donde editaste el archivo, abre otra terminal y verifica que puedes entrar. Si te cerró la sesión actual y algo falló, podrías quedarte sin acceso al servidor.

Gestionar varias llaves

Si tienes diferentes servidores con llaves distintas, crea un archivo ~/.ssh/config en tu computadora:

Host oxira-vps
    HostName 192.0.2.10
    User root
    IdentityFile ~/.ssh/id_ed25519_oxira
    Port 22

Host cliente-vps
    HostName otroservidor.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_cliente
    Port 2222

Con eso, conectas con solo ssh oxira-vps — el cliente SSH selecciona host, usuario, puerto y llave automáticamente.