Melhor sistema para gerenciar chaves ssh? [fechadas]


42

Eu tenho vários computadores clientes (ou seja, laptops, desktops etc.), conecto-me a várias máquinas servidor que eu gerencio e faço logon nelas via SSH. Posso imaginar vários esquemas de gerenciamento de chaves ssh que fariam sentido e estou curioso sobre o que os outros fazem.

Opção 1: Um par de chaves pública / privada global.

Eu geraria um par de chaves pública / privada e colocaria a chave privada em todas as máquinas clientes e a chave pública em todas as máquinas servidores.

Opção 2: um par de chaves por máquina servidor.

Eu geraria um par de chaves em cada máquina servidor e colocaria cada chave privada nas máquinas clientes.

Opção 3: um par de chaves por máquina cliente.

Cada máquina cliente teria uma chave privada exclusiva e cada máquina servidor teria as chaves públicas de todas as máquinas clientes das quais eu gostaria de conectar.

Opção 4: um par de chaves por par cliente / servidor

Totalmente ao mar?

Qual destes é o melhor? Existem outras opções? Quais critérios você usa para avaliar a configuração correta?

Respostas:


33

Uso a Opção 3: um par de chaves por máquina cliente e faz mais sentido para mim. Aqui estão alguns dos motivos:

  • Se um cliente estiver comprometido, essa chave (e somente essa chave) precisará ser removida dos servidores.
  • É flexível o suficiente para decidir o que eu posso acessar de onde, sem conceder acesso geral a todos os servidores de todos os clientes.
  • Muito conveniente. Há apenas uma chave para ssh-add, sem confusão.
  • Fácil de configurar e administrar pela Opção 4

A opção 4 é boa, mas é muito trabalho. A opção 3 leva você a 98% com muito menos problemas.


4
Não vejo o ponto da opção 4. Não serve para nada.
NiXar 29/05/2009

26

Uso uma solução que é um pouco mais complicada, mas muito versátil, pois quero manter alguma separação nas chaves de identidade SSH usadas para meus servidores de rede doméstica, servidores de escritório, servidores de rede de clientes consultores e outros sistemas em que tenho contas.

Agora que eu disse que trabalho quase exclusivamente em estações de trabalho Linux, tenho uma chave USB configurada usando a criptografia LUKS e meu gerenciador de janelas X11 junto com o daemon HAL detecta a unidade criptografada LUKS e solicita a senha de descriptografia quando é inserida e tenta ser montado. Armazenando isso em uma unidade criptografada da maneira que faço, nunca armazeno minhas chaves SSH em nenhuma estação de trabalho.

Em seguida, tenho a seguinte configuração no meu ~/.ssh/configarquivo:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

O % d é convertido para o diretório inicial do usuário pelo OpenSSH e no diretório ~ / .ssh eu criei o keys.d como um link simbólico para o caminho do diretório na unidade USB criptografada quando montada corretamente.

A expressão % l é traduzida como o nome do host das máquinas clientes locais e % u será convertida no nome de usuário do cliente local.

O que essa configuração faz é permitir que o SSH procure uma chave usando 3 expressões diferentes. Por exemplo, se o nome de usuário do jdoemeu cliente local fosse e o nome da máquina do cliente local, examplehostele procuraria na seguinte ordem até encontrar uma chave que existisse e fosse aceita pelo servidor remoto.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Você pode usar a expressão % r para procurar uma chave específica para o nome de usuário do servidor remoto ou % h para o nome do host do servidor remoto, exatamente como % u e % l foram usados.

Atualização: Agora eu realmente utilizo o GnuPG gpg-agent com compatibilidade ssh-agent para apenas ler e usar a chave de autenticação do meu cartão inteligente OpenPGP v2.


Uau, ótima solução, obrigado! Eu amo a configuração universal em ~ / .ssh / config
slacy

Provou-se bastante conveniente manter as coisas separadas para trabalho, pessoal e consultoria em servidores de rede de clientes ... Não quero misturar autenticação entre eles, mas também quero que seja fácil para mim.
Jeremy Bouse

Surpreendente! Eu realmente amo esse.
18711

Presumo que você esteja usando chaves USB diferentes para máquinas clientes diferentes. Caso contrário, qual é o ponto em chaves separadas se todas elas estiverem armazenadas no mesmo local? Em caso de violação, você precisaria revogar todos eles. A menos que (e provavelmente) eu esteja perdendo algo, isso apenas complica as coisas.
Halil Özgür

@ HalilÖzgür, Sim, faço consultoria e nem sempre quero usar a mesma chave. Como a chave USB é criptografada e não está conectada a nenhum computador, a menos que eu precise estabelecer uma conexão, não há preocupação de o servidor estar sendo violado e a senha para descriptografar o sistema de arquivos da unidade é suficientemente longa para simplificar bastante a revogação de chaves.
Jeremy Bouse

6

Eu eliminaria as duas opções 1s (das quais suspeito que uma deveria ser a opção 2 ;-) porque as chaves privadas são dados confidenciais e faz sentido mantê-las no menor número possível de lugares. Pessoalmente, nunca copiaria uma chave privada de um computador para outro (ou mesmo de um arquivo para outro no mesmo computador), exceto talvez para fazer backups. Embora diferente da maioria das chaves de criptografia, se uma chave SSH se perder, não será o fim do mundo (basta criar uma nova, você não perde nenhum dado).


Sim, renomeado para uma "Opção 2" adequada. Gosto da regra de "nunca copiar uma chave privada". Essa é uma boa regra.
Slacy 28/05


1

Opção 3.

Isso também permite controlar quais servidores um cliente pode acessar. por exemplo, se o cliente X precisar acessar os servidores A e B, mas C ou D, você copiará sua chave pública apenas para esses hosts.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.