Gestión de claves SSH: 7 buenas prácticas para 2026

El problema de las claves SSH

Las claves SSH son la columna vertebral del acceso a los servidores. Son más seguras que las contraseñas, sencillas de implementar y soportadas en todas partes. Pero a medida que su equipo crece, la complejidad de su gestión también lo hace.

La mayoría de los equipos empiezan con un puñado de claves, copiando manualmente las claves públicas en los servidores. En un año, tiene decenas de claves diseminadas entre portátiles, pipelines CI/CD y carpetas compartidas. Nadie sabe qué claves dan acceso a qué servidores. Cuando alguien se va, revocar el acceso consiste en conectarse a cada servidor individualmente.

7 buenas prácticas

1. Centralizar la gestión de claves

Deje de gestionar las claves en cada servidor. Utilice un sistema centralizado que sirva como fuente única de verdad sobre quién tiene acceso a qué. Es lo que hace posible la auditoría y la revocación instantánea.

2. Implementar una rotación de claves

Las claves SSH deben tener una fecha de expiración. Defina una política de rotación: 90 días es un buen punto de partida. La rotación automatizada elimina el síndrome del "ya lo haremos más tarde" que conduce a claves de varios años todavía válidas en producción.

3. Utilizar la autenticación por certificados

Los certificados SSH son superiores a las claves brutas en entorno de equipo. Incluyen metadatos (quién, qué, cuándo, dónde) y pueden estar acotados en el tiempo. Un certificado que expira en 8 horas es intrínsecamente más seguro que una clave que vive eternamente.

4. Imponer la autenticación multifactor

Las claves SSH por sí solas son una autenticación de un único factor. Combínelas con TOTP, WebAuthn o claves de seguridad hardware. Si una clave se ve comprometida, el segundo factor impide el acceso no autorizado.

5. Auditar cada conexión

Registre quién se conectó, cuándo, desde dónde y qué hizo. Sin registros de auditoría completos, no puede investigar incidentes, demostrar cumplimiento ni responder a la pregunta básica: "¿Quién accedió a producción esta noche?"

6. Aplicar el principio de mínimo privilegio

Los desarrolladores no necesitan acceso root en todos los servidores. Defina políticas de acceso por rol. Un desarrollador frontend necesita acceder al servidor de staging, no a la base de datos de producción.

7. Automatizar el offboarding

Cuando alguien se va, la revocación de acceso debe ser automatizada e instantánea. Los procesos de offboarding manuales son lentos, propensos a errores y constituyen un riesgo de seguridad.

Cómo ayuda SecurSSH

SecurSSH implementa estas buenas prácticas de forma nativa: gestión centralizada de credenciales SSH en una bóveda cifrada, registro de auditoría de dos años, RBAC de tres niveles y revocación instantánea por retirada de miembro. La firma de certificados SSH, la 2FA TOTP en la cuenta y la MFA de equipo obligatoria están en la hoja de ruta 2026. Implementación en 15 minutos.