Forcer rsync en mode non interactif

8

Je voudrais utiliser rsync dans un script python. Je l'appelle à l'aide du subprocessmodule et je m'authentifie à l' aide de clés publiques stockées dans le authorized_keyfichier sur la machine distante.

Le seul problème est que lorsque j'utilise rsync en utilisant un mauvais nom d'utilisateur distant, je suis invité à entrer un mot de passe, ce qui arrête évidemment le script de sauvegarde pour toujours.

Puis-je forcer rsyncà quitter avec erreur s'il ne peut pas s'authentifier, plutôt que de demander un mot de passe?

Udi

shell rsync

— Adam Matan
source

9

En supposant que vous utilisez rsync avec un shell distant SSH (et non - par exemple - avec un serveur rsync), vous pouvez demander à rsync d'exécuter SSH d'une manière qui ne demandera jamais de mot de passe. Par exemple, une fois peut utiliser cet appel:

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

Cela forcera rsync à utiliser SSH avec 0 essai de mot de passe possible - s'il ne peut pas accéder à l'aide d'une autre méthode d'authentification (comme la clé publique ou GSSAPI), il échouera avec une erreur. Notez que rsync ne vous aimera pas lorsque cela se produira et se plaindra fortement à STDERR et rompra avec le code de sortie 255.

— Guss
source

5

Voici les options de ligne de commande pour ssh que j'utilise pour le garder silencieux.

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

Vous n'avez besoin de la clé hôte que si vous ne gérez pas votre fichier known_hosts et que vous craignez d'obtenir des avertissements MitM. Plutôt que de spécifier les types d'authentification comme suggéré par James F, j'ai dû restreindre explicitement l'authentification par mot de passe. Je l'utilise pour toucher des centaines d'hôtes avec quelques versions de système d'exploitation différentes, donc il peut s'agir simplement d'une incompatibilité.

— Chad Huneycutt
source

1

Veuillez NE PAS utiliser ces paramètres. Voir la section 11.5 de «SSH, The Secure Shell: The Definitive Guide, Second Edition» d'Oreilly. Selon le livre: "Malheureusement, sauter efficacement l'authentification du serveur désactive une partie vitale de la sécurité SSH: la résistance à l'usurpation d'hôte du serveur et aux attaques de l'homme du milieu! Cette situation rend également impossible le remplacement périodique des clés du serveur, comme cela devrait être le cas. fait, ou pour révoquer une clé dans le cas où elle est connue pour être compromise (c'est-à-dire, dire aux clients de ne plus lui faire confiance). "

— Mick

1

@Mick: le problème avec de telles critiques est qu'elles sont totalement inappropriées dans certains contextes. Par exemple, je travaille dans un environnement où la cible des opérations rsync est généralement une multitude de systèmes embarqués dans un réseau privé enfoui au fond d'un laboratoire. Il n'y a aucune connectivité avec le monde extérieur, et le système de construction doit être capable de pousser le code mis à jour vers les cibles. Il s'agit d'une utilisation tout à fait légitime de ssh et rsync, et la solution évidente est de désactiver la vérification de l'hôte. Faire une règle absolue à ce sujet n'a aucun sens.

— Stabledog

@Stabledog - Mon conseil est le bon conseil pour la grande majorité des cas d'utilisation. Cependant, je concède que lorsque vous ne pensez pas qu'un mauvais acteur peut raisonnablement obtenir l'accès à votre réseau pour effectuer une attaque MiTM, vous pouvez choisir une configuration de sécurité faible. La configuration de sécurité requise pour un environnement de laboratoire (comme vous l'avez mentionné) sera évidemment différente d'un environnement de production car le risque est naturellement réduit.

— Mick

C'est suffisant. Voici la préoccupation philosophique, mais aussi pratique: ssh est valorisé pour bien plus que sa capacité à être sécurisé , et en fait ... dans la plupart des paramètres que je l'ai vu utiliser, la sécurité est la préoccupation la moins importante . C'est juste le couteau suisse de choix pour les connexions à distance de tous types. Il y a donc ce décalage entre les réprimandes des «puristes de la sécurité» et la façon dont les vraies personnes l'utilisent tout le temps de manière quotidienne et pratique. Je ne crois pas que nous soyons tous des imbéciles occasionnels et que les puristes ont "raison". C'est une question de savoir quand prendre soin.

— Stabledog

1

re: suggestion de James (ne lui donnant pas tty), pour le sous-processus, essayez de mettre stdin = None comme paramètre à Popen.

— Adam Brand
source

0

Commencez par faire fonctionner rsync à partir du shell, la commande devrait ressembler à ceci.

Si cela échoue, déboguez la commande ssh seule. Lorsque tout fonctionne, voyez ce qui se passe pour le script python

Ce n'est pas un mauvais tutoriel

— James
source

0

Selon la façon dont vous lancez rsync, ne pas lui donner de TTY ou PTY peut aider.

De nombreux programmes vérifient s'ils ont un ATS de contrôle avant de décider d'inviter l'utilisateur à entrer. Le comportement par défaut de system () et des appels similaires est de fournir un tty aux sous-programmes, mais vous pouvez le désactiver.

Il peut également être possible de désactiver l'authentification par mot de passe entièrement du côté distant si vous contrôlez les deux systèmes et que vous souhaitez vous éloigner de l'authentification par mot de passe pour les avantages de sécurité tout en résolvant ce problème.

Si vous faites rsync sur SSH, vous pouvez ajouter ce qui suit à votre fichier ssh_config pour l'hôte en question, ou via le commutateur de ligne de commande -o:

PreferredAuthentications publickey

Sur un test rapide (juste ssh, pas rsync) qui a entraîné la fermeture immédiate de SSH lorsque ma clé publique n'a pas été acceptée sans me demander de mot de passe.

— James F
source