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.
Índice de contenidos
¿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):
- 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».
- 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 "[email protected]"-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 [email protected](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».
- Lees tu clave pública (ojo, la que acaba en
.pub):
cat ~/.ssh/id_ed25519.pubCopias 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 [email protected]
mkdir -p ~/.ssh && chmod 700 ~/.sshchmod 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_keysBlindas el archivo:
chmod 600 ~/.ssh/authorized_keyschmod 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 [email protected]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(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.
Pro Tip 1: Evita bloquearte fuera del servidor
Antes de desactivar el acceso por contraseña o reiniciar el servicio SSH, hay una regla de oro: mantén abierta una segunda sesión activa hasta comprobar que puedes entrar con la nueva clave sin problemas.
El error clásico no es que falle un atacante. El error clásico es que falle el administrador y se deje fuera de su propio servidor.
Primero genera y copia la clave, después prueba el acceso en una terminal nueva y, solo cuando veas que funciona correctamente, desactiva la autenticación por contraseña y reinicia SSH.
En seguridad, bloquear ataques está bien. Bloquearte a ti mismo es bastante peor.
Pro Tip 2: No uses root directamente si puedes evitarlo
Aunque técnicamente puedas acceder por SSH como root, no suele ser la mejor idea. Lo más razonable es usar un usuario normal con permisos de sudo y reservar la cuenta root para casos excepcionales.
¿Por qué? Porque separar identidad administrativa y privilegios reduce errores, mejora trazabilidad y limita el impacto de un acceso indebido. Si alguien consigue entrar con una cuenta normal, todavía queda una barrera más. Si entra directamente como root, el problema escala mucho más rápido.
Usar claves SSH mejora mucho la seguridad, pero usar claves SSH con root directo sigue siendo peor que usar claves SSH con un usuario administrativo controlado.
Pro Tip 3: Si siempre administras desde el mismo sitio, no abras SSH al mundo
Una de las medidas más eficaces no está en sshd_config, sino en el firewall. Si administras tu VPS desde una IP fija o desde una red conocida, tiene mucho sentido permitir SSH solo desde ese origen.
Esto reduce de forma drástica la superficie de ataque, elimina gran parte del ruido automatizado y hace que el servicio deje de estar expuesto innecesariamente a Internet.
En otras palabras: cuanto menos tráfico reciba SSH, menos oportunidades tendrá un atacante de probar nada. Las claves SSH son una buena defensa. Filtrar el acceso antes de que llegue al puerto es todavía mejor.
Pro Tip 4: Esto es hardening básico, no el final del camino
Usar claves en lugar de contraseñas es una de las mejoras más importantes que puedes aplicar en SSH, pero no conviene confundir una mejora potente con un hardening completo.
Todavía quedan otras decisiones relevantes: limitar usuarios autorizados, revisar logs, reducir exposición, reforzar el firewall, controlar intentos fallidos o añadir capas como Fail2ban. La seguridad real no suele depender de una sola medida, sino de varias defensas razonables trabajando juntas.
La buena noticia es que este cambio ya te saca de la zona peligrosa. La mala es que la seguridad no termina cuando generas una clave y pegas un comando.
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».
