Claves SSH: configurar el acceso al servidor sin contraseña

Una clave SSH es un par de archivos: la clave privada se queda con usted y la pública se copia al servidor. Al conectarse, el servidor comprueba que usted posee la clave privada correspondiente a una de las claves públicas autorizadas, y le deja entrar sin contraseña. Es más cómodo y mucho más seguro que una contraseña: adivinar una clave por fuerza bruta es prácticamente imposible. A continuación se explica la configuración de claves SSH, desde la generación hasta la desactivación del acceso por contraseña, con los errores en los que más se tropieza.

Cómo funciona la autenticación por clave

Las claves son asimétricas. La clave pública (id_ed25519.pub) puede mostrarse a cualquiera: con ella no se puede reconstruir la privada. La clave privada (id_ed25519) nunca sale de su equipo ni se envía por la red.

Al conectarse, el cliente indica al servidor qué clave quiere usar. El servidor busca esa clave pública en el archivo ~/.ssh/authorized_keys del usuario y, si la encuentra, pide al cliente que firme los datos de la sesión con la clave privada. La firma se verifica con la clave pública y se permite el acceso. En ningún momento se transmite una contraseña.

Paso 1. Generar una clave: ssh-keygen

En su equipo (Linux, macOS o Windows 10/11 con OpenSSH integrado) ejecute:

ssh-keygen -t ed25519 -C "alena@laptop"

La opción -t elige el algoritmo, y -C añade un comentario que se incluye al final de la clave pública y que ayuda a saber de quién es. Ed25519 es el algoritmo moderno recomendado: las claves son cortas, rápidas y seguras. Si el servidor es muy antiguo y no admite Ed25519, use RSA de al menos 3072 bits: ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

¿Hace falta una frase de contraseña?

La frase de contraseña cifra la clave privada en el disco. Si el portátil se roba o el archivo se filtra, sin ella la clave no sirve de nada. Para una clave personal conviene ponerla; y para no escribirla en cada conexión, use ssh-agent: mantiene la clave descifrada en memoria hasta el final de la sesión.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # listar las claves cargadas

Las claves sin frase de contraseña se justifican para la automatización, por ejemplo para la CI o un script de copias de seguridad. Esa clave debe restringirse en el servidor (más abajo).

Paso 2. Copiar la clave pública al servidor: ssh-copy-id

La forma más sencilla es ssh-copy-id. Se conecta una última vez con la contraseña, añade su clave pública a ~/.ssh/authorized_keys en el servidor y ajusta los permisos correctos.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Si el servidor escucha en un puerto no estándar, añada -p 2222.

Si ssh-copy-id no está disponible

En Windows no existe ssh-copy-id. La clave puede transferirse a mano con un solo comando:

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

Los proveedores de nube suelen pedir la clave pública al crear el servidor: entonces se añade a authorized_keys mediante cloud-init.

Paso 3. Comprobar el acceso

ssh deploy@203.0.113.10

Si ya no pide contraseña (o solo la frase de la clave), todo funciona. En la primera conexión a un servidor nuevo, SSH muestra la huella de la clave del host y pregunta si confía en él. Tras responder yes, la huella se guarda en ~/.ssh/known_hosts y, a partir de entonces, SSH avisa si la clave del servidor cambia.

Para ver qué claves prueba el cliente y por qué rechaza el servidor, lance la conexión en modo detallado:

ssh -v deploy@203.0.113.10

El archivo ~/.ssh/config: nombres cortos para los servidores

Cuando hay varios servidores, escribir cada vez el usuario, la IP, el puerto y la ruta de la clave resulta tedioso. Todo eso se describe en ~/.ssh/config:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host bd-interna
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Ahora basta con ssh prod, y scp, rsync y Git también entienden estos nombres: rsync -av ./sitio/ prod:/var/www/.

• IdentitiesOnly yes — usar solo la clave indicada. Sin esta línea, el cliente prueba todas las claves del agente, y el servidor puede desconectarle por exceso de intentos antes de llegar a la correcta.
• ProxyJump — conectarse a un servidor interno a través de uno intermedio (bastión) con un solo comando.
• ServerAliveInterval — enviar un «ping» cada 60 segundos para que la conexión no se corte cuando está inactiva.

El archivo debe tener permisos 600, o SSH puede negarse a leerlo: chmod 600 ~/.ssh/config.

