Cómo configurar acceso SSH con claves públicas en Ubuntu

El acceso SSH con claves públicas permite autenticarse en remoto sin enviar contraseñas por la red: en lugar de ello se usa un par criptográfico (clave pública en el servidor, clave privada en el cliente). En esta guía práctica aprenderás a generar claves seguras (recomendando ed25519), instalar la clave pública en un servidor Ubuntu, ajustar permisos, comprobar la configuración efectiva de sshd, y desactivar la autenticación por contraseña de forma segura para evitar quedarte fuera.

Requisitos previos y precauciones

• Acceso local o consola al servidor (o al menos una sesión SSH alternativa abierta) en caso de error.
• Cuenta de usuario con permiso para conectarse por SSH y, si vas a modificar la configuración del servidor, acceso a sudo.
• Copia de seguridad de cualquier archivo /etc/ssh/sshd_config antes de editarlo.

Elegir el tipo de clave

Para la mayoría de casos actuales recomendamos ed25519 por seguridad, rendimiento y tamaño pequeño de clave. Sólo use RSA 4096 cuando necesites máxima compatibilidad con clientes antiguos que no soporten ed25519.

Los comandos de ejemplo usan ed25519; si optas por RSA sustituye -t ed25519 por -t rsa -b 4096. Para ajustar las rondas KDF en la clave privada se usa la opción -a de ssh-keygen, que incrementa la resistencia ante ataques por fuerza bruta en la frase de paso. (manpages.debian.org

Generar el par de claves en el cliente

Ejemplo recomendado (ed25519, con comentario y fichero explícito):

ssh-keygen -t ed25519 -a 100 -C "tu_email@dominio" -f ~/.ssh/id_ed25519

Explicación breve:

• -t ed25519: tipo de clave moderno y eficiente.
• -a 100: número de rondas del KDF (bcrypt_pbkdf) para endurecer la frase de paso.
• -C: comentario (útil para identificar la clave).
• -f: ruta del fichero de salida (evita sobrescribir otras claves).

Si no quieres frase de paso (no recomendado), presiona Enter al solicitarla; para uso con ssh-agent es preferible usar frase y agente.

Copiar la clave pública al servidor

Método práctico: ssh-copy-id

La forma más sencilla es usar ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@servidor

Esto añade la clave a ~/.ssh/authorized_keys del usuario remoto creando la carpeta si hace falta y preservando permisos en la mayoría de sistemas.

Método manual

ssh usuario@servidor 'mkdir -p ~/.ssh && chmod 700 ~/.ssh'
cat ~/.ssh/id_ed25519.pub | ssh usuario@servidor 'cat >> ~/.ssh/authorized_keys'
ssh usuario@servidor 'chmod 600 ~/.ssh/authorized_keys && chown $(whoami):$(whoami) ~/.ssh -R'

El método manual es útil si ssh-copy-id no está disponible o si necesitas añadir restricciones (por ejemplo, prefijar la clave con command="..." o opciones from="...").

Permisos y propietario correctos

sshd verifica modos y propietarios. Asegúrate en el servidor de que:

• ~/.ssh tiene permisos 700.
• ~/.ssh/authorized_keys tiene permisos 600.
• El propietario es el usuario correcto (chown user:user -R ~/.ssh si procede).

Si los permisos son demasiado laxos, la autenticación por clave pública puede rechazarse. El propio sshd comprueba estos modos para seguridad. (manpages.ubuntu.com

Configurar el servidor sshd

En Ubuntu la configuración principal está en /etc/ssh/sshd_config, y se permiten snippets en /etc/ssh/sshd_config.d/. Directivas relevantes:

• PubkeyAuthentication yes
• AuthorizedKeysFile .ssh/authorized_keys (ruta por defecto; comprueba que no se haya cambiado)
• PasswordAuthentication yes|no (para desactivar el login por contraseña)
• ChallengeResponseAuthentication no y UsePAM yes según tu entorno PAM

Tras editar crea un fichero de snippet en /etc/ssh/sshd_config.d/99-security.conf si prefieres no tocar el archivo principal. Después comprueba la configuración efectiva con sshd -T. (boycottsystemd.org

Caveat importante: archivos drop-in y cloud-init

En instalaciones de Ubuntu cloud images o sistemas inicializados por cloud-init, es habitual encontrar un fichero /etc/ssh/sshd_config.d/50-cloud-init.conf que puede establecer PasswordAuthentication yes u otras opciones; esos snippets pueden afectar la prioridad de las directivas. Antes de asumir que cambiar /etc/ssh/sshd_config es suficiente, revisa el contenido de /etc/ssh/sshd_config.d/ y edita o añade un snippet con prioridad superior (por ejemplo, nombre 99-*.conf) para forzar la opción deseada. Existe historial de casos donde 50-cloud-init.conf restaura o prevalece sobre cambios si cloud-init vuelve a ejecutarse. (askubuntu.com

Probar la conexión y verificar la configuración

Desde el cliente prueba con modo verbose para ver por qué clave se usa:

ssh -v usuario@servidor

En el servidor revisa la configuración efectiva y las opciones relacionadas:

sudo sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|authorizedkeysfile'
sudo journalctl -u ssh -e   # o /var/log/auth.log según sistema

El comando sshd -T imprime la configuración que sshd aplica realmente, lo cual ayuda a detectar overrides por snippets. (boycottsystemd.org

Desactivar la autenticación por contraseña — paso a paso y con seguridad

Advertencia: si desactivas PasswordAuthentication sin haber verificado el acceso por clave desde otro terminal y sin acceso físico/console, puedes perder acceso remoto. Mantén siempre al menos una sesión abierta o acceso de consola.

1. Desde un cliente diferente confirma que puedes acceder con la clave: ssh -i ~/.ssh/id_ed25519 usuario@servidor.
2. En el servidor crea un snippet: sudo nano /etc/ssh/sshd_config.d/99-disable-password.conf y añade:

   PasswordAuthentication no
   ChallengeResponseAuthentication no
   

3. Verifica la configuración efectiva: sudo sshd -T | grep -Ei 'passwordauthentication'.
4. Recarga/reinicia el servicio SSH (ver nota sobre unidades más abajo): sudo systemctl restart ssh.
5. Desde el cliente (en otra terminal) confirma que el acceso por clave funciona. Sólo una vez verificado cierra sesiones antiguas.

En Ubuntu la unidad de servicio gestionada suele ser ssh.service, por lo que systemctl restart ssh es el comando habitual; confirma en tu sistema si la unidad tiene otro nombre. Además, si cambias el puerto puede ser necesario recargar ssh.socket o ejecutar systemctl daemon-reload para que el socket note el cambio. (ubuntu.com

Opciones avanzadas

• ssh-agent y ssh-add para manejar frases de paso localmente.
• Claves hardware y tokens: ed25519-sk o rsa-sk para llaves ligadas a un FIDO2/USB security key.
• Expiración/rotación de claves: implementar políticas operativas (rotación periódica y control de authorized_keys).
• Match blocks en sshd_config para reglas por dirección, grupo o usuario: Match User ..., Address ....

Solución de problemas comunes

• Permission denied (publickey): comprueba permisos de ~/.ssh y authorized_keys, propietario y que la clave pública esté completa y en una línea.
• ssh no pide la clave correcta: usa ssh -v para ver qué claves prueba el cliente y si el servidor las acepta.
• Cambios en sshd_config no se aplican: revisa /etc/ssh/sshd_config.d/ por snippets que sobrescriban (por ejemplo 50-cloud-init.conf) y usa sshd -T para ver la configuración efectiva. (boycottsystemd.org
• Reinicio no funciona: confirma la unidad con systemctl status ssh y, si cambias puertos, ejecuta sudo systemctl daemon-reload; sudo systemctl restart ssh.socket si procede. (ubuntu.com

Checklist final antes de cerrar la sesión de administración

• Acceso por clave verificado desde otro terminal.
• Permisos y propietario de ~/.ssh y authorized_keys correctos.
• sshd -T muestra pubkeyauthentication yes y passwordauthentication no (si lo has desactivado).
• Copias de seguridad de archivos de configuración editados.

Si quieres practicar en local o en una VM antes de tocar servidores de producción, puede ser útil instalar y probar OpenSSH en una máquina de laboratorio. Para mantener el sistema y OpenSSH actualizados revisa las instrucciones de actualización de tu Ubuntu 24.04 antes de aplicar cambios de seguridad. Instalar OpenSSH en Linux: Guía Rápida y Efectiva y Actualizar Ubuntu 24.04 desde Terminal son recursos complementarios.

Preguntas frecuentes

• ¿Puedo usar la misma clave desde varios equipos? Sí: copia la misma clave pública al servidor desde los clientes que necesites. Alternativamente, genera claves diferentes por equipo y documenta su uso en el servidor.
• ¿Por qué sigue pidiendo contraseña después de añadir la clave? Revisa permisos, la ruta de AuthorizedKeysFile en la configuración efectiva (sshd -T) y posibles snippets en /etc/ssh/sshd_config.d/ que lo anulen.
• ¿Es seguro eliminar el acceso por contraseña? Sí, siempre que hayas comprobado que la autenticación por clave funciona desde otra sesión o tengas acceso físico/console al servidor.

Con esto tendrás un acceso SSH con claves públicas robusto y práctico en Ubuntu. Si quieres, puedo adaptar los comandos para Ubuntu 24.04 específicamente (rutas de sockets/servicios) o ayudarte a generar un script de despliegue para varios servidores.