Na minha empresa, usamos o LDAP para ter um conjunto consistente de contas em todas as máquinas e, em seguida, usamos uma ferramenta de gerenciamento de configuração (no nosso caso atualmente cfengine) para distribuir authorized_keysarquivos para cada usuário em todos os servidores. Os próprios arquivos de chave são mantidos (junto com outras informações de configuração do sistema) em um repositório git, para que possamos ver quando as chaves vão e vêm. O cfengine também distribui um sudoersarquivo que controla quem tem acesso para executar o que como raiz em cada host, usando os usuários e grupos do diretório LDAP.
A autenticação de senha é completamente desativada em nossos servidores de produção, portanto, a autenticação de chave SSH é obrigatória. A política incentiva o uso de uma chave separada para cada laptop / desktop / o que for e o uso de uma senha em todas as chaves para reduzir o impacto de um laptop perdido / roubado.
Também temos um host bastião usado para acessar hosts na rede de produção, o que nos permite ter regras de firewall muito restritivas em torno dessa rede. A maioria dos engenheiros possui algumas configurações especiais de SSH para tornar isso transparente:
Host prod-*.example.com
User jsmith
ForwardAgent yes
ProxyCommand ssh -q bastion.example.com "nc %h %p"
Adicionar uma nova chave ou remover uma antiga exige um pouco de cerimônia nesta configuração. Eu diria que, para adicionar uma nova chave, é desejável que seja uma operação que deixe uma trilha de auditoria e seja visível para todos. No entanto, devido à sobrecarga envolvida, acho que as pessoas às vezes esquecem de remover uma chave antiga quando ela não é mais necessária e não temos uma maneira real de rastrear isso, exceto para limpar quando um funcionário deixa a empresa. Ele também cria um atrito adicional ao integrar um novo engenheiro, já que eles precisam gerar uma nova chave e enviá-la a todos os hosts antes que possam ser completamente produtivos.
No entanto, o maior benefício é ter um nome de usuário separado para cada usuário, o que facilita o controle de acesso mais granular quando necessário e fornece a cada usuário uma identidade que aparece nos logs de auditoria, o que pode ser realmente útil ao tentar rastrear um usuário. problema de produção de volta a uma ação sysadmin.
É incômodo, nessa configuração, ter sistemas automatizados que executam ações contra hosts de produção, pois suas chaves SSH "conhecidas" podem servir como um caminho de acesso alternativo. Até agora, acabamos de fazer com que as contas de usuário desses sistemas automatizados tenham apenas o acesso mínimo necessário para realizar suas tarefas e aceitamos que um usuário mal-intencionado (que já deve ser um engenheiro com acesso à produção) também possa executar essas mesmas ações semi- anonimamente usando a chave do aplicativo.