Agent forwarding: cuándo es necesario y por qué es arriesgado

A veces hay que saltar desde un servidor a otro, por ejemplo para hacer git pull de un repositorio privado. No conviene copiar la clave privada a ese servidor. En su lugar se usa ssh -A o ForwardAgent yes: el servidor obtiene acceso a su agente durante la sesión. Pero cualquiera con root en ese servidor también puede usar el agente mientras usted está conectado. Por eso active el reenvío solo para hosts de confianza, y para saltar a través de un servidor intermedio prefiera ProxyJump, que no expone el agente.

Paso 4. Desactivar el acceso por contraseña

Mientras el acceso por contraseña esté permitido, el servidor sigue siendo objetivo de ataques de fuerza bruta. Cuando compruebe que entra con clave, desactive las contraseñas. Importante: no cierre la sesión actual hasta haber probado el acceso en una ventana nueva; si no, podría quedarse sin acceso.

Abra /etc/ssh/sshd_config (o cree un archivo en /etc/ssh/sshd_config.d/ si la configuración principal lo incluye con la directiva Include) y establezca:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no prohíbe por completo entrar como root: los administradores entran con sus propios usuarios y obtienen privilegios con sudo. Si no puede prescindir del acceso como root, use PermitRootLogin prohibit-password: solo por clave.

Compruebe la sintaxis y recargue el servicio:

sudo sshd -t
sudo systemctl reload ssh      # en Debian/Ubuntu; en sistemas RHEL — sshd

El comando sshd -t no muestra nada si la configuración es correcta. Ahora, en una terminal nueva, compruebe que el acceso con clave funciona y que el servidor rechaza el acceso con contraseña:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Protección adicional

Desactivar las contraseñas es la medida principal. Después se suele limitar el acceso al puerto 22 con el cortafuegos (ufw allow from 198.51.100.0/24 to any port 22) e instalar fail2ban, que bloquea una IP tras una serie de intentos fallidos. El estado de la protección SSH se consulta con sudo fail2ban-client status sshd.

Una clave usada para automatización puede restringirse directamente en authorized_keys con opciones delante de la clave: por ejemplo, from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup permite el acceso solo desde una dirección y sin shell interactiva.

Errores habituales y cómo corregirlos

Permission denied (publickey)

El error más común. Las causas, de la más frecuente a la más rara:

1. Permisos incorrectos en el servidor. sshd ignora authorized_keys si el directorio o el archivo son escribibles por otros. Solución: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, y el directorio personal no debe ser escribible por el grupo ni por otros.
2. Propietario incorrecto. Si creó los archivos con sudo, pertenecen a root. Solución: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. La clave se colocó para otro usuario. Copió la clave para root, pero entra como deploy, o al revés.
4. El cliente ofrece otra clave. Mire ssh -v: las líneas Offering public key muestran qué claves se prueban. Indique la correcta con -i o con IdentityFile.
5. La clave se estropeó al copiarla. La clave pública debe ocupar una sola línea. Un salto de línea del portapapeles la rompe.

El motivo del rechazo en el servidor aparece en el registro: sudo journalctl -u ssh -n 30 (en RHEL, -u sshd). Allí aparecen líneas como Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

El cliente se niega a usar una clave privada que otros usuarios pueden leer. Solución: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

La clave del host no coincide con la guardada en known_hosts. Esto ocurre tras reinstalar un servidor o cambiar su IP, pero también se parece a un ataque de tipo «hombre en el medio». Asegúrese de que el servidor se reinstaló de verdad y elimine la entrada antigua: ssh-keygen -R 203.0.113.10.

Too many authentication failures

El agente ofreció al servidor demasiadas claves, y este cerró la conexión por MaxAuthTries. La solución es IdentitiesOnly yes y un IdentityFile explícito en ~/.ssh/config.

Resumen

Configurar las claves SSH lleva cinco minutos: ssh-keygen -t ed25519, ssh-copy-id, comprobar el acceso, y después PasswordAuthentication no y recargar sshd mientras una segunda sesión permanece abierta. El archivo ~/.ssh/config evita comandos interminables, y los permisos 700/600 resuelven la mayoría de errores «Permission denied». SSH, rsync y la protección del servidor con cortafuegos y fail2ban se explican con práctica en nuestro curso de Linux.