Estoy esbozando una forma de fortalecer y automatizar el inicio de sesión del servidor usando ssh-keygen con certificados donde los certificados son válidos, por ejemplo. 1 semana, se generan en un servidor de confianza y se pueden usar tanto para crear el usuario del servidor como para iniciar sesión. El esquema podría extenderse fácilmente para admitir diferentes roles, como implementación, respaldo, sudo, etc.
Mi pregunta es: ¿diría que el método propuesto a continuación es seguro y confiable?
En resumen, los pasos serían:
- El usuario inicia sesión en la página web
- El usuario proporciona la clave pública SSH
- El servidor genera dos certificados, uno para root para crear el usuario y el otro para iniciar sesión
- El usuario descarga los certificados generados a la carpeta de inicio en la máquina cliente
- La primera vez que accede al servidor, el usuario usará el certificado de creación de usuario. Tras la conexión (como root), el servidor creará el usuario y luego se desconectará.
- En el uso normal, se utilizará el certificado de inicio de sesión. Este certificado deberá actualizarse una vez a la semana.
- Si un usuario sospecha la pérdida de un certificado, entonces el propio usuario o un administrador pueden actualizar la lista de revocación de claves desde el servidor emisor
Los pasos más significativos involucrados serían:
- Cree una clave de firma de usuario almacenada en un servidor seguro. El servidor podría estar protegido por auth2_proxy para la autenticación y le permite cifrar para SSL. Al utilizar oauth2_proxy, la identidad del usuario se conoce y autentica. La autorización podría ser por membresías grupales verificadas por oauth2_proxy.
- Todos los servidores deben ser aprovisionados para aceptar usuarios mediante la firma de la clave del paso 1. (Configure TrustedUserCAKeys en / etc / ssh / sshd_config) El inicio de sesión con contraseña se puede eliminar y la lista de revocación de claves debe sincronizarse continuamente.
- Cuando un usuario solicita un certificado de creación de usuario, el usuario proporcionará su clave pública, y el servidor creará el certificado y se lo proporcionará al usuario. La identidad se guarda para proporcionar capacidades de revocación de claves si es necesario.
ssh-keygen -s ca-private-keyfile -I 'create user username válido NN ' -V + 30d -n root -O borrar -O force-command = 'useradd username ' user-provided-public-key
- Cuando un usuario solicita un certificado de inicio de sesión, el usuario proporcionará su clave pública, y el servidor creará el certificado y se lo proporcionará al usuario. (De nuevo, guardando identidad para posible revocación de clave)
ssh-keygen -s ca-private-keyfile -I 'user @ org válido nn ' -V + 7d -n nombre de usuario user-provided-public-key
Notas:
- Sería posible y recomendable agregar un paso de verificación de dos factores al menos a los pasos de generación de firmas.
- El usuario debe, por conveniencia, tener dos pares de claves SSH para que ssh pueda distinguir entre los certificados deseados.
- Sería fácil emitir más tipos de acceso cambiando el comando-force, como obtener acceso a sudo: -n root -O force-command 'adduser username sudo' con el beneficio adicional de los usuarios pueden elegir cuándo invocar sus derechos y sobre qué hosts.
- Para proporcionar un acceso más granular, se pueden emitir certificados con límites para nombres de host, o se puede instalar una clave de firma diferente en diferentes clases de hosts.
- Para proporcionar cierta protección contra un atacante que lee los archivos en el servidor emisor (por ejemplo, obtener acceso a la copia de seguridad), el par de claves SSH podría estar cifrado en el servidor. Los usuarios que necesiten emitir certificados deberán conocer la contraseña y proporcionarla en cada solicitud de firma.
He encontrado una configuración similar donde los colegas firman las solicitudes de firmas de otros: enlace pero preferiría una configuración como el anterior.