Claves SSH: gestión básica y revocación segura

Cómo funcionan las claves SSH

Una clave SSH es un par de archivos: una clave privada que permanece en su dispositivo y una clave pública que copia en cada servidor al que quiera conectarse. Cuando se conecta, el servidor usa la clave pública para enviar un desafío que sólo puede responder la clave privada correspondiente. La clave privada nunca sale de su dispositivo, por lo que ningún secreto viaja por la red y un servidor vulnerado no tiene nada útil que robar. Por eso las claves son más seguras que las contraseñas. Administrar correctamente las claves SSH se reduce a cuatro hábitos: una clave por dispositivo, los permisos de archivo que exige sshd, un archivo ~/.ssh/config para dejar de escribir opciones y saber cómo eliminar una clave el día que desaparece un portátil.

Esta guía cubre cada hábito en Ubuntu 24.04, aunque casi todo lo descrito aquí se aplica a cualquier servidor Linux y a cualquier versión reciente de OpenSSH.

Antes de empezar, conviene aclarar un término para evitar errores reales. La clave pública no es secreta. Puede pegarla en un ticket, enviarla por correo electrónico o publicarla, y nadie podrá iniciar sesión con ella. La clave privada es el secreto. Cualquiera que copie ese archivo y conozca su frase de contraseña, si tiene una, podrá actuar como usted frente a sus servidores.

Cree una clave: ed25519 es la opción predeterminada adecuada

Ejecute lo siguiente en su propio equipo, no en el servidor:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 selecciona el tipo de clave. Ed25519 es la opción predeterminada moderna: las claves son cortas, rápidas y compatibles con todas las versiones de OpenSSH publicadas desde 2014. Use ssh-keygen -t rsa -b 4096 sólo cuando deba conectarse a un dispositivo antiguo que no admita ed25519. -C "laptop" establece un comentario. El comentario no tiene ninguna función criptográfica, pero permite reconocer esta clave en el archivo authorized_keys de un servidor dentro de dos años. Indique el dispositivo donde reside la clave.

ssh-keygen solicita la ubicación donde se guardará la clave. Acepte el valor predeterminado, ~/.ssh/id_ed25519. A continuación, solicita una frase de contraseña. Establezca una. La sección siguiente explica por qué no le supondrá trabajo diario. Obtendrá dos archivos: ~/.ssh/id_ed25519 es la clave privada y ~/.ssh/id_ed25519.pub es la clave pública. Muestre la parte pública:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Es una sola línea: el tipo de clave, el material criptográfico y el comentario. Esa línea es la que se copia en los servidores.

Una clave por dispositivo, no una por servidor

La primera pregunta suele ser: ¿necesito una clave nueva para cada servidor? No. Cree una clave para cada dispositivo desde el que escriba y coloque esa clave pública en cada servidor al que el dispositivo deba acceder. La clave identifica al dispositivo. El archivo authorized_keys de cada servidor contiene la lista de dispositivos autorizados.

Este modelo escala correctamente. Las alternativas fallan de formas predecibles. Una clave por servidor significa que un portátil con veinte servidores tiene veinte claves privadas, y perderá el control de cuál corresponde a cada servidor. Compartir una clave entre todos sus dispositivos es peor: si roban el portátil, no puede revocar el acceso del portátil sin bloquear también el equipo de escritorio, porque ambos tienen la misma clave privada. Por tanto, debe reemplazar la clave en todas partes y distribuirla de nuevo a todos los dispositivos al mismo tiempo.

Con una clave por dispositivo, perder el portátil sólo le obliga a eliminar una línea por servidor: borre la línea del portátil de authorized_keys y los demás dispositivos seguirán funcionando. El comentario que establezca con -C facilita localizar esa línea.

La regla de este modelo es la siguiente: una clave privada se crea en un dispositivo y deja de utilizarse con ese dispositivo. Nunca copie una clave privada a una segunda máquina ni la cargue en un servidor. Cuando un dispositivo nuevo necesite acceso, genere una clave nueva en él.

Coloque la clave pública en el servidor

La opción sencilla es ssh-copy-id, que se incluye con OpenSSH:

ssh-copy-id matt@10.0.0.10

Inicia sesión con el método que todavía funcione, normalmente una contraseña, añade su clave pública a ~/.ssh/authorized_keys en el servidor y crea el directorio y el archivo con los permisos correctos si no existen. Pruébelo abriendo una nueva sesión SSH: el servidor debería permitirle el acceso sin solicitar la contraseña de la cuenta. Si su clave tiene una frase de contraseña, su propio equipo puede solicitarle esa frase; esa solicitud es local y no corresponde a la contraseña del servidor.

