Protege el acceso SSH de tus servidores con SoloKey

El acceso SSH es una de las puertas más sensibles de cualquier servidor. Da igual que hablemos de un VPS pequeño, de una máquina interna o de un servidor crítico: si alguien consigue autenticarse por SSH con privilegios suficientes, el servidor deja de ser tuyo.

Aquí es donde entran en juego las llaves de seguridad hardware como SoloKey (u otras parecidas). En lugar de depender únicamente de un fichero privado almacenado en nuestro equipo, podemos utilizar una llave física compatible con FIDO2 para que la autenticación SSH requiera un dispositivo real.

En este artículo vamos a ver qué es SoloKey, qué papel tiene FIDO2 en todo este proceso y cómo podemos configurar un servidor GNU/Linux para acceder por SSH usando una llave FIDO2 como método principal. Además, prepararemos una segunda llave SSH de emergencia, guardada offline, para evitar quedarnos fuera de nuestros servidores si perdemos la SoloKey o deja de funcionar.

Qué es SoloKey

SoloKey es una llave de seguridad hardware compatible con FIDO2 y U2F. Su función es actuar como un autenticador físico: un pequeño dispositivo USB o NFC capaz de generar y proteger material criptográfico, y de participar en procesos de autenticación sin exponer la clave privada al sistema desde el que nos conectamos.

La diferencia respecto a una clave SSH tradicional es que cuando generamos una clave SSH normal, por ejemplo una ed25519, se crea un fichero privado en nuestro equipo. Ese fichero puede estar protegido con passphrase, puede tener buenos permisos y puede guardarse con cuidado, pero sigue siendo un fichero. Si alguien lo copia y conoce la passphrase, puede usarlo desde otro sistema.

Con una clave SSH respaldada por una llave FIDO2, el modelo cambia. OpenSSH no guarda una clave privada completa y reutilizable como en una clave tradicional, sino una referencia asociada al autenticador hardware. Cuando intentamos iniciar sesión, el servidor envía un desafío criptográfico, el cliente SSH solicita a la SoloKey que firme ese desafío y la SoloKey solo lo hace si está presente y, normalmente, si el usuario confirma físicamente la operación tocando el dispositivo. La clave privada real no sale del autenticador.

SoloKeys define Solo 2 como una llave FIDO2 open source orientada a proteger frente a phishing y toma de control de cuentas. La compatibilidad concreta depende del modelo, del firmware y del cliente que utilicemos, pero el concepto central es el mismo: trasladar una parte crítica de la autenticación a un dispositivo físico separado del ordenador.

Creación de claves SSH

Para esta configuración crearemos dos llaves SSH que se usarán en diferentes escenarios:

• Clave SSH con SoloKey: Esta llave SSH la usaremos para conectarnos a nuestros servidores. Para conectarnos será necesario que SoloKey esté conectada a nuestro ordenador o leer con nuestro móvil el NFC de la llave. Será la clave que usaremos de costumbre
• Clave de Emergencia: Esta clave SSH la tendremos configurada en el servidor para poder seguir accediendo en caso de que perdamos la SoloKey o se estropee. Por lo que esta clave SSH no la usaremos de costumbre, la tendremos guardada en un lugar seguro (algún disco cifrado o Gestor de Contraseñas).

Crear la clave SSH principal con SoloKey

Para generar una clave SSH respaldada por una SoloKey, tendremos que conectar la SOloKey por USB a nuestro ordenador y genera la clave.

ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk_solokey

Durante el proceso, ssh-keygen pedirá interacción con la llave. Dependiendo del modelo y del sistema, puede solicitar que toquemos la SoloKey para confirmar la operación. Al terminar, tendremos dos ficheros: una parte privada en ~/.ssh/id_ed25519_sk_solokey y una parte pública en ~/.ssh/id_ed25519_sk_solokey.pub.

Crear una clave SSH de emergencia

Aunque la SoloKey sea el método principal, no es buena idea depender de un único dispositivo físico. Una llave se puede perder, romper o quedar temporalmente inutilizable.

Para la clave SSH de emergencia crearemos una del tipo ed25519 traducional y la protegeremos con una passphrase fuerte.

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_emergency

La opción -a 100 aumenta el número de rondas usadas por la función de derivación de clave al proteger la clave privada con passphrase. Por lo que deberemos de guardarla en un lugar seguro (a poder ser un lugar cifrado).

