Hardening básico del puerto SSH con SSH Keys

Seamos sinceros. Si sigues entrando a tu servidor web tecleando una contraseña cada vez, estás jugando a la ruleta rusa con una pistola automática.

Dejar un servidor expuesto a Internet solo con protección de usuario y contraseña es como cerrar la puerta de tu casa con un trozo de celo: psicológicamente te sientes seguro, pero cualquiera con un poco de tiempo y malas intenciones va a entrar hasta la cocina.

Hoy vamos a hablar de SSH (Secure Shell) y de cómo endurecerlo (hardening) usando criptografía asimétrica (asymmetric cryptography). O dicho en cristiano: vamos a crear un par de llaves para que entres como un VIP y los demás se queden en la puerta.

¿Por qué las contraseñas apestan?

El problema de las contraseñas no es solo que tengas la mala costumbre de usar la misma para tu correo, tu banco y tu servidor (que nos conocemos). El problema son los ataques de fuerza bruta (brute-force attacks).

Hay miles de bots escaneando Internet 24/7 buscando servidores con el puerto 22 abierto. Si usas contraseña, eventualmente pueden adivinarla. Si usas claves SSH (SSH keys), la cosa cambia.

Para romper una clave SSH moderna, un atacante necesitaría más tiempo del que le queda de vida al universo. Así que sí, es bastante más seguro.

El concepto: La llave y el candado

Esto funciona con un par de claves (key pair):

1. Clave Pública (Public Key): Es como un candado abierto. La puedes copiar en todos los servidores que quieras. Le dices al servidor: «Oye, pon este candado en mi puerta».
2. Clave Privada (Private Key): Es la llave que abre ese candado. Esta NUNCA sale de tu ordenador. Si la pierdes, despídete del acceso. Si te la roban, estás vendido.

Manos a la obra: Tutorial paso a paso

Usaremos ed25519 (nada de RSA viejuno). Ed25519 es un sistema moderno de firma digital de clave pública (criptografía asimétrica) basado en curvas elípticas. Es actualmente considerado el «estándar de oro» por su equilibrio entre rendimiento y seguridad.

Paso 1: Generar la joya de la corona

Lo primero es crear el par de claves en tu ordenador local (tu PC, Mac o WSL). Abre tu terminal y escribe:

ssh-keygen -t ed25519 -C "tu_email@example.com"

ssh-keygen -t ed25519 -C "tu_email@example.com"

• -t ed25519: Estamos eligiendo el algoritmo Edwards-curve Digital Signature Algorithm. Es más rápido y seguro que el clásico RSA.
• -C: Es solo un comentario para que sepas de quién es la clave (útil cuando administras veinte servidores).

Te preguntará dónde guardarla (dale a Enter para dejar la ruta por defecto) y si quieres una frase de paso (passphrase).

Consejo de amigo: Ponle passphrase. Si alguien te roba el portátil y la clave no tiene contraseña, entra a tus servidores sin llamar. Con passphrase, al menos tienen que sudar un poco más.

Paso 2: Copiar la «cerradura» al servidor

Ahora tienes que decirle a tu servidor: «Eh, confía en esta llave». Tienes dos formas de hacerlo, la fácil y la de «soy un hacker de los 90».

La forma fácil (si tienes ssh-copy-id)

ssh-copy-id root@nombredetuserver.com

ssh-copy-id root@nombredetuserver.com

(Sustituye root y el dominio por los tuyos, obviamente). Te pedirá la contraseña del servidor una última vez. Y listo.

La forma manual (si la fácil falla): A veces el comando anterior no está o el servidor se pone tonto. Aquí es donde entra el «método artesanal».

1. Lees tu clave pública (ojo, la que acaba en .pub):

cat ~/.ssh/id_ed25519.pub

cat ~/.ssh/id_ed25519.pub

Copias ese chorro de texto que empieza por ssh-ed25519.

Entras al servidor (a la antigua, con contraseña) y creas la carpeta si no existe:

ssh root@nombredetuserver.com
mkdir -p ~/.ssh && chmod 700 ~/.ssh

ssh root@nombredetuserver.com
mkdir -p ~/.ssh && chmod 700 ~/.ssh

• chmod 700: Esto es vital. Le dice al sistema «solo el dueño puede mirar aquí». Si los permisos son muy abiertos, SSH te rechazará la llave por inseguro.

Pegas la clave en el archivo de llaves autorizadas:

echo "pega_aquí_la_clave_pública" >> ~/.ssh/authorized_keys

echo "pega_aquí_la_clave_pública" >> ~/.ssh/authorized_keys

Blindas el archivo:

chmod 600 ~/.ssh/authorized_keys

chmod 600 ~/.ssh/authorized_keys

chmod 600: Significa «solo yo puedo leer y escribir este archivo». Nadie más.

Paso 3: La prueba de fuego

Sal del servidor con exit y vuelve a intentar entrar:

ssh root@nombredetuserver.com

ssh root@nombredetuserver.com

Si todo ha ido bien, entrarás directamente (o te pedirá la passphrase de la llave si la pusiste). ¡Sin contraseña del servidor! Magia.

El paso final: Cerrar la puerta trasera

Ahora que ya tienes llave VIP, es hora de que deshabilites la entrada con contraseña para que nadie más pueda intentar colarse.

Edita el archivo de configuración del demonio SSH (/etc/ssh/sshd_config) y busca/cambia estas líneas:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password

(Nota: Si puedes, evita loguearte como root directamente y usa un usuario con sudo, es una mejor práctica de Mínimo Privilegio (Least Privilege)).

Reinicia el servicio SSH (sudo service ssh restart o systemctl restart sshd) y listo. Ahora, quien intente entrar sin tu llave privada recibirá un portazo digital en la cara.

Checklist de supervivencia (Buenas Prácticas)

Para que duermas como un bebé:

• Protege tu clave privada: Es el anillo único. No se comparte, no se envía por email.
• Usa Fail2Ban: Una herramienta que banea automáticamente las IPs que intentan hacerse las listas demasiadas veces.
• Cambia el puerto 22: Mover SSH al puerto 2222 (por ejemplo) reduce el ruido de los logs, aunque no es una medida de seguridad real (es seguridad por oscuridad / security through obscurity), ayuda a limpiar la basura.

Conclusión

Configurar llaves SSH es el paso cero en la seguridad de cualquier servidor. Te lleva 5 minutos y te ahorra el dolor de cabeza de ver cómo un script kiddie de 14 años te ha borrado la base de datos porque tu contraseña era «madrid2024».