Cuando el inicio de sesión mediante contraseña ya está deshabilitado, ssh-copy-id no puede acceder, por lo que debe añadir la línea manualmente. Inicie sesión mediante una sesión que todavía funcione o mediante la consola web de su proveedor y ejecute esto en el servidor:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Pegue su clave pública real entre las comillas, la línea completa de id_ed25519.pub. authorized_keys contiene una clave pública por línea y constituye toda la base de datos de acceso: añadir un dispositivo consiste en añadir una línea y revocar un dispositivo consiste en eliminar una línea. En un servidor nuevo, este paso debe realizarse en los primeros 10 minutos en un VPS nuevo, justo antes de deshabilitar el inicio de sesión mediante contraseña.

Permisos que impiden el inicio de sesión con claves

Esta es la causa más común de los fallos del inicio de sesión con claves, y el cliente no muestra ningún error. sshd se ejecuta con StrictModes yes de forma predeterminada en Ubuntu 24.04, por lo que se niega a usar un archivo authorized_keys que otros usuarios puedan modificar. Si otros usuarios pueden escribir en el archivo, en el directorio ~/.ssh o en su directorio personal, sshd ignora la clave y vuelve a solicitar una contraseña sin explicar el motivo al cliente. (El OpenSSH de Ubuntu admite exactamente un caso excepcional: un archivo con permisos de escritura para el grupo privado del propio usuario, siempre que ningún otro usuario pertenezca a ese grupo. No dependa de este comportamiento; use los permisos indicados a continuación.) El motivo sólo aparece en el registro del servidor:

sudo grep 'Authentication refused' /var/log/auth.log

En una imagen mínima sin rsyslog no existe auth.log. La misma línea aparece en el journal: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

La solución consiste en cambiar dos permisos y comprobar el propietario. Ejecute los comandos en el servidor como el usuario afectado:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

La regla que debe recordar es: 700 en el directorio .ssh y 600 en todo su contenido. Los mismos valores se aplican en su propio equipo, porque el cliente también realiza estas comprobaciones. Si otros usuarios pueden leer una clave privada, ssh se niega a usarla, y esta vez el error se muestra claramente:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 lo corrige.

~/.ssh/config: deje de escribir opciones

Un archivo ~/.ssh/config en su propio equipo asigna un nombre corto a cada servidor y recuerda las opciones que escribe con frecuencia. Créelo con permisos 600 y añada un bloque Host por servidor:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Ahora ssh web1 sustituye a ssh -p 22 matt@10.0.0.10, y el mismo nombre corto funciona en scp, rsync y git, porque todos leen este archivo. HostName es la dirección real, User evita que tenga que escribir el nombre de la cuenta y IdentityFile fija la clave que se ofrecerá.

IdentitiesOnly yes merece una explicación, porque corrige un fallo confuso. Cuando el agente contiene varias claves, el cliente las ofrece una a una y el servidor cuenta cada oferta como un intento fallido. Si hay suficientes claves cargadas, recibe Received disconnect: Too many authentication failures antes de que se pruebe la clave correcta. IdentitiesOnly yes hace que el cliente ofrezca sólo la clave indicada en IdentityFile, por lo que el fallo no puede producirse.

Frases de contraseña y ssh-agent

Una frase de contraseña cifra el archivo de clave privada en el disco. Sin ella, cualquiera que copie el archivo puede usarlo de inmediato. Con ella, el archivo robado no sirve hasta que se adivina la frase de contraseña. Para una clave almacenada en un portátil, esa es exactamente la protección que necesita, porque los portátiles se roban y las copias de seguridad de los portátiles pueden filtrarse.

La razón por la que una frase de contraseña no supone un coste práctico es ssh-agent. El agente mantiene la clave descifrada en la memoria. Por tanto, escribe la frase de contraseña una vez por sesión de inicio de sesión y todas las conexiones posteriores son inmediatas. La mayoría de las distribuciones de Linux de escritorio y macOS ya ejecutan un agente. Cargue la clave en él con:

ssh-add ~/.ssh/id_ed25519

ssh-add -l muestra las claves que el agente mantiene actualmente. Tenga en cuenta lo siguiente: el reenvío del agente (ssh -A) permite que el servidor remoto use el agente para autenticarse en otro servidor mientras está conectado. Actívelo sólo hacia servidores en los que confíe plenamente y déjelo desactivado de forma predeterminada.

Rotación y revocación: procedimiento para un portátil perdido

Revocar una clave SSH normal consiste únicamente en eliminar su línea de authorized_keys en cada servidor que la tenga. No hay ninguna autoridad certificadora a la que avisar ni ninguna fecha de caducidad que esperar. En cuanto desaparece la línea, los nuevos inicios de sesión con esa clave fallan.

Ejecute ahora el procedimiento, mientras no sea una emergencia. Elija un servidor, abra ~/.ssh/authorized_keys y localice la clave mediante su comentario. Elimine la línea con un editor o filtre el comentario:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

