Forzare rsync in modalità non interattiva


8

Vorrei usare rsync all'interno di uno script Python. Lo chiamo utilizzando il subprocessmodulo e eseguo l'autenticazione utilizzando le chiavi pubbliche memorizzate nel authorized_keyfile sul computer remoto.

L'unico problema è che quando uso rsync usando un nome utente remoto errato, mi viene richiesta la password, che ovviamente interrompe per sempre lo script di backup.

Posso forzare rsyncl'uscita con errore se non è in grado di eseguire l'autenticazione, anziché richiedere la password?

Udi

Risposte:


9

Supponendo che tu usi rsync con una shell remota SSH (e non - per esempio - con un server rsync), puoi ottenere rsync per eseguire SSH in un modo che non chiederà mai una password. Ad esempio, una volta puoi usare questa chiamata:

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

Questo costringerà rsync a usare SSH con 0 possibili tentativi di password - se non riesce ad accedere usando qualche altro metodo di autenticazione (come chiave pubblica o GSSAPI), allora fallirà con un errore. Si noti che rsync non ti piacerà quando ciò accade e si lamenterà ad alta voce con STDERR e si romperà con il codice di uscita 255.


5

Ecco le opzioni della riga di comando per ssh che uso per mantenerlo silenzioso.

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

Hai solo bisogno dell'elemento hostkey se non mantieni il tuo file known_hosts e sei preoccupato di ricevere avvisi MitM. Invece di specificare i tipi di autenticazione come suggerito da James F, ho dovuto limitare esplicitamente l'autenticazione con password. Lo uso per colpire centinaia di host con alcune versioni del sistema operativo diverse, tuttavia, quindi potrebbe essere solo un'incompatibilità.


1
Si prega di NON utilizzare queste impostazioni. Vedi la sezione 11.5 di "SSH, The Secure Shell: The Definitive Guide, Second Edition" di Oreilly. Secondo il libro: "Sfortunatamente, saltare efficacemente l'autenticazione del server disabilita una parte vitale della sicurezza SSH: la resistenza allo spoofing dell'host del server e agli attacchi man-in-the-middle! Questa situazione rende anche poco pratico sostituire le chiavi del server periodicamente, come dovrebbe essere fatto, o di revocare una chiave nel caso in cui sia noto che sia compromessa (ovvero, dire ai clienti di non fidarsene più). "
Mick,

1
@Mick: il problema con critiche come queste è che sono del tutto inadeguate in alcuni contesti. Ad esempio, lavoro in un ambiente in cui l'obiettivo delle operazioni rsync è generalmente un host di sistemi integrati in una rete privata sepolta in profondità in un laboratorio. Non esiste alcuna connettività con il mondo esterno e il sistema di compilazione deve essere in grado di spingere il codice aggiornato verso il basso sui target. Questo è un uso completamente legittimo di ssh e rsync e la soluzione ovvia è disattivare il controllo host. Fare una regola assoluta al riguardo non ha alcun senso.
Stabledog,

@Stabledog - Il mio consiglio è il consiglio corretto per la stragrande maggioranza dei casi d'uso. Tuttavia, ammetto che quando non credi che un cattivo attore possa ragionevolmente ottenere l'accesso alla tua rete per eseguire un attacco MiTM, puoi scegliere una configurazione di sicurezza debole. La configurazione di sicurezza richiesta per un ambiente di laboratorio (come hai menzionato) ovviamente differirà da un ambiente di produzione perché il rischio è naturalmente ridotto.
Mick,

Giusto. Ecco la preoccupazione filosofica, oltre che la pratica, però: ssh è valutato per molto più della sua capacità di essere sicuro , e in effetti ... nella maggior parte delle impostazioni che ho visto usato, la sicurezza è la preoccupazione meno importante . È solo il coltellino svizzero scelto per le connessioni remote di tutti i tipi. Quindi c'è questa disconnessione tra i rimproveri dei "puristi della sicurezza" e il modo in cui le persone reali lo usano sempre in modo pratico e quotidiano. Non credo che siamo tutti solo degli sciocchi casuali e che i puristi siano "giusti". È una questione di sapere quando preoccuparsi.
Stabledog,

1

ri: il suggerimento di James (non darlo tty), per i sottoprocessi, prova a mettere stdin = None come parametro su Popen.


0

Prima fai in modo che rsync funzioni dalla shell, il comando dovrebbe apparire come.

In caso contrario, eseguire il debug del comando ssh da solo. Quando tutto funziona, vedi cosa succede per lo script Python

Questo non è un cattivo tutorial


0

A seconda di come stai lanciando rsync, non assegnarle un TTY o PTY potrebbe essere d'aiuto.

Molti programmi controllano se dispongono di un TTY di controllo prima di decidere di richiedere l'input all'utente. Il comportamento predefinito di system () e chiamate simili è di fornire un sottotitolo ai sottoprogrammi, ma è possibile disabilitarlo.

Potrebbe anche essere possibile disabilitare completamente l'autenticazione della password sul lato remoto se si ha il controllo di entrambi i sistemi e si desidera allontanarsi dall'autenticazione della password per i vantaggi di sicurezza mentre si risolve questo problema.

Se stai eseguendo rsync su SSH, puoi aggiungere quanto segue al tuo file ssh_config per l'host in questione o tramite l'opzione -o della riga di comando:

PreferredAuthentications publickey

In un rapido test (di solo ssh, non rsync) che ha causato la chiusura immediata di SSH quando la mia chiave pubblica non è stata accettata senza richiedermi una password.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.