A chave para uma tarefa cron em execução automática que executa em ssh não possui uma frase secreta?

Question

Estou lendo um artigo em Master Linux Now 2013 chamado OpenSSH: Easy Logins e ele usa ssh-agent para permitir que você insira uma frase secreta para sua chave uma vez e, em seguida, é possível se conectar a uma máquina remota sem digitar novamente enquanto o agente ssh estiver rodando.

A razão pela qual fui atraído para o artigo em primeiro lugar, além de não ter que redigitar minha senha um milhão de vezes; foi para que eu pudesse fazer backups autônomos de / para máquinas remotas chamando o rsync do cron em uma máquina remota para o servidor através do ssh;

Eu vi outro artigo em que alguém simplesmente pulou a senha para que o cron pudesse facilmente usar a chave para fazer login, não parece certo, mas está tudo bem em fazer isso na prática? Quero dizer, se alguém pegasse o arquivo de chaves, seria capaz de causar estragos na máquina que está sendo copiada.

Parece-me mais seguro certificar-se de que o usuário está logado na reinicialização e fazer com que ele insira a frase-senha uma vez, quando eles fazem login para obter o agente em execução e apenas aguardar a execução da tarefa cron com o tela bloqueada; mas provavelmente eu estou sentindo falta de algo aqui, como sobre qual usuário ou usuário digita tarefas do cron executadas.

    

Answer 1

Restringe os comandos que podem ser invocados pela chave

Se uma chave SSH for usada por qualquer tipo de tarefa automatizada ou autônoma, você deve restringir os comandos que ela pode executar em uma máquina remota, independentemente da decisão tomada sobre como e onde armazenar a chave .

Use algo assim em ~/.ssh/authhrized_keys :

command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....

Dessa forma, pelo menos a chave não deve ser capaz, como você diz, de causar estragos. Ele só pode acessar o que deve acessar, etc ... Ele provavelmente ainda pode causar danos, mas deve ter menos que o acesso total ao sistema remoto.

Você também pode restringir os endereços IP que podem se conectar usando essa chave e desabilitar vários outros recursos SSH, como o encaminhamento de porta para conexões nas quais essa chave é usada:

from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....

Tudo o que precisa ir em uma única linha em ~/.ssh/authorized_keys .

Protegendo a chave

Depende de qual é o seu modelo de ameaça.

Se você está preocupado com a chave que está sendo roubada enquanto está "fria", por exemplo, se o computador foi salvo fisicamente, você não vai querer salvá-lo sem uma frase secreta nesse local.

Você pode iniciar um tipo de agente SSH em segundo plano manualmente após a inicialização do servidor, adicionar a chave a esse agente e registrar $SSH_AUTH_SOCK do agente para uso futuro pela tarefa cron, mas honestamente Soa como mais problemas do que vale a pena. Você pode simplesmente armazenar a chave não criptografada em um sistema de arquivos tmpfs e fazer com que a tarefa cron acesse a partir daí. De qualquer forma, a chave fica na memória apenas (se você não tiver swap ou troca criptografada). É claro que você deve chown e chmod do arquivo para que apenas o usuário alvo possa acessá-lo.

Então, novamente, se você está preocupado com isso, provavelmente já configurou este computador com um sistema de arquivos raiz criptografado e troca (por exemplo, luks), então você pode não precisar se preocupar com isso.

Se você está preocupado com a chave que está sendo roubada enquanto está "quente" (carregado na memória), então não há muito o que fazer sobre isso. Se o cron job puder acessá-lo, então poderá outra coisa que conseguiu obter o mesmo acesso. É isso, ou desistir da conveniência de execução de trabalho autônoma.

Em conclusão, você deve tratar um servidor de backup como um sistema muito privilegiado, uma vez que, por necessidade, terá acesso somente leitura aos sistemas de arquivos completos de todos os computadores que ele faz backup. Seu servidor de backup não deve estar acessível na Internet, por exemplo.