Claves SSH para entrar a tu servidor sin contraseña

Qué ganás con una clave

Con contraseña, el secreto viaja al servidor en cada conexión y cualquiera puede probar suerte. Con una clave, el servidor propone un desafío distinto en cada conexión, tu computadora lo firma con la parte privada y el servidor comprueba la firma con la parte pública que tiene guardada. Por la red no pasa nada que sirva para entrar después.

La diferencia se ve en los registros de cualquier VPS con IP pública: miles de intentos por día contra root, admin, ubuntu y otros nombres comunes. Con la contraseña apagada, todos esos intentos se cortan antes de empezar. Una clave ed25519, además, es corta, rápida y la aceptan todas las distribuciones actuales.

Paso 1: generar el par en tu computadora

Todo esto se hace en tu equipo, no en el servidor: la Terminal en macOS, cualquier consola en Linux, PowerShell en Windows. El comando es el mismo en los tres:

ssh-keygen -t ed25519 -C "ana@oficina-2026"

• El texto de -C es solo una etiqueta. Poné quién sos y desde qué equipo: dentro de un año, en el servidor, es lo que te dice de dónde viene cada clave.
• Aceptá la ubicación que propone: ~/.ssh/id_ed25519 en Linux y macOS, C:\Users\ana\.ssh\id_ed25519 en Windows. Si pregunta por sobrescribir, es porque existe una clave anterior en esa ruta: contestá que no, porque pisarla te deja sin entrada en cada servidor donde esté cargada.
• Ponele una frase de paso. Si te roban la notebook, el archivo solo no alcanza para entrar a ningún lado, y con el agente (más abajo) la frase se escribe una vez por sesión.
• Quedan dos archivos. El que termina en .pub es la clave pública: se puede mandar por correo o pegar en un formulario sin riesgo. El otro es la privada, y no se copia a ningún lado.

Paso 2: cargar la clave pública en el servidor

La clave se carga en la cuenta con la que vas a entrar. Si el servidor es nuevo y solo tenés root, cargala ahí y después creá tu propio usuario, como se explica en usuario administrador con sudo.

Desde Linux o macOS se usa ssh-copy-id: te pide la contraseña del servidor una vez más, crea ~/.ssh/authorized_keys si hace falta y suma tu clave a la lista, respetando las que ya había. Con -p le indicás el puerto si SSH no escucha en el 22, y con -i elegís qué clave mandar si tenés varias.

En Windows esa herramienta no viene, pero la misma tarea sale con una línea de PowerShell que le pasa el .pub al servidor y lo suma a la lista. El umask 077 hace que la carpeta y el archivo nuevos queden con los permisos que SSH exige.

# Linux o macOS
ssh-copy-id -p 22 -i ~/.ssh/id_ed25519.pub ana@198.51.100.20
# Windows, en PowerShell
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh ana@198.51.100.20 "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"

Paso 3: probar desde otra terminal

1. No cierres la sesión que ya tenés abierta en el servidor. Es tu salida de emergencia si algo queda mal.
2. Abrí una terminal nueva y conectate forzando el uso de la clave: ssh -o PreferredAuthentications=publickey ana@198.51.100.20. Si entra, o si solo te pide la frase de paso de tu clave, funciona.
3. Si responde "Permission denied", repetí con -v y buscá tres líneas: "Offering public key" (qué clave ofrece tu equipo), "Server accepts key" (si el servidor la reconoce) y "Authenticated" (si terminó de entrar). La que falta te dice dónde está el problema.

Un archivo de configuración para no escribir IP ni puerto

En ~/.ssh/config, en tu computadora, cada servidor puede tener un nombre corto con todos sus datos. Después alcanza con ssh tienda, y el mismo nombre sirve para scp, rsync y sftp.

Host tienda
    HostName 198.51.100.20
    User ana
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    AddKeysToAgent yes

• IdentitiesOnly yes evita que tu equipo pruebe todas sus claves hasta dar con la correcta. Con cinco o seis cargadas, el servidor corta antes con "Too many authentication failures".
• AddKeysToAgent yes suma la clave al agente la primera vez que la usás, así no volvés a escribir la frase de paso en esa sesión.
• En macOS podés agregar UseKeychain yes para que la frase quede en el Llavero. Si compartís el archivo con un equipo Linux, poné antes IgnoreUnknown UseKeychain, porque Linux no conoce esa opción y da error.
• El archivo tiene que ser solo tuyo: chmod 600 ~/.ssh/config. Si otros usuarios pueden escribirlo, SSH se niega a leerlo.

El agente en cada sistema

• Linux: en casi todos los escritorios el agente arranca solo. Si ssh-add -l dice que no hay agente, levantalo en esa terminal con eval "$(ssh-agent -s)" y cargá la clave con ssh-add ~/.ssh/id_ed25519.
• macOS: el agente ya corre. ssh-add --apple-use-keychain ~/.ssh/id_ed25519 carga la clave y guarda la frase en el Llavero, que la recuerda aun después de reiniciar.
• Windows: el servicio viene apagado. En una PowerShell como administrador, Get-Service ssh-agent | Set-Service -StartupType Automatic y después Start-Service ssh-agent. Desde tu usuario, ssh-add carga la clave.

Paso 4: apagar la contraseña

Con la clave probada, la contraseña se apaga en el servidor. Conviene hacerlo en un archivo propio dentro de /etc/ssh/sshd_config.d/ y no en el principal: en Debian 12 y 13, Ubuntu 24.04 y AlmaLinux 9 y 10 esa carpeta se lee al principio, y en SSH vale el primer valor que aparece para cada opción. Con un nombre que empiece con 01-, tu archivo se lee antes que el 50-cloud-init.conf que traen algunas imágenes de nube y que vuelve a habilitar la contraseña.

sudo tee /etc/ssh/sshd_config.d/01-solo-claves.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF
sudo sshd -t
sudo systemctl restart ssh    # en AlmaLinux: sudo systemctl restart sshd

1. sshd -t revisa la sintaxis: el silencio significa que el archivo es válido, y cualquier error se corrige antes de reiniciar.
2. Reiniciar el servicio no echa a nadie: la sesión que dejaste abierta en el paso 3 sigue funcionando.
3. Confirmá los valores en uso con sudo sshd -T | grep -Ei "passwordauth|kbdinteractive|permitroot".
4. Desde tu computadora, ssh -o PubkeyAuthentication=no ana@198.51.100.20 tiene que rebotar sin ofrecerte escribir la contraseña.
5. PermitRootLogin prohibit-password deja entrar a root solo con clave. Si ya trabajás con un usuario con sudo, podés poner no.

Si el servidor ignora tu clave

El motivo exacto del rechazo queda en el servidor: sudo journalctl -u ssh -n 30 en Debian y Ubuntu, sudo journalctl -u sshd -n 30 en AlmaLinux.

Cuatro salidas si perdiste el acceso

• Con la primera sesión todavía abierta, borrá el archivo que creaste en /etc/ssh/sshd_config.d/ y reiniciá SSH. Todo vuelve a como estaba.
• Si tenés otro usuario con su propia clave, entrá con ese y corregí desde ahí.
• En los servidores cloud de InHosting tenés una consola de rescate, que entra al equipo sin pasar por SSH ni por la red.
• Si no te queda ninguna de esas vías, escribinos por ticket y lo resolvemos con vos.