rsync como outro usuário

1

quando eu executo o comando follow como usuário normal tudo funciona corretamente:

fabio@myclient:~$ rsync -rv myserver:~/backup /home/fabio/backup/

Funciona sem interação do usuário, mas eu preciso rodar em um script executado como root, então tentei:

root@myclient:~# sudo -u fabio rsync -rv myserver:~/backup /home/fabio/backup/

e também tentou:

root@myclient:~# su - fabio -c "rsync -rv myserver:~/backup /home/fabio/backup"

ambos funcionam mas me perguntam uma "senha para chave", posso evitá-lo?

    
por Fabio 27.09.2016 / 22:53

2 respostas

1

O "passphrase para key" provavelmente vem do SSH e não de rsync ou sudo , que está pedindo a frase secreta para desbloquear sua chave SSH privada.

Como realmente não recomendo que você use uma chave sem uma frase secreta, considere as circunstâncias em que o script é executado como raiz. O script é sempre executado como root algum dia depois do login? Você está bem em entrar com sua senha uma vez após o login?

Se esse for o caso, recomendo usar algo como keychain para garantir que o agente ssh tenha sido iniciado como seu usuário é usado pelo script enquanto ele está sendo executado como root. Você pode configurar isso para que você tenha que digitar a senha uma vez após o login, e qualquer chamada futura não requer interação.

Se esse não for o caso, se o script tiver que ser executado autonomamente sem qualquer autenticação interativa, considere gerar um par de chaves especificamente para o script de backup e, em seguida, restringir o que ele pode fazer, autenticando-o como outro usuário no final remoto (ou seja, não fabio , mas, por exemplo, fabio-backup ), ou restringindo-o com o argumento command= no seu arquivo .authorized_keys no final remoto (embora isso seja um pouco mais complicado, como isso requer olhar a variável de ambiente SSH_ORIGINAL_COMMAND , veja authorized_keys (5) para detalhes)

    
por 27.09.2016 / 23:31
1

Sua chave privada ssh é protegida por frase secreta. Quando você o executa manualmente como usuário (logado), ele usa o agente ssh onde armazenou o keystore de senha longa uma vez.

No entanto, quando executado de forma autônoma, isso não acontece - afinal, o usuário pode nem estar logado (e, portanto, seu keystore não está disponível). Para que ele sempre funcione, você precisa remover a frase secreta da sua chave privada ssh (via ssh-keygen -p quando estiver logado como usuário fabio - basta pressionar enter para a nova frase secreta e ela deve ser removida).

Nota de segurança menor: quando a chave privada não é protegida por frase secreta, qualquer pessoa que obtiver acesso a fabio conta também poderá ssh como para outros hosts que permitem essa chave, sem precisar primeiro sintetizar a senha do usuário )

    
por 27.09.2016 / 23:37