Tenho cerca de 20 servidores… como gerencio as chaves SSH e as permissões de cada um?

Question

Eu tenho servidores de banco de dados, servidores web, servidores SVN, etc. Muitas vezes eu ssh entre eles ... ou eles auto-ssh.

Como faço para gerenciar qual servidor consegue fazer login em quais outras pessoas?

    

Answer 1

Eu uso o Puppet, e tenho uma classe definida para cada chave, então classes que incluem essas classes para definir os "grupos" de chaves que tenho (para nós é gente - então técnicos de L1, técnicos de L2, gerentes, desenvolvedores - - mas você pode fazer servidores db, servidores de arquivos, servidores svn, etc). Então os vários tipos de máquinas têm seus próprios manifestos que definem quais desses grupos têm acesso a esse tipo de máquina, então as caixas de desenvolvimento têm L1, L2 e desenvolvedores, servidores de produção têm L1 e L2, servidores sensíveis têm L2, esse tipo de coisa. Adicionar uma nova máquina é apenas uma questão de decidir a quais classes ela pertence e adicionar algumas linhas aqui e ali, que documentamos em nossos novos procedimentos de comissionamento de máquinas.

    

Answer 2

Estamos usando o OpenLDAP para armazenar usuários:

• chaves públicas
• senhas
• uids
• direitos do sudo
• nomes reais
• números de telefone
• e-mails
• e etc.

É estável, fácil de expandir, tem muitos recursos de documentação e integração, por isso recomendo.

    

Answer 3

MIT Kerberos v5.

O Kerberos é um sistema seguro, orientado por privilégios e baseado em tickets, que entende os conceitos de usuários, domínios, funções, máquinas, etc. Primeiro você autentica com um ticket de concessão de ticket, que obtém tickets de serviço para você quando você solicita um privilégio / login específico em uma máquina. Você pode controlar quais entidades podem efetuar login em quais contas com arquivos ~ / .k5login gerenciados centralmente, talvez via Puppet / cfengine. As máquinas base de configuração podem ter seus próprios princípios / chaves, etc., para poder atualizar os outros sistemas automaticamente. Você também precisa proteger o KDC fisicamente e bloqueá-lo para talvez um ou dois usuários críticos, pois é aqui que você revoga os principais, etc.

Sua implementação variará muito, tenho certeza, mas a descrição acima é uma visão geral muito ampla da configuração que usamos para executar.

É um sistema complexo e pode exigir uma mudança drástica no seu final, no que diz respeito à implementação e aos procedimentos de segurança. Na minha experiência, no entanto, uma vez que o sistema está no lugar e configurado corretamente, torna-se transparente e é muito menos um fardo para as várias equipes envolvidas.

Você pode ler mais sobre isso aqui:

Guia do usuário do MIT Kerberos

    

Answer 4

Isso pode simplificar um pouco sua tarefa: use ssh-copy-id [-i [identity_file]] [user@]master-host para se conectar de cada um desses servidores a um deles. Use clusterssh para fornecer este comando para todos os servidores de uma só vez. Em seguida, copie o arquivo authorized_keys keys do host principal para todos os outros hosts: por exemplo, com clusterssh e scp . Isso vai fazer o truque simples, rápido, legal e ... uma vez:)

    

Answer 5

Você pode estar interessado no conceito de ssh-agent, no qual você pode deixar uma conexão ssh-client perguntar "de volta" através da (s) conexão (s) ssh usada para obter a localização atual sobre credenciais.

É muito útil.