Entrar al VPS con clave SSH en lugar de contraseña

Qué cambia respecto de la contraseña

Con una contraseña, el secreto viaja hasta el servidor en cada conexión. Con una clave no viaja nada: el servidor manda un desafío, tu equipo lo firma con la privada y él verifica esa firma contra la pública que ya tenía guardada. El cambio se nota en los registros: un VPS con contraseña habilitada acumula miles de intentos automatizados por día contra root, admin y cualquier nombre común, y con la contraseña apagada todos mueren en el primer paso.

Generar el par de claves en Linux o macOS

1. Abrí una terminal en tu computadora, no en el servidor. La clave privada se genera donde la vas a usar y de ahí no se mueve.
2. Escribí ssh-keygen -t ed25519 -a 100 -C "juan@notebook". El texto del final es un comentario que queda dentro del archivo público y dice, dentro de seis meses, de qué equipo salió.
3. Aceptá con Enter la ruta que propone, ~/.ssh/id_ed25519, salvo que ya tengas una clave con ese nombre: si le das Enter igual, la pisás.
4. Poné una frase de paso cuando la pida. Es lo que protege el archivo si alguien se lleva tu notebook, y no la vas a tipear en cada conexión: el agente de claves la recuerda mientras dure la sesión de tu escritorio.
5. Te quedan dos archivos. id_ed25519 es la privada: no se copia, no se manda y no se sube a un repositorio. id_ed25519.pub es la pública y viaja por cualquier medio sin riesgo.

Cada archivo y su lugar

Si el servidor escucha en un puerto distinto del 22, el lugar para anotarlo es ~/.ssh/config, y así no lo tipeás nunca más.

Copiar la clave pública al servidor

1. Desde tu computadora, escribí ssh-copy-id juan@203.0.113.24. Te va a pedir la contraseña del servidor: es la última vez.
2. Si SSH escucha en otro puerto, el puerto va en la herramienta y no en la dirección: ssh-copy-id -p 2222 juan@203.0.113.24. Olvidarse del -p es el motivo número uno por el que este paso parece fallar. Si tenés varias claves, elegí cuál con -i ~/.ssh/id_ed25519.pub.
3. La herramienta crea ~/.ssh y authorized_keys si no existían, y agrega tu clave al final sin borrar las que ya estaban.
4. Si el sistema no tiene ssh-copy-id, entrá por contraseña y pegá el contenido del .pub como una sola línea al final de ~/.ssh/authorized_keys. Después: chmod 700 ~/.ssh y chmod 600 ~/.ssh/authorized_keys.

Lo mismo desde Windows

1. Windows 10 y 11 traen el cliente de OpenSSH. Abrí PowerShell y escribí ssh: si responde, ya está; si no, se agrega desde Configuración, en "Características opcionales".
2. Generá la clave igual que en Linux: ssh-keygen -t ed25519 -a 100 -C "juan@windows". Los archivos quedan en %USERPROFILE%\.ssh\, que es C:\Users\juan\.ssh.
3. Windows no trae ssh-copy-id, así que el archivo se copia con scp, que sí viene incluido: scp $env:USERPROFILE\.ssh\id_ed25519.pub juan@203.0.113.24:/tmp/clave.pub.
4. Entrá al servidor por contraseña y agregala: mkdir -p ~/.ssh && cat /tmp/clave.pub >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys && rm /tmp/clave.pub.
5. Para no tipear la frase de paso todo el tiempo, dejá andando el agente: en una PowerShell de administrador, Get-Service ssh-agent | Set-Service -StartupType Automatic, Start-Service ssh-agent y ssh-add $env:USERPROFILE\.ssh\id_ed25519.
6. Si pegás la clave a mano, tiene que quedar en una sola línea. Un salto de línea en el medio la invalida y el error es idéntico al de una clave equivocada.

Probar antes de tocar la configuración

1. No cierres la terminal que ya tenés conectada: esa sesión sigue viva aunque rompas la configuración.
2. Abrí una segunda terminal y entrá: ssh juan@203.0.113.24. Si no te pide nada, o te pide la frase de paso de tu propia clave, ya está andando.
3. La prueba que no deja dudas es prohibirle la contraseña al cliente: ssh -o PasswordAuthentication=no -o KbdInteractiveAuthentication=no juan@203.0.113.24. Si entra igual, entró por clave.
4. Si te sigue pidiendo la contraseña del servidor, repetí con -v y leé las líneas donde el cliente ofrece tu clave y el servidor decide. Ahí se ve si ofrece otra clave o si el servidor la rechaza.

Cuando la clave está bien y el servidor igual la rechaza

Casi siempre son los permisos. Antes de leer authorized_keys, SSH revisa el modo y el dueño del home, de la carpeta .ssh y del archivo; si alguno es escribible por el grupo o por otros, ignora la clave y sigue de largo. Del lado del cliente eso se ve como una contraseña que se vuelve a pedir, sin explicación.

Lo que espera es chmod 700 en ~/.ssh y chmod 600 en ~/.ssh/authorized_keys, con el home sin escritura para grupo ni otros, y todo eso perteneciendo al usuario: si armaste la carpeta estando como root, quedó de root y se corrige con chown -R juan:juan /home/juan/.ssh. El motivo exacto está del lado del servidor, en sudo journalctl -u ssh -n 50.

Recién ahora, apagar la contraseña

1. Guardá una copia de la configuración antes de tocarla: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.original.
2. Abrilo con sudo nano /etc/ssh/sshd_config y dejá tres directivas: PubkeyAuthentication yes, PasswordAuthentication no y KbdInteractiveAuthentication no. La tercera existe porque sin ella algunos sistemas siguen ofreciendo un pedido de contraseña por otra vía.
3. Mirá qué hay en /etc/ssh/sshd_config.d/. La primera línea del archivo principal incluye esa carpeta, y en SSH gana el primer valor que aparece, no el último: un archivo de ahí puede estar habilitando la contraseña aunque vos la apagues más abajo. En las imágenes de nube es común encontrar uno que empieza con 50-cloud-init.
4. Revisá la sintaxis antes de reiniciar: sudo sshd -t. Si no imprime nada, está bien.
5. Aplicá con sudo systemctl restart ssh.service. Tu sesión abierta no se corta.
6. Desde la segunda terminal, entrá de nuevo. Y comprobá que la contraseña ya no sirve: ssh -o PubkeyAuthentication=no juan@203.0.113.24 tiene que rebotar sin preguntar nada.

Si igual te quedaste afuera

• Si la primera sesión sigue abierta, ahí mismo restaurás el archivo original y reiniciás el servicio. Por eso no se cierra hasta haber entrado de nuevo.
• Si ya no hay sesión, queda la consola del panel del proveedor, que entra por fuera de la red y no depende de SSH ni del firewall.
• Si tomaste un snapshot antes de empezar, volver atrás son unos minutos y no hay nada que depurar.
• Si había otro usuario con clave propia, ese entra aunque el tuyo no. Y si nada de eso está a mano, lo coordinamos por ticket.