Genera la clave en la máquina donde estás sentado
No en el servidor. La parte privada nunca debe existir en un host al que podrías perder el acceso, y copiarla anula el propósito de tenerla.
ssh-keygen -t ed25519 -a 100 -C "laptop-2026"-a 100 establece el número de rondas de KDF que protegen la frase de contraseña, que es lo único que se interpone entre un portátil robado y tu flota. Usa una frase de contraseña. Si tienes un token de hardware, úsalo en su lugar:
ssh-keygen -t ed25519-sk -O resident -C "token-1"Instala la parte pública
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@<ipv4>A mano, desde una sesión root, si la cuenta no tiene contraseña todavía:
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
install -m 600 -o deploy -g deploy /dev/null /home/deploy/.ssh/authorized_keys
cat >> /home/deploy/.ssh/authorized_keysPega la línea única y luego Ctrl-D. Los permisos importan más de lo que la gente espera: sshd rechaza un home escribible por el grupo o un directorio .ssh, y solo se explica en el log del demonio, nunca al cliente.
Restringe la clave mientras estás ahí
Las opciones en authorized_keys se aplican por clave. restrict lo desactiva todo, y luego añades de nuevo lo que la clave realmente necesita:
restrict,pty ssh-ed25519 AAAAC3Nza... deploy@laptopUna clave que existe para ejecutar un trabajo debe poder ejecutar solo ese trabajo:
restrict,command="/usr/local/bin/backup-receive" ssh-ed25519 AAAAC3Nza... backupPrueba antes de bloquear
Deja la primera sesión conectada. Desde una segunda terminal:
ssh -o PreferredAuthentications=publickey deploy@<ipv4> idSi eso imprime tu uid, la ruta de la clave funciona. Si no, ssh -vvv en el cliente y journalctl -u ssh -n 50 en el servidor dirán entre ambos qué lado está fallando. La mayoría de las veces son los permisos, y el resto, el nombre de usuario incorrecto.
Apaga las contraseñas
cat > /etc/ssh/sshd_config.d/20-keys-only.conf <<EOF
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey
EOF
sshd -t && systemctl reload sshAuthenticationMethods publickey es el cinturón debajo de los tirantes. Incluso si un drop-in posterior reactiva silenciosamente las contraseñas, el demonio sigue rechazando todo lo que no sea una clave.
Confirma desde el cliente que la puerta está cerrada:
ssh -o PreferredAuthentications=password deploy@<ipv4>El resultado esperado es Permission denied (publickey).
Claves en el momento del despliegue
El panel mantiene una lista de claves por cuenta. Marca las que quieras y cloud-init las escribe durante el primer arranque, lo que significa que una instancia puede existir por primera vez con la autenticación por contraseña ya desactivada. Adjuntar la clave al pedido convierte los diez minutos anteriores en uno.
Cuando pierdes la clave
Aquí no hay recuperación basada en identidad, porque no tenemos identidad. La consola fuera de banda es el camino de regreso: llega a la instancia por una ruta que nunca toca sshd, y desde un shell de rescate puedes añadir una nueva clave y continuar.
Guarda una segunda clave en una segunda máquina y nunca necesitarás leer ese artículo.