Boas práticas para usar o mesmo par de chaves SSH em várias máquinas?

12

Recentemente, adquiri um novo laptop para trabalhar e fiquei pensando se seria uma boa prática continuar usando o mesmo par de chaves RSA que estou usando no meu antigo laptop de trabalho. Eu realmente gostaria de não ter que criar outro par de chaves para acompanhar.

Isso é, de um modo geral, uma prática aceitável? Como o par de chaves tem uma senha, ele deve ser razoavelmente seguro, desde que minhas máquinas físicas estejam seguras, certo?

Naftuli Kay
fonte

Respostas:

4

Sim, é seguro desde que esteja em boas mãos, ou seja, máquinas físicas são seguras. Obviamente, se um invasor obtém acesso e é capaz de fazer o ssh em uma máquina, ele pode obter a chave dessa máquina e usá-la em outros computadores também. Veja isto para mais informações.

harish.venkat
fonte
2
Somente a máquina que possui a chave privada precisa estar segura.
Psd #
7

Para ficar um pouco mais claro com as outras respostas aqui e em outros lugares: a "segurança" é tão segura quanto a segurança da chave privada. Se alguém puder acessar suas chaves privadas, elas poderão ser enviadas por email ou copiadas para um dispositivo USB. Em seguida, a chave privada copiada pode ser usada por outra pessoa.

Desde que a chave privada esteja em um sistema seguro, não há problema em acessá-lo em várias máquinas.

Mas uma coisa que direi: não copie uma chave privada para um sistema remoto. Tente confiar no agente SSH (ssh-agent ou pageant) e no encaminhamento do agente. Se você possui uma chave privada em um sistema remoto, verifique se não é a mesma chave usada para acessar o sistema.

Arcege
fonte
1

Uma única chave em várias máquinas certamente reduz a quantidade de chaves que um administrador de sistemas precisa manipular. Eu tenho cinco máquinas nas quais posso trabalhar (geralmente cerca de três muito ativas, mas uma pode estar em reparo, outra em uso muito ocasional). Se uma empresa tinha oito pessoas como eu, faz 40 chaves para administrar em vez de 8.

No entanto, a questão que a Arcege apontou de maneira bastante inteligente, embora indireta, é que, se uma única máquina for comprometida ou mesmo desaparecer por um curto período de tempo, isso significaria que eu não teria mais acesso a partir de nenhuma máquina (como minha chave para todas as minhas máquinas teriam que ser derrubadas). Certamente, a conveniência de poder remover uma única chave de um laptop comprometido ou roubado e poder continuar trabalhando em outra máquina vale o trabalho de lidar com várias chaves.

Em um exemplo ainda mais extremo, imagine que eu sou o administrador do sistema e tenho um laptop roubado ou hackeado. Minha chave precisa ser removida, mas eu preciso acessar todos os sistemas para fazer isso. Embora seja tecnicamente possível substituir e remover em uma única sessão, ao tentar mover-se rapidamente e cobrir todas as bases, isso complica consideravelmente o cenário de emergência.

Por outro lado, se eu tiver chaves únicas para cada estação de trabalho, se puder acessar uma estação de trabalho alternativa, posso excluir rápida e eficientemente a chave comprometida, sem correr o risco de me bloquear.

À medida que me aprofundo na abordagem das chaves SSH à segurança, fica claro que, para segurança real, todos devemos usar os dois:

  • o que temos (chaves SSH)
  • o que sabemos (senha para o servidor)

O requisito de senha abrange o acesso ao servidor e uma senha para a chave. O fator de aborrecimento aumenta, mas no momento temos os três em vigor (chaves SSH, senha de acesso à chave SSH, senha do servidor) nesse ponto, não há mais um único ponto de falha . Uma senha de servidor compartilhada também protege sua equipe contra uma senha de chave SSH muito fraca (normalmente não temos controle sobre o nível de senha que nossos colegas geram - e um administrador de senhas em uma situação corporativa em que tenho acesso às ferramentas de auditoria de senha que posso diga a você mesmo quem deve saber melhor às vezes cria senhas chocantemente fracas).

Um invasor precisa ser determinado e um ataque bem-sucedido pode levar meses ou até anos. Alterando a senha do servidor ocasionalmente (a cada seis meses ou mais, a senha do servidor é compartilhada com um sistema de nível empresarial como o LastPass - lembre-se de que também existem chaves SSH), neste momento seus servidores desfrutam de segurança razoável (como ninguém poderia combinar um SSH quente chave com uma senha antiga para invadir).

É preciso pensar no acesso interno ilegal (Edward Snowden vem à mente, o Ashley Madison vem em segundo) como um risco primário. Somente usando chaves e senhas seria possível realmente desacelerar um usuário interno.

Diferente do método chinês antigo: enterre-os vivos quando seu trabalho terminar.

Após o enterro, sugeriu-se que seria uma violação grave se os artesãos que construíram os dispositivos mecânicos e conheciam seus tesouros divulgassem esses segredos. Portanto, depois que as cerimônias fúnebres terminaram e os tesouros foram escondidos, a passagem interna foi bloqueada e o portão externo abaixou, prendendo imediatamente todos os trabalhadores e artesãos que estavam dentro. Ninguém poderia escapar.

Foliovision
fonte
0

Para chaves de usuário - sim, se você usar uma senha segura e criar a chave em um sistema sem falhas de segurança ssh.

Para chaves do servidor: não.

Nils
fonte
0

Eu diria que é um bom hábito ter chaves diferentes para grupos diferentes, por exemplo: trabalho, casa, open_source_project.

Quanto mais chaves você adicionar, mais complexo será gerenciá-las.

AB
fonte