Copiar las claves al servidor

Una vez creadas las dos claves, debemos añadir sus claves públicas al usuario root del servidor. Si todavía tenemos acceso por contraseña o por otra clave temporal, podemos usar ssh-copy-id.

Para copiar la clave principal de SoloKey:

ssh-copy-id -i ~/.ssh/id_ed25519_sk_solokey.pub root@IP_DEL_SERVIDOR

Para copiar la clave de emergencia:

ssh-copy-id -i ~/.ssh/id_ed25519_emergency.pub root@IP_DEL_SERVIDOR

El fichero /root/.ssh/authorized_keys debería contener una línea por cada clave pública autorizada. La clave de SoloKey empezará por sk-ssh-ed25519@openssh.com y la clave de emergencia por ssh-ed25519.

Configurar OpenSSH en el servidor

La configuración principal del servidor está en /etc/ssh/sshd_config y deberemos de configurar las siguientes directivas:

PermitRootLogin prohibit-password

PasswordAuthentication no
KbdInteractiveAuthentication no

PubkeyAuthentication yes
AuthenticationMethods publickey

PubkeyAcceptedAlgorithms sk-ssh-ed25519@openssh.com,ssh-ed25519

PubkeyAuthOptions touch-required

UsePAM yes

X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no

MaxAuthTries 3
LoginGraceTime 30

LogLevel INFO

Esta configuración permite acceso como root únicamente mediante claves SSH, desactivando completamente contraseñas y autenticación interactiva. OpenSSH aceptará tanto la clave FIDO2 respaldada por la SoloKey como una segunda llave ed25519 tradicional usada como método de emergencia.

La opción PubkeyAuthOptions touch-required obliga a confirmar físicamente cada autenticación FIDO2 tocando la llave hardware, mientras que UsePAM yes mantiene la integración moderna del sistema para gestión de sesiones y límites sin reactivar el login por contraseña.

Además, se desactivan funciones innecesarias como X11 forwarding, túneles SSH y agent forwarding para reducir superficie de ataque. Finalmente, opciones como MaxAuthTries 3, LoginGraceTime 30 y LogLevel INFO endurecen el acceso SSH y mejoran la auditoría sin generar el exceso de logs.

Antes de reiniciar SSH, es obligatorio validar la sintaxis:

sshd -t

Después, reiniciamos el servicio. En muchas distribuciones basta con:

systemctl restart ssh

No cierres la sesión actual todavía. Abre una segunda terminal y prueba una conexión nueva:

ssh -i ~/.ssh/id_ed25519_sk_solokey root@IP_DEL_SERVIDOR

Si todo está bien, OpenSSH pedirá interacción con la SoloKey. Una vez validado el acceso principal, prueba también la llave de emergencia desde el entorno autorizado:

ssh -i ~/.ssh/id_ed25519_emergency root@IP_DEL_SERVIDOR

Solo cuando ambas pruebas funcionen deberías cerrar la sesión antigua.

Conclusión

Usar SoloKey con OpenSSH permite llevar la autenticación SSH a un modelo mucho más resistente que el basado en contraseñas o claves privadas tradicionales. La clave deja de ser simplemente un fichero que puede copiarse y pasa a depender de un autenticador físico que debe participar en cada operación. Si además exigimos presencia física con touch-required, cada conexión requiere una confirmación real por parte del administrador.

Combinado con una VPN, reglas de firewall, acceso restringido como root mediante prohibit-password, una llave de emergencia offline y una configuración SSH sin funciones innecesarias, el resultado es una configuración limpia, cómoda y muy sólida para administrar servidores GNU/Linux. No se trata de añadir seguridad a costa de hacer imposible el trabajo diario, sino de diseñar un acceso que sea práctico para el administrador y difícil de abusar para cualquiera que no tenga la llave física, la red adecuada y la autorización correcta.

Más sobre ./voidNull

• 📖 Aprende todos sobre los comandos de GNU/Linux en nuestro Diccionario "De la A a la Z: Los comandos de GNU/Linux"
• 💪 ¡Forma parte de la Comunidad de ./voidNull!
• 🤖 Disfruta de todos nuestros Cursos sobre Ansible, Proxmox, Home Assistant entre otros.
• 📩 Mantente actualizado con lo último en GNU/Linux y Software Libre. Recibe nuestra Newsletter mensual.