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

12

Recentemente, adquiri um novo laptop para o trabalho, e fiquei me perguntando 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.

É, em geral, uma prática aceitável? Como o par de chaves tem uma frase secreta, ele deve ser razoavelmente seguro, contanto que minhas máquinas físicas estejam seguras, certo?

    
por Naftuli Kay 26.12.2011 / 05:29

5 respostas

4

Sim, é seguro, desde que esteja em boas mãos, ou seja, as máquinas físicas estejam seguras. É claro que, se um invasor obtiver acesso e puder fazer ssh em uma máquina, ele poderá obter a chave dessa máquina e usar a chave para outros computadores também. Veja this para mais informações.

    
por 26.12.2011 / 07:29
6

Para ser um pouco mais claro das 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 sua (s) chave (s) privada (s), ela poderá ser enviada por email ou copiada para um dispositivo USB. Então, 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 ir para várias máquinas.

Mas uma coisa eu vou dizer: 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ê tiver uma chave privada em um sistema remoto, certifique-se de que não seja a mesma chave usada para acessar o sistema.

    
por 26.12.2011 / 20:23
1

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

Ainda assim, a questão que Arcege apontou de maneira inteligente, embora indiretamente, é que, se uma única máquina é comprometida ou desaparece por um curto período de tempo, isso significaria que eu não teria mais acesso de nenhuma máquina (como minha chave para todas as minhas máquinas teria que ser puxada para baixo). 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 incômodo de lidar com várias chaves.

Em um exemplo ainda mais extremo, imagine que eu sou o administrador de sistema e tenho um laptop roubado ou hackeado. Minha chave precisa ser removida, mas preciso de acesso a 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 exclusivas para cada estação de trabalho, se eu puder acessar uma estação de trabalho alternativa, posso excluir a chave comprometida de forma rápida e eficiente, sem correr o risco de me trancar.

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

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

O requisito de senha abrange o acesso ao servidor e uma senha para a chave. O fator hassle sobe, mas no ponto em que temos todos os três no lugar (chaves SSH, senha de acesso da chave SSH, senha do servidor) nesse ponto, há não é mais um ponto único de falha . Uma senha compartilhada do servidor também protege sua equipe contra uma senha de senha SSH muito fraca (normalmente não temos controle sobre o nível de senha que nossos colegas geram) e um administrador de senha em uma situação corporativa em que eu tenho acesso a ferramentas de auditoria de senha diga-lhe que mesmo aqueles que deveriam conhecer melhor algumas vezes criam senhas chocantes e 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, a senha do servidor compartilhada com um sistema de nível corporativo como o LastPass - lembre-se que há chaves SSH também), neste ponto seus servidores desfrutam de segurança razoável (já que ninguém poderia combinar um SSH quente chave com uma senha antiga para invadir).

É preciso pensar em acesso ilegal à informação privilegiada (Edward Snowden vem à mente, a invasão de Ashley Madison vem em segundo lugar) como um risco primário. Somente usando chaves e senhas seria possível realmente retardar um insider.

Diferente do método chinês antigo: enterre-os vivos quando o trabalho estiver terminado.

After the burial, it was suggested that it would be a serious breach if the craftsmen who constructed the mechanical devices and knew of its treasures were to divulge those secrets. Therefore after the funeral ceremonies had completed and the treasures hidden away, the inner passageway was blocked, and the outer gate lowered, immediately trapping all the workers and craftsmen inside. None could escape.

    
por 21.04.2017 / 00:46
0

Para chaves de usuário - sim, se você usa uma frase secreta segura e criou a chave em um sistema sem falhas de segurança do ssh.

Para chaves do servidor: não.

    
por 26.12.2011 / 22:50
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.

    
por 26.12.2011 / 23:08

Tags