Todavía hay una antigua clave de administración en la carpeta del proyecto. Funciona en varios servidores, pero nadie sabe exactamente quién conserva una copia. El paso de contraseñas a claves SSH ha cambiado la autenticación sin aclarar la responsabilidad.
Una gestión SSH útil combina identidades individuales, permisos adecuados en los destinos y revocación fiable. Según el entorno, pueden bastar claves públicas mantenidas con un inventario preciso. Los entornos más grandes o que cambian con frecuencia pueden beneficiarse de certificados SSH de corta duración. Ambos enfoques necesitan una operación sostenible.
Cuatro elementos que no deben confundirse
La clave privada del usuario permite demostrar la propia identidad. Se conserva protegida y no se distribuye por chat, correo o carpetas de proyecto sin protección. La correspondiente clave pública puede registrarse en los sistemas previstos para autorizar el acceso. Su huella facilita la identificación inequívoca en el inventario.
La clave del servidor identifica, en cambio, al servidor contactado. La verificación del host impide que una conexión llegue inadvertidamente a un interlocutor equivocado. Un certificado SSH añade a una clave pública una declaración firmada, por ejemplo sobre identidad y validez. Los certificados OpenSSH utilizan un formato propio y no son certificados TLS/X.509 convencionales.
Separar los inicios de sesión personales de las tareas técnicas
El trabajo administrativo se asigna a personas y tareas autorizadas. Una clave root compartida y de larga duración complica innecesariamente las bajas, la rotación y la trazabilidad. Los accesos individuales con privilegios administrativos regulados ofrecen una base mejor.
Una tarea de copia de seguridad o despliegue necesita su propia identidad técnica con responsabilidad documentada. Siempre que sea posible, su acceso se limita a la función prevista, por ejemplo mediante un comando forzado y reglas de reenvío adecuadas. La clave privada de un empleado no debe convertirse silenciosamente en un requisito permanente de una tarea automática.
Del inventario de claves a los certificados de corta duración
Con pocos sistemas puede bastar una distribución controlada de claves públicas. El inventario registra persona o servicio, huella, sistemas de destino, alcance y fecha prevista de revisión o sustitución. Lo decisivo es mantener de forma fiable los permisos en todos los destinos afectados.
Una autoridad de certificación SSH puede, en cambio, firmar claves públicas para un periodo limitado e identidades definidas. Los servidores confían en la CA designada y comprueban sus demás reglas. No es necesario enviar a la CA la clave privada de acceso. Las claves de la CA y sus reglas de emisión se protegen especialmente.
Una validez corta reduce el tiempo de uso de una credencial emitida. No termina una sesión ya abierta ni sustituye el proceso de revocación. Tras una baja también debe impedirse la emisión de nuevos certificados. Una plataforma central de secretos es una posible forma de operación; debe admitir realmente el flujo SSH previsto.
| Forma de gestión | Uso adecuado | Requisitos operativos |
|---|---|---|
| Mantener claves públicas | Un conjunto de destinos acotado y bien inventariado. | Distribución, retirada de permisos antiguos y sustitución de responsables ausentes. |
| Emitir certificados SSH | Validez limitada e identidades definidas. | Protección de la CA, reglas de emisión, confianza del servidor y revocación. |
| Identidades técnicas | Automatización con una tarea clara. | Permisos limitados en destinos, responsabilidad y procedimiento de rotación. |
| Agente o clave de hardware | Métodos adecuados de autenticación personal. | Límites de reenvío, revisión de versiones y recuperación. |
Utilizar agentes y claves de hardware con criterio
Un agente SSH permite autenticarse con las claves cargadas sin copiar el archivo de clave privada a cada servidor. Reenviar el agente, sin embargo, concede a un sistema remoto acceso a sus capacidades de firma. OpenSSH advierte expresamente que un atacante con suficiente acceso a ese sistema puede autenticarse con las identidades cargadas sin extraer el material de las claves.
El reenvío del agente se configura por ello solo para el recorrido necesario. Las restricciones de tiempo o destino admitidas pueden añadir límites. Las llaves de seguridad físicas son otra opción para accesos interactivos adecuados. Cliente, servidor, tipo de clave y requisitos de contacto o PIN deben ser compatibles; una tarea desatendida tiene necesidades diferentes de un acceso personal.
La rotación y la revocación deben llegar al destino
Cambiar una clave en el portátil no elimina el acceso antiguo del servidor. Con claves públicas registradas, hay que actualizar los permisos en todos los destinos afectados. Los certificados pueden incorporar mecanismos como las listas de revocación de OpenSSH. La revocación solo es efectiva cuando los servidores previstos la aplican correctamente.
El procedimiento contempla también un dispositivo perdido, una clave comprometida y un servicio de gestión no disponible. Un acceso de emergencia independiente se protege, documenta y prueba de forma controlada. La recuperación no debe depender precisamente de la vía de acceso que ha fallado.
Diferenciar los entornos Linux y Proxmox
En entornos heterogéneos se registran las versiones y funciones OpenSSH realmente admitidas. Un manual actual no garantiza que todas las instalaciones Linux tengan las mismas opciones. Las nuevas reglas se introducen con un acceso de prueba designado y una vía de retorno comprobada.
Proxmox VE también utiliza SSH para funciones propias del clúster, como determinados accesos de consola, migraciones y replicaciones. Estas relaciones técnicas de confianza se evalúan por separado de los accesos personales de administración. Una limpieza general o la sobrescritura de archivos de claves puede alterar el funcionamiento. Por ello se contrastan los cambios con la documentación de la versión instalada.
Qué incluye un primer paso manejable
DAXS inventaría los accesos SSH existentes, asigna responsabilidades y planifica una gestión adecuada. El piloto prueba acceso, permisos, revocación, registro y recuperación. Un inicio de sesión correcto no basta como criterio de aceptación. Los registros de acceso por sí solos tampoco constituyen automáticamente un historial completo de todos los comandos ejecutados.
Los servicios de infraestructura y el artículo sobre Proxmox en la empresa aportan el contexto operativo. Para portales compartidos, el artículo sobre bóvedas, roles y bajas completa la perspectiva. Puede solicitar un inventario de los accesos administrativos.
Preguntas frecuentes
¿Puedo compartir una clave pública?
La parte pública está destinada a una distribución adecuada. Aun así hay que comprobar su asociación con la persona y el destino correctos. La parte privada se protege y no circula como archivo de acceso compartido.
¿Basta un certificado de corta duración para una revocación inmediata?
No. Deben considerarse conjuntamente emisión, validez restante, comprobación de revocación y sesiones ya abiertas. Una duración corta no sustituye este proceso.
¿Siempre hace falta una autoridad de certificación central?
No. El tamaño, la frecuencia de cambios, la automatización y la capacidad operativa determinan la solución adecuada. Una gestión de claves bien mantenida puede servir para un conjunto acotado de sistemas.
Fuentes: OpenSSH: autenticación y claves autorizadas (enlace externo) · OpenSSH: certificados y listas de revocación (enlace externo) · OpenSSH: reglas de confianza y revocación en el servidor (enlace externo) · OpenSSH: reenvío del agente (enlace externo) · OpenSSH: claves del agente y restricciones (enlace externo) · Proxmox VE: manual de administración, SSH en el clúster (enlace externo)
Orientación conceptual; las funciones concretas dependen de las versiones instaladas y la gestión prevista.
