Conselhos para gerir chaves SSH

13

Qual é a melhor prática que você encontrou para gerenciar muitos keypairs SSH?

Eu uso o SSH para me conectar a vários sistemas, tanto em casa como no trabalho. Atualmente tenho uma coleção bastante pequena de pares de chaves para sistemas de trabalho e domésticos. Eu tenho um script que gera um par de chaves com nome para que eu possa evitar confusão.

Minha rede doméstica é composta de meu laptop (ubuntu), dois desktops (boot dual do Ubuntu / Fedora, boot duplo do fedora / windows) e um sistema de mídia (Ubuntu). No trabalho eu tenho meu laptop pessoal (que eu uso para trabalhar em casa), meu desktop (fedora), um sistema de produção (RHEL), e um laptop com windows (suspiro) e uma VM (fedora). Tudo bem até agora.

(não tenho interesse em colocar meu par de chaves no meu sistema de trabalho ou no par de chaves do meu trabalho. E temos contas de usuário virtuais para mecanizar transferências de arquivos com outros sistemas, onde a chave privada deve residir na máquina de produção, para transferir arquivos entre outros sistemas.)

Mas agora vem o Hadoop, um grande cluster de mais de 100 sistemas e, com isso, mais complexidade, mais usuários e mais keypairs. Agora preciso gerenciar as chaves.

(preciso esclarecer. Sou um desenvolvedor de software consultando um cliente que está implantando um cluster do Hadoop. Eles precisam gerenciar chaves. Haverá muitas pessoas acessando o cluster, precisando colocar suas chaves públicas em Como o Linux savant residente, eles me pediram ajuda. Eu recomendei a contratação de um administrador de sistema, mas até que eles o fizessem, eu estou ajudando)

Quando eu preciso publicar a chave pública em um sistema remoto, todas as páginas da Web 'como fazer' sugerem substituir (>) (destruindo chaves existentes) ou acrescentar (> >) (que é bom, preserva chaves existentes). Mas eu acho que preservar cada chave pública na máquina de destino separadamente, e combiná-las seria melhor. Estou procurando conselhos.

Qual é a melhor prática que você encontrou para gerenciar muitas chaves?

Obrigado!

Edit: Um aspecto é a necessidade de colocar chaves em muitos sistemas, e o CRUD (criar, ler, atualizar, deletar / desabilitar) para usuários específicos, o que significa ser capaz de identificar quais chaves pertencem para quais usuários.

    
por ChuckCottrill 11.10.2013 / 04:29

4 respostas

12

Geralmente você não deve ter mais de uma chave por máquina cliente (ênfase em "geralmente"). Não tenho certeza se estou entendendo sua pergunta corretamente, mas se você está dizendo que tem uma chave separada para cada sistema remoto, então você está definitivamente fazendo isso errado.

O ssh usa criptografia de chave pública. A chave que você instala no sistema remoto é a chave pública, não há absolutamente nenhum dano em reutilizar esta chave em outro lugar. É a chave privada que deve ser protegida e permanece no seu sistema pessoal.

Também é uma boa ideia ter a chave privada em apenas um cliente, não compartilhada. Isso é para que, se um cliente for comprometido, você possa revogar apenas essa chave.

Agora, se você está perguntando como você pode obter sua chave pública para centenas de sistemas, há algumas maneiras de fazer isso.

A maneira mais comum é usar diretórios pessoais compartilhados. Ter um NFS (ou outro sistema de arquivos de rede) montado (ou montado automaticamente) em todos os sistemas.

A outra maneira é aproveitar um novo recurso no ssh. É uma diretiva de configuração chamada AuthorizedKeysCommand . Basicamente é um comando que o sshd irá rodar toda vez que precisar procurar uma chave pública. O comando simplesmente grava a chave pública do usuário que está sendo consultado no STDOUT. Isto é usado principalmente quando você não tem diretórios home montados, mas ainda tem um servidor de autenticação central ( FreeIPA aproveita isso).

É claro que você pode fazer outras coisas, como o rsync do cron job em /home de um servidor central. Mas isso não é uma prática comum.

    
por 11.10.2013 / 04:55
2

When I need to publish the public key to a remote system, all of the 'how-to' web pages suggest either overwrite (>) (destroying existing keys), or append (>>) (which is good, preserves existing keys). But I would think preserving each public key on the destination machine separately, and combining them would be better. I am looking for advice.a

Eu não vejo nenhuma vantagem em armazenar as chaves públicas ambas em .ssh/authorized_keys e em um arquivo separado.

Se você observar as chaves armazenadas no arquivo * authorized_keys *, verá que elas já contêm meta-informações legíveis sobre a origem da chave. por exemplo. a chave pública para user@foo geralmente tem uma entrada como:

ssh-rsa AAAAB3Nza...LiPk== [email protected]

tornando assim muito fácil inspecionar / extrair / apagar certas chaves (anexadas a certos usuários) do arquivo * authorized_keys *.

o ID do usuário é na verdade um campo de "comentário" de forma livre, para que você possa colocar qualquer informação lá, que julgue necessário para identificar a chave fornecida.

em qualquer caso, você deve gerar apenas pares de chaves para "usuários" que precisam acessar recursos remotos. É provável que você não precise fazer o login de cada host hadoop para o outro host hadoop. em vez disso, você terá algumas máquinas de gerenciamento que precisam acessar todos os hosts do hadoop. você só precisa de um único par de chaves por máquina de gerenciamento e instala cada chave pública em todos os hosts hadoop.

    
por 11.10.2013 / 09:35
1

O recente OpenSSH permite obter chaves ssh do LDAP, veja 'AuthorizedKeysCommand' em sshd_config man page. Pessoalmente, eu preferiria certificados OpenSSH, não chaves, consulte link . Você pode gerenciar as chaves com qualquer gerenciador de configuração como cfengine, fantoche, chef, sal ...

    
por 11.10.2013 / 10:18
0

Uma outra maneira que é super fácil de implementar e permite um pouco mais de flexibilidade em termos de adição de múltiplos usuários é usar. link

Ele permite que você defina diferentes grupos de servidores e tenha chaves para diferentes usuários habilitados ou desabilitados para esses servidores.

Instalação e gerenciamento super simples.

    
por 09.10.2015 / 22:51

Tags