Na minha empresa, usamos o LDAP para ter um conjunto consistente de contas em todas as máquinas e usamos uma ferramenta de gerenciamento de configuração (no nosso caso atualmente cfengine) para distribuir authorized_keys arquivos para cada usuário em todos os servidores. Os arquivos de chaves em si são mantidos (juntamente com outras informações de configuração do sistema) em um repositório git para que possamos ver quando as chaves vêm e vão. O cfengine também distribui um arquivo sudoers que controla quem tem acesso para executar o que é root em cada host, usando os usuários e grupos do diretório LDAP.
A autenticação por senha é totalmente desativada em nossos servidores de produção, portanto, a autenticação por chave SSH é obrigatória. A política incentiva o uso de uma chave separada para cada laptop / desktop / qualquer coisa e o uso de uma senha em todas as chaves para reduzir o impacto de um laptop perdido / roubado.
Também temos um host bastion que é usado para acessar hosts na rede de produção, permitindo que tenhamos regras de firewall muito restritivas em torno dessa rede. A maioria dos engenheiros tem alguma configuração SSH especial 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 nessa 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 deixam de remover uma chave antiga quando ela não é mais necessária e não temos nenhuma maneira real de rastrear isso, exceto para limpar quando um funcionário deixa a empresa. Ele também cria algum atrito adicional ao embarcar em um novo engenheiro, já que eles precisam gerar uma nova chave e enviá-la a todos os hosts antes que eles 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 dá a cada usuário uma identidade que aparece nos registros de auditoria, o que pode ser muito útil ao tentar para rastrear um problema de produção de volta para uma ação sysadmin.
É incomodativo, sob essa configuração, ter sistemas automatizados que executem ações contra hosts de produção, já que suas chaves SSH "conhecidas" podem servir como um caminho de acesso alternativo. Até agora, fizemos as contas de usuário para esses sistemas automatizados terem apenas o mínimo de acesso necessário para realizar seus trabalhos e aceitaram que um usuário mal-intencionado (que já deve ser engenheiro com acesso de produção) também poderia fazer essas mesmas ações. anonimamente usando a chave do aplicativo.