A melhor maneira de distribuir a chave SSH pública do usuário para vários hosts?

5

Obviamente eu poderia scp a chave para cada host que o usuário precisa de acesso SSH. Mas se houver muitos hosts, isso pode levar muito tempo. Especialmente se a autenticação de chave pública ainda não estiver configurada, cada scp exigiria que eu inserisse uma senha. Isso pode ser muito demorado e chato.

O uso de diretórios iniciais montados automaticamente resolveria esse problema? Como todos os hosts usariam o mesmo diretório inicial para cada usuário, as chaves públicas só precisariam ser copiadas uma vez. Isso não parece certo no entanto. Alguém pode me dar conselhos?

    
por Timothy Pulliam 09.10.2017 / 19:34

3 respostas

5

Existem várias maneiras de fazer isso, especialmente se você estiver em versões recentes do OpenSSH. Lembre-se também de que você precisa de mais do que uma maneira de adicioná-los, você precisa de uma maneira de removê-los (e rapidamente - considere se a chave está comprometida, as partes da pessoa em termos ruins, etc.). Uma adição importante que leva um dia para se propagar é um aborrecimento; uma remoção de chave que leva um dia para se propagar é uma séria preocupação de segurança.

Tendo em mente que a importância da remoção é fácil, isso sugere algumas abordagens:

  1. Parece que você já tem uma maneira de criar os usuários rapidamente. Existe uma boa chance de que o LDAP, por exemplo. O LDAP pode armazenar chaves públicas SSH, e você pode conectar isso ao sshd usando a opção de configuração AuthorizedKeysCommand . Por exemplo, se você estiver executando o SSSD, sss_ssh_authorizedkeys é destinado a isso. (Veja, por exemplo, documentos do RedHat sobre chaves autorizadas do SSSD ). A adição e a remoção de chaves podem ser instantâneas. No pior dos casos, normalmente, são necessários alguns segundos para a propagação do LDAP. Você pode muito bem automatizar isso (e se você tiver um monte de usuários provavelmente já tem!), Não exigindo nenhuma intervenção do administrador.

  2. Se os seus servidores devem lidar com a autenticação offline (e além do que o SSSD pode fazer), outra abordagem é usar o suporte da autoridade de certificação (CA) no OpenSSH. Isso está documentado principalmente na seção “Certificados” da manpage ssh-keygen . Basicamente, você configura o sshd de seus servidores para confiar em sua CA e para buscar automaticamente listas de revogação de atualização. Em seguida, você assina a chave pública do cliente com essa CA e fornece o certificado ao cliente. Nesse ponto, o cliente pode efetuar login em todos os servidores que usam esse certificado. Para cancelar a autorização do cliente, adicione-o à lista de revogação (conforme explicado na seção imediatamente a seguir na página man). A adição de chaves é instantânea. A remoção depende da frequência com que você atualiza as listas de revogação. Infelizmente não há nada como OCSP para SSH CAs. Automação (sem ajuda administrativa) de adições é possível fazer com segurança; de remove é fácil.

  3. Você poderia, como sugere, usar diretórios pessoais compartilhados, montados automaticamente (ou montados permanentemente, não é necessário montar automaticamente) para que todos os servidores vejam o mesmo ~/.ssh/authorized_keys - mas esse é um lote de sobrecarga se você não precisar de um $HOME compartilhado. A adição e a remoção de chaves são instantâneas para bastante rápidas, dependendo do armazenamento em cache. Gerenciamento de chaves provavelmente feito inteiramente pelo usuário, não por um administrador.

    3b. Ulrich Schwarz aponta que você pode alterar a localização do arquivo de chaves autorizadas do usuário; não precisa ser ~/.ssh/authorized_keys . Assim, você pode compartilhar um diretório contendo todos os arquivos de chaves autorizados dos usuários e não ter a sobrecarga de diretórios iniciais totalmente compartilhados.

  4. Você poderia usar sua ferramenta de gerenciamento de configuração como sugere o @DopeGhoti. Tenha muito cuidado para não esquecer um host - especialmente aquele em que a chave foi adicionada manualmente. Provavelmente significa que a adição e remoção de chaves exigirá intervenção manual do administrador.

por 09.10.2017 / 20:45
5

Ansible é uma solução livre baseada em ssh para administração remota do sistema projetada para executar um determinado comando (ou playbook) em um conjunto configurável ou subconjunto de hosts; para algo tão simples quanto distribuir chaves shell seguras, essa provavelmente seria uma opção de baixo crescimento.

    
por 09.10.2017 / 19:47
0

Criar arquivo com hosts:

$ vim server.list
server1.ru
server2.ru
192.168.0.100
192.168.0.101
...

Instale o sshpass:

# apt-get install sshpass

Crie um script simples para copiar ssh:

$ vim script.sh
#!/bin/bash
while read -r line
do
    echo "running $line"
    sshpass -p sshPassword ssh-copy-id userName@$line -o "StrictHostKeyChecking no"
done < "server.list"

Executar script:

$ sh script.sh
running server1.ru
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1
running server2.ru
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Fonte

    
por 24.10.2017 / 20:49