Conselho para gerenciar chaves SSH

Qual é a melhor prática encontrada para gerenciar muitos pares de chaves SSH?

Uso o SSH para conectar-me a vários sistemas, tanto em casa quanto no trabalho. Atualmente, tenho uma coleção bastante pequena e gerenciável de pares de chaves para os sistemas doméstico e de trabalho. Eu tenho um script que gera um par de chaves nomeado para evitar confusão.

Minha rede doméstica é composta pelo meu laptop (ubuntu), dois desktops (inicialização dupla do ubuntu / fedora, inicialização dupla do fedora / windows) e um sistema de mídia (ubuntu). No trabalho, tenho meu laptop pessoal (usado para trabalhar em casa), minha área de trabalho (fedora), um sistema de produção (RHEL) e um laptop com janelas (suspiro) e uma VM (fedora). Tudo de bom até agora.

(Não tenho interesse em colocar meu par de chaves domésticas em meu sistema de trabalho ou meu par de chaves de trabalho em meus sistemas domésticos. E temos contas de usuário virtual para mecanizar as transferências de arquivos com outros sistemas, nos quais 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 mais complexidade, mais usuários e mais pares de chaves. Agora eu preciso gerenciar chaves.

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

Quando preciso publicar a chave pública em um sistema remoto, todas as páginas da Web 'sugerem' substituir (>) (destruir chaves existentes) ou acrescentar (>>) (que é bom, preserva as 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 encontrada para gerenciar muitas chaves?

Obrigado!

Editar: um aspecto é a necessidade de colocar as chaves em muitos sistemas e o CRUD (criar, ler, atualizar, excluir / desativar) para usuários específicos, o que significa precisar identificar quais chaves pertencem a quais usuários.

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 possui uma chave separada para cada sistema remoto, está definitivamente fazendo 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 mal em reutilizá-la 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 compartilhado. Isso é feito para que, se um cliente estiver comprometido, você possa revogar apenas essa chave.

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

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

A outra maneira é tirar proveito de um novo recurso no ssh. É uma diretiva de configuração chamada AuthorizedKeysCommand. Basicamente, é um comando que o sshd será executado toda vez que for necessário procurar uma chave pública. O comando simplesmente grava a chave pública do usuário que está sendo consultado no STDOUT. Isso é usado principalmente quando você não possui diretórios pessoais montados, mas ainda possui um servidor de autenticação central ( FreeIPA tira proveito disso).

Claro que você pode fazer outras coisas, como cron job rsync on, a /homepartir de um servidor central. Mas isso não é uma prática comum.

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

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

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

ssh-rsa AAAAB3Nza...LiPk== user@example.net

facilitando assim a inspeção / extração / exclusão de determinadas chaves (anexadas a determinados usuários) do arquivo * allowed_keys *.

o ID do usuário é realmente um campo de "comentário" de forma livre, para que você possa colocar todas as informações que achar necessárias para identificar a chave fornecida.

em qualquer caso, você deve gerar apenas pares de chaves para "usuários" que precisam acessar recursos remotos. as chances são de que você não precisa fazer login de cada host hadoop para outro host hadoop. em vez disso, você terá algumas máquinas de gerenciamento, que precisam acessar todos os hosts 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.

O OpenSSH recente permite obter chaves ssh do LDAP, consulte 'AuthorizedKeysCommand' na página de manual sshd_config . Pessoalmente, prefiro certificados OpenSSH, não chaves, consulte http://blog.habets.pp.se/2011/07/OpenSSH-certificates . Você pode gerenciar as chaves com qualquer gerenciador de configuração, como cfengine, fantoche, chef, sal ...

Uma outra maneira que é super fácil de implementar e permite um pouco mais de flexibilidade em termos de adição de vários usuários é usar. https://userify.com/

Permite definir diferentes grupos de servidores e ter chaves para diferentes usuários ativados ou desativados para esses servidores.

Instalação e gerenciamento super simples.