Proteja el acceso SSH a su VPS y conserve una vía de recuperación
SSH suele ser la puerta de entrada a un VPS Linux. Una política de acceso útil protege esa puerta y a la vez mantiene una vía probada para volver a entrar. La secuencia de cambios más segura demuestra que el reemplazo funciona antes de retirar el método de acceso existente.
La conclusión práctica
Verifique la identidad del servidor, use cuentas individuales y claves protegidas, pruebe cada cambio de configuración en una segunda sesión y mantenga un procedimiento de recuperación controlado por separado.
Empiece por un inventario de accesos y una ruta de recuperación
Antes de editar SSH, enumere todas las vías legítimas de entrada al servidor: cuentas de administrador, tareas de despliegue, clientes de copia de seguridad, agentes de monitorización y cualquier mantenedor externo. Anote qué identidad usa cada una y si necesita un shell, transferencia de archivos o una acción automatizada restringida. Una clave de despliegue olvidada puede seguir siendo útil para alguien mucho después de que una persona deje el proyecto.
Confirme cómo se recuperaría el acceso si fallara una regla de firewall o un cambio de autenticación. Una consola del proveedor o un entorno de recuperación pueden ser relevantes, pero no dé por hecho que una instalación concreta esté incluida o ya configurada. Pida al equipo que confirme la ruta disponible y quién está autorizado a usarla. Guarde el procedimiento en un lugar privado que siga siendo accesible cuando este VPS no esté disponible.
Mantenga abierta la sesión SSH actual que funciona mientras realiza un cambio planificado. Use otra terminal para las pruebas de conexión nuevas. Que una sesión existente siga funcionando demuestra poco sobre si una conexión nueva puede autenticarse, así que cerrar la primera terminal es el paso final, no la prueba en sí.
Verifique el host y luego establezca identidades individuales
La clave de host del servidor identifica la máquina; su clave de usuario le autentica ante ella. Compare la huella de la clave de host con un valor obtenido por un canal de confianza independiente antes de aceptar una primera conexión. Si cambia una huella conocida previamente, determine si lo explica una reconstrucción o una rotación de claves planificada. Eliminar la huella guardada solo para quitar la advertencia omite esa comprobación de identidad.
Asigne a cada administrador una cuenta con nombre y una clave SSH individual. Proteja la clave privada en el dispositivo del administrador, preferiblemente con una frase de contraseña y un agente local adecuado o un proceso de inicio de sesión que use una clave de seguridad física. Instale solo la clave pública en el servidor. Compruebe el propietario y los permisos del directorio personal de la cuenta, del directorio SSH y del archivo de claves autorizadas usando la documentación del sistema operativo instalado.
Para un proyecto de dos personas, registre qué clave pertenece a cada persona y cuándo se autorizó. Pruebe una conexión nueva como ese usuario con nombre y verifique por separado la elevación administrativa prevista. Compartir una única clave privada o un inicio de sesión root habitual dificulta innecesariamente las salidas, las investigaciones y la revocación selectiva.
Cambie la autenticación en una secuencia que pueda verificar
| Control | Decisión que tomar | Evidencia antes de endurecer |
|---|---|---|
| Autenticación con clave pública | ¿Qué cuentas con nombre y claves se aceptan? | Un inicio de sesión nuevo basado en clave para cada administrador requerido |
| Autenticación con contraseña | ¿Sigue siendo necesaria para un flujo de trabajo aprobado? | Se han probado tanto el acceso de sustitución como la recuperación |
| Autenticación interactiva por teclado | ¿Depende de ella alguna política de MFA o PAM? | La secuencia de autenticación completa prevista se completa correctamente |
| Acceso directo como root | ¿Puede la administración diaria usar cuentas con nombre? | La ruta de elevación requerida funciona desde una sesión nueva |
Trate PasswordAuthentication y KbdInteractiveAuthentication como decisiones separadas. Desactivar solo la autenticación con contraseña no describe todas las vías de autenticación interactiva, mientras que desactivar sin criterio el acceso interactivo por teclado puede romper una configuración de MFA prevista. Lea la política efectiva de su versión de OpenSSH instalada y pruebe todo el recorrido de inicio de sesión, incluido cualquier segundo factor.
La configuración de OpenSSH puede incluir archivos adicionales y secciones Match condicionales. Una línea añadida al final no necesariamente anula un valor aplicable anterior. Valide la sintaxis antes de aplicar un cambio; en el flujo de trabajo documentado de Ubuntu, sudo sshd -t realiza esa comprobación. Inspeccione la configuración efectiva para el contexto de conexión correspondiente y siga las instrucciones de gestión de servicios del sistema operativo. La validación de sintaxis no demuestra la accesibilidad de red ni una autenticación correcta.
Limite la exposición sin confundir la ocultación con la protección
Si los administradores se conectan desde redes predecibles, considere restringir el punto de entrada administrativo a esas redes o a una ruta de acceso privada gestionada adecuadamente. Tenga en cuenta al personal que viaja, las direcciones residenciales cambiantes y los clientes automatizados antes de aplicar una restricción. Compruebe la regla desde una conexión genuinamente nueva y mantenga la ruta de recuperación acordada durante todo el cambio.
Cambiar el puerto SSH puede reducir el ruido del escaneo en segundo plano, pero no sustituye una autenticación sólida ni las actualizaciones oportunas. Evite el reenvío innecesario y el reenvío de agente en las sesiones diarias. Una tarea de despliegue que solo transfiere archivos no debería heredar automáticamente las mismas capacidades que un administrador humano. Limite cada identidad de automatización a la tarea que su propietario pueda explicar.
Mantenga OpenSSH y el sistema operativo mediante su proceso de actualización compatible. Revise los fallos de autenticación junto con los inicios de sesión correctos, las redes de origen y el mantenimiento planificado. Un gran número de intentos públicos fallidos es motivo para evaluar la exposición; no es prueba de que se haya accedido correctamente a una cuenta concreta.
Termine con una revisión de accesos repetible
- Una nueva sesión verifica la huella del host esperada y se autentica con la identidad prevista.
- Cada administrador puede realizar el trabajo aprobado utilizando el método de elevación requerido.
- Las tareas de despliegue y copia de seguridad siguen teniendo éxito con sus propias identidades restringidas.
- El método de acceso anterior se elimina solo después de que la sustitución y las comprobaciones de recuperación hayan pasado.
- Cuando una persona se marcha, se revisan con prontitud el acceso a su cuenta y sus claves individuales.
Repita la revisión tras añadir un mantenedor, reconstruir un servidor o cambiar su política de autenticación. Guarde el inventario de accesos aprobados sin copiar claves privadas en notas de proyecto ni en tickets de soporte. Cuando solicite ayuda, facilite la referencia del servidor, el sistema operativo, la hora aproximada del fallo y el error exacto no secreto. Una descripción clara del fallo es más útil que compartir el control de una credencial de administrador.
