Registros de autenticación de un nuevo VPS: 200 intentos root/admin123 en cuatro horas: robots, no objetivos personales. El servidor se cae no debido al SSH de día cero, sino porque PasswordAuthentication sí todavía estaba pendiente después de la instalación. Cuatro hábitos habrían cerrado el 95% de esta superficie.
SSH es la puerta de administración de su VPS. En un proyecto pequeño, suele ser el único. Asegurarlo no requiere un centro de seguridad: requiere disciplina básica.
Los análisis automáticos apuntan al puerto global 22 en todo momento. La buena noticia: están buscando valores predeterminados: contraseñas de root, claves débiles, servicios obsoletos. Cuatro hábitos bien aplicados reducen drásticamente la superficie sin herramientas exóticas. Combínelos con firewall VPS y actualizaciones periódicas.
Hábito 1: solo autenticación de clave
Genere una clave Ed25519 localmente, implemente la clave pública en ~/.ssh/authorized_keys para un usuario dedicado. En /etc/ssh/sshd_config, establezca PasswordAuthentication no, PubkeyAuthentication sí, PermitRootLogin no. Pruebe una nueva sesión antes de cerrar la anterior, luego vuelva a cargar sshd.
Una clave sin contraseña en una computadora portátil robada = clave maestra. Frase de contraseña o token de hardware para producción.
Hábito 2: usuario no root más sudo
Cree deploy o admin en el grupo sudo. Prohibido el root directo; operaciones a través de sudo registradas. Deshabilite las cuentas de demostración de imágenes en la nube.
Hábito 3: fail2ban (o equivalente)
Prisión sshd: prohíbe la dirección IP después de N fallas. Emparejar con firewall restrictivo. Lista blanca de IP de Office si se soluciona. No confíe únicamente en cambiar el puerto 22: los escaneos cubren todo el rango.
Hábito 4: actualización y superficie mínima
Correcciones de seguridad automáticas ("actualizaciones desatendidas"). Desinstale los servicios innecesarios que están escuchando. MaxAuthTries 3, AllowUsers implementado si es un equipo pequeño.
Acceso al bastión y al equipo
Multiservidor: un bastión SSH (dirección IP restringida) o WireGuard VPN; La producción no expone SSH público si es posible. Diferentes claves de puesta en escena/producción. Revocar claves de salida de empleados: secretos de implementación incluye claves CI SSH.
| Malo | Mejor |
|---|---|
| raíz + contraseña | usuario + tecla + sudo |
| misma clave en todas partes | claves por entorno |
| Mundo SSH 0.0.0.0/0 | Cortafuegos de administración de IP |
Más allá de SSH: no olvides la aplicación
Reforzar SSH no sustituye a parchear WordPress, cerrar phpMyAdmin expuesto o eliminar .env del repositorio; consulte secretos de implementación. Muchos pequeños compromisos de VPS se producen a través de la fuga de aplicaciones o credenciales después de un endurecimiento SSH exitoso. Los cuatro hábitos siguen siendo necesarios; no son suficientes por sí solos.
Lo mejor: SSH reforzado no protege la aplicación
Decide y avanza sin puntos ciegos
Genere la clave Ed25519 con frase de contraseña. Cree un usuario sudo y pruebe el inicio de sesión clave. Deshabilite la autenticación de contraseña y el inicio de sesión raíz SSH. Habilite fail2ban y firewall que restringen el puerto 22. Documente el acceso a la consola alternativa. Compare los hosts con el rescate de la consola a través del directorio.
Preguntas frecuentes
¿Clave RSA o Ed25519?
Se recomienda Ed25519 para un VPS nuevo: clave corta, moderna y rápida de implementar. RSA 4096 sigue siendo aceptable si necesita admitir un entorno más antiguo. En una computadora portátil, proteja la clave privada con una frase de contraseña o un agente SSH bloqueado al cerrar sesión.
¿Desactivar SSH raíz por completo?
Sí, una vez que se crea y prueba un usuario sudo desde una nueva sesión paralela. Mantenga accesible la consola del host (KVM o serie): un error en sshd_config puede excluirlo antes de la siguiente implementación. Pruebe el inicio de sesión con clave antes de cerrar la sesión raíz.
¿es suficiente fail2ban?
No solo. fail2ban complementa la desactivación de claves y contraseñas al prohibir direcciones IP después de repetidos fallos. Establezca la duración de la prohibición y incluya en la lista blanca la dirección IP fija de la oficina si tiene una; de lo contrario, corre el riesgo de ser bloqueado después de sus propias pruebas.
SSH en varios servidores: ¿cómo organizarse?
Utilice claves separadas por entorno (ensayo, producción), un bloque Host en ~/.ssh/config por servidor y un bastión o WireGuard VPN para producción. Restrinja el puerto 22 a través del firewall VPS a direcciones de administrador autorizadas; Revocar las llaves cuando un empleado se marcha.
SSH seguro: cuatro hábitos obvios (claves, no contraseña de root, sudo, fail2ban) que muchos VPS aplican solo después del primer análisis exitoso.