Está tudo bem em usar uma chave SSH com uma frase secreta vazia?

Question

Quando aprendi a fazer chaves ssh, os tutoriais que li todos afirmavam que uma boa frase-senha deveria ser escolhida. Mas recentemente, ao configurar um processo daemon que precisa ser ssh para outra máquina, descobri que a única maneira (aparentemente) de ter uma chave que não preciso de auth em cada inicialização é criar uma chave com uma passphrase. Então, minha pergunta é: quais são as preocupações com o uso de uma chave sem senha?

    

Answer 1

Uma chave sem frase-senha depende de mais ninguém conseguir essa chave (quem não conseguiria obter os recursos aos quais dá acesso). Então, se a chave concede acesso a uma máquina próxima a ela e as duas máquinas têm o mesmo nível de segurança física e eletrônica, não é grande coisa.

Por outro lado, se a sua chave estiver em uma máquina com pouca segurança (talvez tenha muitos usuários não confiáveis, seja facilmente acessível fisicamente ou não seja mantida em dia com seu regime de correção), você provavelmente não quer manter as chaves sem senha aqui.

Em última análise, é preciso confiar na sua configuração e pesar os riscos / custos de fazê-lo - se você pode ter certeza de que não é realisticamente mais fácil para um invasor obter acesso à chave do que ao recurso que a chave fornece você acessa, então você está bem. Se você não tem confiança, provavelmente deve corrigir os motivos:)

    

Answer 2

outra solução, aumentando a segurança e facilitando o uso de você, para que você não precise digitar sua senha o tempo todo:

se você quiser criptografar sua chave privada, use ssh-agent em sua estação de trabalho para "armazenar em cache" a chave não criptografada. quando você quiser armazenar sua chave descriptografada, você executará ssh-add ~/.ssh/id_rsa ou qualquer que seja sua chave privada. você será solicitado a fornecer a senha e a chave descriptografada estará disponível para suas conexões ssh até que você efetue logout, elimine ssh-agent ou desligamento.

você pode kill das chaves armazenadas com ssh-agent -k e você pode atribuir uma vida útil para a chave estar na memória com ssh-agent -t [seconds] , por exemplo; Se você não quiser manter a sua chave descriptografada para sempre, mas você quer fazer muito ssh-ing em torno de seus hosts, você pode definir o tempo limite para 5-10 minutos. para que você não precise inserir continuamente a senha da sua chave.

novamente, tudo isso tem a ver com a confiança da segurança de sua / workstation /, que, se você é o único que tem acesso a ela, e você tem uma senha local bastante segura, e você não convide exploits e rootkits para você, sua chave privada sem senha é razoavelmente segura.

Se você é como eu, e mantém sua chave privada em um thumb-drive, você definitivamente vai querer criptografar isso, mesmo que seja apenas uma chave privada (uma separada da qual eu uso na minha estação de trabalho , então se eu perder minha chave, posso facilmente remover a chave pública da unidade de polegar da lista ~/.ssh/authorized_keys do meu servidor, o que também traz uma / excelente / razão para adicionar comentários ÚTEIS às suas chaves públicas)

na sua resposta a uma resposta anterior, você disse que apenas as pessoas em quem você confia têm acesso à máquina com as chaves. Eu só quero esclarecer que sua chave privada não precisa estar no servidor que você está se conectando, caso seja o que você está fazendo. somente sua chave pública precisa estar no servidor, e isso não é um problema, e é por isso que é uma chave 'pública'.

oh, eu esqueci de mencionar; Eu inicio o ssh-agent quando eu inicio o X, caso contrário, as chaves não criptografadas que eu armazeno com ssh-add não são retidas através de diferentes xterm sessões, e eu tenho que re-digitar a senha toda vez que eu fechar o xterm Eu lancei ssh-add in. no meu arquivo ~/.xinitrc , eu tenho:

if [ -x /usr/bin/ssh-agent ]; then
   eval $(/usr/bin/ssh-agent)
fi

Eu tenho a chamada para ssh-agent envolta em eval porque o ssh-agent retorna algumas variáveis de ambiente que precisam ser definidas quando é executado e executado a partir de ~/.xinitrc , as variáveis de ambiente são constantes durante a sessão X.

    

Answer 3

Você pode dar uma olhada em um pergunta semelhante Eu perguntei sobre chaves privadas SSL para servidores web. Basicamente, existem três opções:

1. Proteja a chave com perms do sistema de arquivos.
2. Use uma chave protegida por senha e insira a chave manualmente em cada reinicialização.
3. Use uma chave protegida por senha e armazene a chave no sistema de arquivos para automatizar a reinicialização.

Cada um deles é falho, então tudo depende do que você mais teme.

    

Answer 4

Para acesso automatizado, o que, como você diz, requer chaves sem senha, eu sempre uso as opções extras de authorized_keys (veja sshd (8)) para limitar o comando que pode ser executado.

Normalmente eu forneço um script cuidadosamente escrito no final remoto, que faz exatamente o trabalho (ou trabalhos - pode olhar para os parâmetros) que eu quero que seja permitido.

Então eu também bloqueio os endereços IP que podem se conectar com essa chave (não 100% infalível, mas também com a restrição de comando).

    

Answer 5

Desde que ninguém além de você tenha acesso à chave, você não precisa de uma frase secreta. Na verdade, você não pode usar uma frase secreta nas chaves usadas pelo software automatizado.

    

Answer 6

Se você quiser usar o ssh para fazer qualquer tipo de procedimento automatizado - estou pensando especificamente em verificações do Nagios - então você provavelmente não desejaria usar uma frase secreta.

Nesta situação, você provavelmente não usaria isso fora de uma LAN e teria a chave armazenada com segurança no servidor que faz o procedimento.

A maioria dos tutoriais discutindo o SSH antecipará a entrada de uma pessoa a partir de uma rede externa, possivelmente de um computador não seguro, caso em que o conselho é sólido.

Basicamente, a menos que você saiba que há uma boa razão para não criar uma frase secreta. Estar com preguiça de digitar sua senha toda vez pode ser uma boa razão para você: -)