Encontré esta pregunta al intentar responderla yo mismo. Después de algunas búsquedas y experimentos, he encontrado algunas otras opciones para esto. Voy a omitir la parte sobre la distribución de claves como alternativa ya que Matt Simmons lo cubrió. Además, sé que hay momentos en que eso no es lo suficientemente bueno. Por ejemplo, si usted es GitHub y tiene que almacenar millones de claves públicas contra un solo usuario, no es factible o deseable actualizar continuamente los archivos SSH autorizado_keys y mantenerlos sincronizados entre docenas y cientos de cajas de borde.
Entonces,
En primer lugar, RedHat (y sus variantes) tienen un parche compatible para OpenSSH que agrega las opciones AuthorizedKeysCommandy AuthorizedKeysCommandRunAs. El parche se ha fusionado en sentido ascendente en openssh 6.2. Para citar de la página del manual :
AuthorizedKeysCommand
Especifica un programa que se utilizará para buscar las claves públicas del usuario. El programa se invocará con su primer argumento el nombre del usuario que se está autorizando, y debe producir en las líneas de salida autorizadas AuthorizedKeys (ver AUTHORIZED_KEYS en sshd (8)). De forma predeterminada (o cuando se establece en la cadena vacía) no se ejecuta AuthorizedKeysCommand. Si AuthorizedKeysCommand no autoriza correctamente al usuario, la autorización se transfiere a AuthorizedKeysFile. Tenga en cuenta que esta opción solo tiene efecto con PubkeyAuthentication activado.
AuthorizedKeysCommandRunAs
Especifica el usuario bajo cuya cuenta se ejecuta AuthorizedKeysCommand. La cadena vacía (el valor predeterminado) significa que se utiliza el usuario que está siendo autorizado.
En mis experimentos de esta noche, descubrí que esto no funciona debido a las políticas predeterminadas de SELinux. Puede solucionar esto desactivando la aplicación de SELinux con setenforce 0. Dado que la conversión de SELinux es probablemente una mala idea, en su lugar puede generar la política correcta. En mi caso, eso fue tan simple como intentar iniciar sesión con la AuthorizedKeysCommandopción configurada /etc/ssh/sshd_configy luego usar audit2allow -a -M local && semodule -i local.pp. Básicamente, esto revisa los registros de auditoría y encuentra cosas que se evitaron y genera excepciones para ellos. Si es probable que tenga otras cosas allí que podrían incluirse en la lista blanca, probablemente debería obtener más información audit2allowpara asegurarse de obtener las nuevas políticas correctas.
Existen otros parches diferentes (probablemente menos probados y confiables) para agregar una funcionalidad similar. Por ejemplo, hay, openssh-script-auth . También puede encontrar el parche que RedHat usó y aplicarlo directamente. Un encuentro rápido de Google descubre https://launchpadlibrarian.net/89063205/openssh-5.3p1-authorized-keys-command.patch y https://launchpadlibrarian.net/105938151/openssh-authorized-keys-command.patch que son basado en las versiones RH pero que se han actualizado para las versiones más nuevas de OpenSSH.
Parche OpenSSH para realizar búsquedas de claves directamente desde alguna tienda (por ejemplo, como GitHub y CodeBaseHQ y otros lo han hecho). GitHub no ha abierto este parche, que yo sepa, pero sé que en el pasado he encontrado versiones para la búsqueda de claves MySQL y PostgreSQL. Traté de encontrarlos nuevamente pero no he tenido mucha suerte.
También hay algunas opciones basadas en FUSE. Por ejemplo, hay LPKFuse que le permite servir claves públicas de LDAP cambiando la AuthorizedKeysFileubicación a una en el sistema de archivos LPKFuse. LPKFuse FS crea archivos virtuales cuyo contenido está respaldado por campos de un servidor de directorio.
En general, creo que la opción # 1 es, con mucho, la mejor, ya que es oficialmente compatible con RedHat. Además, le permite poner cualquier lógica que desee en ese script (incluyendo hablar con una base de datos) en el idioma que desee.