En mi empresa, utilizamos LDAP para tener un conjunto consistente de cuentas en todas las máquinas y luego utilizamos una herramienta de administración de configuración (en nuestro caso actualmente cfengine) para distribuir authorized_keysarchivos para cada usuario en todos los servidores. Los archivos de claves se guardan (junto con otra información de configuración del sistema) en un repositorio de git para que podamos ver cuándo van y vienen las claves. cfengine también distribuye un sudoersarchivo que controla quién tiene acceso para ejecutar qué como raíz en cada host, utilizando los usuarios y grupos del directorio LDAP.
La autenticación de contraseña está completamente deshabilitada en nuestros servidores de producción, por lo que la autenticación de clave SSH es obligatoria. La política alienta el uso de una clave separada para cada computadora portátil / computadora de escritorio / lo que sea y el uso de una frase de contraseña en todas las teclas para reducir el impacto de una computadora portátil perdida / robada.
También tenemos un host de bastión que se utiliza para acceder a los hosts en la red de producción, lo que nos permite tener reglas de firewall muy restrictivas alrededor de esa red. La mayoría de los ingenieros tienen alguna configuración SSH especial para hacer esto transparente:
Host prod-*.example.com
User jsmith
ForwardAgent yes
ProxyCommand ssh -q bastion.example.com "nc %h %p"
Agregar una nueva clave o eliminar una antigua requiere un poco de ceremonia en esta configuración. Yo diría que para agregar una nueva clave es deseable que sea una operación que deje un rastro de auditoría y sea visible para todos. Sin embargo, debido a los gastos generales involucrados, creo que las personas a veces descuidan quitar una clave antigua cuando ya no es necesaria y no tenemos una forma real de rastrearla, excepto para limpiar cuando un empleado deja la empresa. También crea una fricción adicional al incorporar un nuevo ingeniero, ya que necesitan generar una nueva clave y enviarla a todos los hosts antes de que puedan ser completamente productivos.
Sin embargo, el mayor beneficio es tener un nombre de usuario separado para cada usuario, lo que facilita el control de acceso más granular cuando lo necesitamos y le da a cada usuario una identidad que aparece en los registros de auditoría, lo que puede ser realmente útil al tratar de rastrear un problema de producción de vuelta a una acción de administrador de sistemas.
En esta configuración, es molesto tener sistemas automatizados que actúen contra los hosts de producción, ya que sus claves SSH "conocidas" pueden servir como una ruta de acceso alternativa. Hasta ahora hemos hecho que las cuentas de usuario para estos sistemas automatizados tengan solo el acceso mínimo que necesitan para hacer su trabajo y aceptamos que un usuario malintencionado (que ya debe ser un ingeniero con acceso de producción) también podría hacer esas mismas acciones semi- utilizando de forma anónima la clave de la aplicación.