A continuación, confirme desde el dispositivo cuya clave acaba de revocar que el inicio de sesión falla y, desde otro dispositivo, que el inicio de sesión sigue funcionando. Tenga en cuenta un detalle: eliminar una clave no cierra las sesiones que ya están abiertas, porque la clave sólo se comprueba durante el inicio de sesión. Si está revocando la clave de un dispositivo robado, compruebe también who en el servidor y cierre cualquier sesión que no reconozca.

La rotación es la misma operación en otro orden: genere una clave nueva en el dispositivo, instálela con ssh-copy-id, confirme que la nueva clave permite iniciar sesión y, después, elimine la línea antigua. Hágalo cuando un dispositivo cambie de propietario, cuando una clave pueda haber quedado expuesta o cuando alguien abandone un equipo. Hacerlo manualmente en dos servidores es aceptable; en veinte, es una tarea para automatización, y administrar varios servidores Linux muestra cómo distribuir el mismo estado de authorized_keys en toda una flota.

Qué no se debe hacer

• No comparta una misma clave privada entre todos sus dispositivos. Si uno de ellos es robado, no podrá revocarlo sin sustituir la clave en todas partes.

• No confirme una clave privada en un repositorio de git, ni siquiera en uno privado. Los analizadores automatizados supervisan los repositorios públicos e intentan usar las claves filtradas pocos minutos después de una subida. Además, si el repositorio se hace público más adelante, se filtra todo su historial.

• No suba la clave privada de su portátil a un servidor para que ese servidor pueda acceder a otro servidor. Genere una clave independiente en el propio servidor y autorícela exactamente donde sea necesaria.

• No pegue una clave privada en un chat, correo electrónico o ticket. La clave pública, el archivo .pub, es la única parte que se comparte.

Cuando la clave le permita iniciar sesión de forma fiable, desactive la autenticación mediante contraseña. Así, los intentos constantes de adivinar la contraseña de su servidor no podrán tener éxito. La configuración adicional para hacerlo se encuentra en Refuerzo de la seguridad de SSH en un VPS.

FAQ

¿Cómo funcionan las claves SSH sin enviar una contraseña?

El servidor guarda tu clave pública en ~/.ssh/authorized_keys. Durante el inicio de sesión, envía un desafío, tu cliente firma el desafío con la clave privada y el servidor verifica la firma con la clave pública. La clave privada nunca sale de tu dispositivo, por lo que no hay nada que interceptar durante el tránsito ni nada reutilizable que robar del servidor. Un servidor vulnerado sólo expone claves públicas, que no se pueden usar para iniciar sesión en ningún sitio.

¿Debo usar la misma clave SSH para todos mis servidores?

Usar una clave en muchos servidores es correcto, siempre que esa clave permanezca en un solo dispositivo. La regla es una clave por dispositivo, no una por servidor: la clave pública de tu portátil se instala en todos los servidores que necesite el portátil, y tu equipo de escritorio tiene su propia clave. Esto simplifica la revocación, porque perder un dispositivo implica eliminar una línea identificable de cada servidor, mientras los demás dispositivos siguen funcionando.

¿Qué permisos deben tener el directorio .ssh y authorized_keys?

Establece 700 en ~/.ssh y 600 en authorized_keys y en cada clave privada. Todos deben pertenecer a la cuenta que los utiliza. sshd se ejecuta con StrictModes yes de forma predeterminada, por lo que un archivo o directorio personal que pueda modificar cualquier persona que no seas tú hace que ignore la clave silenciosamente. El único rastro es Authentication refused: bad ownership or modes en el registro de autenticación o el journal del servidor.

¿Cómo elimino una clave SSH de un servidor?

Elimina la línea de la clave de ~/.ssh/authorized_keys en la cuenta para la que estaba autorizada. Identifica la línea correcta mediante su comentario, que es la etiqueta situada después del material de la clave. Los nuevos inicios de sesión con esa clave fallan inmediatamente, pero las sesiones ya abiertas permanecen activas. Si el dispositivo fue robado, finaliza también cualquier sesión activa de ese dispositivo. Repite el procedimiento en todos los servidores donde se copió la clave.

¿Necesito una frase de contraseña para mi clave SSH?

Para una clave almacenada en un portátil o equipo de escritorio, sí. La frase de contraseña cifra el archivo de la clave, por lo que una copia robada o filtrada no sirve por sí sola. Además, ssh-agent permite introducirla una vez por sesión en lugar de hacerlo en cada conexión. Las claves utilizadas por procesos de automatización desatendidos en un servidor normalmente no tienen frase de contraseña, porque no hay ninguna persona que pueda introducirla. Protégelas limitando las acciones que puede realizar la cuenta de destino.