Forçando o rsync para o modo não interativo

8

Eu gostaria de usar o rsync dentro de um script python. Estou chamando usando o subprocessmódulo e autenticando usando chaves públicas armazenadas no authorized_keyarquivo na máquina remota.

O único problema é que, quando eu uso o rsync usando um nome de usuário remoto errado, sou solicitada uma senha, o que obviamente interrompe o script de backup para sempre.

Posso forçar rsynca saída com erro se não conseguir autenticar, em vez de solicitar a senha?

Udi

shell rsync

— Adam Matan
fonte

9

Supondo que você use o rsync com um shell remoto SSH (e não - por exemplo - com um servidor rsync), você poderá fazer com que o rsync execute o SSH de uma maneira que nunca solicite uma senha. Por exemplo, uma vez pode usar esta chamada:

rsync -e 'ssh -o "NumberOfPasswordPrompts 0"' source user@target:/path

Isso forçará o rsync a usar o SSH com 0 tentativas possíveis de senha - se não puder obter acesso usando outro método de autenticação (como chave pública ou GSSAPI), ocorrerá um erro. Observe que o rsync não vai gostar de você quando isso acontecer e irá reclamar alto com o STDERR e violar o código de saída 255.

— Guss
fonte

5

Aqui estão as opções de linha de comando para o ssh que eu uso para mantê-lo quieto.

ssh -o stricthostkeychecking=no -o userknownhostsfile=/dev/null -o batchmode=yes -o passwordauthentication=no

Você só precisa do material da chave do host se não mantiver seu arquivo known_hosts e estiver preocupado em receber avisos do MitM. Em vez de especificar os tipos de autenticação sugeridos por James F, tive que restringir explicitamente a autenticação por senha. Eu uso isso para atingir centenas de hosts com algumas versões diferentes do sistema operacional, portanto, pode ser apenas uma incompatibilidade.

— Chad Huneycutt
fonte

11

Por favor, NÃO use essas configurações. Consulte a seção 11.5 do "SSH, O Shell Seguro: O Guia Definitivo, Segunda Edição" da Oreilly. De acordo com o livro: "Infelizmente, ignorar efetivamente a autenticação do servidor desativa uma parte vital da segurança do SSH: resistência à falsificação do host do servidor e ataques do tipo intermediário! Essa situação também torna impraticável substituir as chaves do servidor periodicamente, como deveria ser". feito ou revogar uma chave, caso ela seja comprometida (ou seja, diga aos clientes para não confiar mais nela). "

— Mick

11

@Mick: o problema com críticas como essas é que elas são totalmente inadequadas em alguns contextos. Por exemplo, trabalho em um ambiente em que o destino das operações rsync geralmente é um host de sistemas incorporados em uma rede privada enterrada no fundo de um laboratório. Não existe conectividade com o mundo externo, e o sistema de compilação precisa poder inserir códigos atualizados nos destinos. Esse é um uso totalmente legítimo do ssh e rsync, e a solução óbvia é desativar a verificação do host. Estabelecer uma regra absoluta sobre isso não faz nenhum sentido.

— Stabledog

@Stabledog - Meu conselho é o conselho correto para a grande maioria dos casos de uso. No entanto, admito que, quando você não acredita que um ator ruim possa obter acesso razoável à sua rede para realizar um ataque MiTM, você pode escolher uma configuração de segurança fraca. A configuração de segurança necessária para um ambiente de laboratório (como você mencionou) obviamente será diferente de um ambiente de produção porque o risco é naturalmente reduzido.

— Mick

Justo. Aqui está a preocupação filosófica, bem como a prática: o ssh é valorizado por muito mais do que sua capacidade de ser seguro e, de fato ... na maioria das configurações que vi, a segurança é a preocupação menos importante . É apenas o canivete suíço de escolha para conexões remotas de todos os tipos. Portanto, existe essa desconexão entre as críticas de "puristas de segurança" e a maneira como as pessoas reais o usam o tempo todo de maneiras práticas diárias. Eu não acredito que somos todos tolos casuais e os puristas estão "certos". É uma questão de saber quando cuidar.

— Stabledog

1

re: sugestão de James (não dando tty), para subprocesso, tente colocar stdin = None como parâmetro para Popen.

— Adam Brand
fonte

0

Primeiro faça com que o rsync funcione no shell, o comando deve ser parecido.

Se isso falhar, depure o comando ssh por si só. Quando tudo funcionar, veja o que acontece com o script python

Este não é um mau tutorial

— James
fonte

0

Dependendo de como você está iniciando o rsync, não fornecer um TTY ou PTY pode ajudar.

Muitos programas verificam se eles têm um TTY de controle antes de decidir solicitar a entrada do usuário. O comportamento padrão de system () e chamadas semelhantes é fornecer um tty para subprogramas, mas você pode desativar isso.

Também pode ser possível desativar a autenticação por senha inteiramente no lado remoto, se você estiver no controle de ambos os sistemas e quiser se afastar da autenticação por senha para obter os benefícios de segurança ao resolver esse problema.

Se você estiver executando o rsync sobre SSH, poderá adicionar o seguinte ao seu arquivo ssh_config para o host em questão ou através da opção de linha de comando -o:

PreferredAuthentications publickey

Em um teste rápido (apenas de ssh, não de rsync) que causou a saída imediata do SSH quando minha chave pública não foi aceita sem solicitar uma senha.

— James F
fonte