Utilisation de Rsync et SSH


Original: http://troy.jdmz.net/rsync/index.html

 

Keys, validation, et de l’automatisation
Ce document couvre l’aide de cron, ssh, rsync et de sauvegarder des fichiers sur un réseau local ou sur Internet. Une partie de mon but est de s’assurer qu’aucune intervention de l’utilisateur est nécessaire lorsque l’ordinateur est redémarré (mots de passe, des clés ou des gestionnaires clés).
J’aime sauvegarde certaines coupes forestières, par la poste, et des informations de configuration parfois sur les hôtes sur le réseau et Internet, et voici un moyen que j’ai trouvé pour le faire. Vous aurez besoin de ces paquets installés:

  • rsync
  • openssh
  • cron (ou vixie-cron)

S’il vous plaît noter que ces instructions peuvent être spécifiques aux versions Red Hat Linux 7.3, 9 et Fedora Core 3, mais j’espère qu’ils ne seront pas trop difficile de s’adapter à presque n’importe quel OS de type * NIX. Les pages de manuel de ‘ssh’ et ‘rsync’ doivent vous être utile si vous avez besoin de changer certaines choses (utiliser le “man ssh” et les commandes “homme rsync”).

Tout d’abord, je vais définir certaines variables. Dans mon explication, je serai la synchronisation des fichiers (copier uniquement les fichiers nouveaux ou modifiés) dans un sens, et je vais commencer ce processus de l’hôte Je veux copier des choses à. En d’autres termes, je serai la synchronisation des fichiers à partir de / à distance / dir / sur remotehost, comme remoteuser, à / ce / dir / sur thishost, comme thisuser.
Je tiens à vous assurer que rsync sur ssh ‘fonctionne à tous avant de commencer à automatiser le processus, de sorte que je teste d’abord comme thisuser:

et tapez le mot de passe remoteuser @ remotehost lorsque vous êtes invité. Je ne dois m’assurer que remoteuser a lu les autorisations d’/ distance / dir / sur remotehost, et que thisuser n’a permissions d’écriture pour / ce / dir / sur thishost. Aussi, rsync et ssh ‘devraient être en chemin (l’utilisation “qui ssh” et “qui rsync”) de thisuser, rsync doit être dans le chemin de remoteuser, et’ sshd ‘doit être exécuté sur remotehost.

Configuration thishost

Si que tout a parfaitement fonctionné, ou j’ai finalement fait marche, je suis prêt pour la prochaine étape. J’ai besoin de générer une paire privé / public des clés pour permettre une connexion ‘ssh’ sans demander un mot de passe. Cela peut sembler dangereux, et il est, mais il est préférable de stocker un mot de passe de l’utilisateur (ou mot de passe clé) en texte clair dans le script [0]. Je peux également mettre des limites sur l’endroit où les connexions établies avec cette clé peuvent provenir, et sur ​​ce qu’ils peuvent faire lorsqu’ils sont connectés. Quoi qu’il en soit, je génère la clé je vais utiliser sur thishost (comme thisuser):

et maintenant nous avons une clé sans mot de passe dans les deux fichiers mentionnés ci-dessus [1]. Assurez-vous qu’aucun autre utilisateur non autorisé peut lire le fichier de clé privée (celle sans le «Pub». Extension).
Cette touche sert à rien jusqu’à ce que nous mettons la partie publique dans le fichier ‘authorized_keys de [2] sur remotehost, en particulier celui de remoteuser:

J’utilise scp pour obtenir le dossier à remotehost:

et alors je peux préparer les choses sur remotehost.

remotehost Configuration

I ‘ssh’ vers remotehost:

de faire un travail.
Je dois m’assurer que j’ai le répertoire et les fichiers que j’ai besoin d’autoriser les connexions avec cette touche [3]:

Maintenant, la clé peut être utilisée pour établir des connexions à cet hôte, mais ces connexions peut être de n’importe où (que le démon ssh sur remotehost permet des connexions à partir de) et ils peuvent faire quelque chose (que remoteuser peut faire), et je ne veux pas que . J’édite le fichier ‘authorized_keys de (avec vi) et modifier la ligne de l’information »thishost-rsync-key.pub» sur elle. Je ne vais ajouter quelques choses en face de ce qui est déjà là, en changeant la ligne de cette:

à cet [4]:

où “10.1.1.1” est l’adresse IP (version 4 [5]) adresse de thishost, et “/ home / remoteuser / cron / validate-rsync” (qui est juste l’une des quelques options [6], y compris la personnalisation [7 ] pour améliorer la sécurité) est un script qui ressemble à ceci:

Si thishost a une adresse de la variable, ou part son adresse (via NAT ou quelque chose de similaire) avec des hôtes que vous n’avez pas confiance, omettre le ‘from = “10.1.1.1”, “partie de la ligne (y compris la virgule), mais laisser le partie «de commande». De cette façon, seul le rsync sera possible de connexions à l’aide de cette clé. Assurez-vous que le script «validate-rsync ‘est exécutable par remoteuser sur remotehost et le tester.
S’IL VOUS PLAÎT NOTE: La clé privée, mais maintenant un peu limité dans ce qu’il peut faire (et je l’espère, où il peut être fait à partir de), permet au possesseur de copier n’importe quel fichier de remotehost que remoteuser a accès. C’est dangereux, et je doit prendre toutes les précautions que je juge nécessaire pour assurer la sécurité et le secret de cette clé. Quelques possibilités permettront de veiller permissions sur les fichiers sont affectés [8], pensez à utiliser un démon de mise en cache clé, et considérer si j’ai vraiment besoin de ce processus automatisé vers le risque.
A noter également: Un autre détail de sécurité à considérer est la configuration démon SSH sur remotehost. Cet exemple met l’accent sur un utilisateur (remoteuser) qui n’est pas racine. Je recommande de ne pas utiliser root comme utilisateur distant puisque root a accès à tous les fichiers sur remotehost. Cette capacité lui seul est très dangereux, et les sanctions pour une erreur ou une mauvaise configuration peut être bien plus forte que celles pour un utilisateur «normal». Si vous n’utilisez pas racine que votre utilisateur distant (jamais), et à prendre des décisions de sécurité pour remotehost, je vous recommande soit:

ou:

être inclus dans le fichier / etc / ssh / sshd_config ‘fichier sur remotehost. Ce sont des paramètres globaux, pas seulement liés à cet égard, alors assurez-vous que vous n’avez pas besoin de la capacité de ces options de configuration interdisent. [9].
Les «AllowUsers», «AllowGroups», «DenyUsers», et les mots clés »DenyGroups» peuvent être utilisés pour restreindre l’accès SSH aux utilisateurs et aux groupes particuliers. Elles sont documentées dans la page de man pour “sshd_config”, mais je vais mentionner que tous peuvent utiliser ‘*’ et ‘?’ comme caractères génériques pour permettre ou refuser l’accès aux utilisateurs et groupes qui correspondent à des modèles. «AllowUsers» et «DenyUsers» peuvent aussi restreindre par l’hôte lorsque le motif est en forme UTILISATEUR @ HOST.

dépannage

Maintenant que j’ai la clé sans mot de passe en place et configuré, j’ai besoin de le tester avant de le mettre dans une tâche cron (qui a son propre petit ensemble de bagages). Je sortie de la session ssh pour remotehost et essayer [10]:

Si cela ne fonctionne pas, je vais enlever la restriction “de commande” à la clé et essayez à nouveau. Si on vous demande un mot de passe, je vais vérifier les autorisations sur le fichier de clé privée (sur thishost, devrait être de 600), sur ‘authorized_keys’ et (sur remotehost, serais 600), dans le répertoire “~ /. Ssh / ‘(sur les deux hôtes, devrait être de 700), et sur ​​le répertoire de la maison (‘~ /’) lui-même (sur les deux hôtes, ne devrait pas être accessible en écriture par personne, mais l’utilisateur). Si certains ‘rsync’ erreur de protocole énigmatique se produit mentionnant le script ‘validate-rsync’, je vais m’assurer que les autorisations sur ‘validate-rsync’ (sur remotehost, peuvent être 755 si chaque utilisateur remotehost confiance) permet remoteuser de lecture et d’exécution il.
Si les choses ne fonctionnent pas encore sur, des informations utiles peuvent être trouvées dans les fichiers journaux. Les fichiers journaux on trouve habituellement dans le répertoire / var / log / sur la plupart des hôtes Linux, et dans le répertoire / var / log fichier journal / sécurité sur les hôtes Linux Red Hat-ish. Les fichiers journaux plus utiles dans ce cas se trouve sur remotehost, mais localhost peuvent fournir des informations côté client dans ses journaux [11]. Si vous ne pouvez pas obtenir dans les journaux, ou sont tout simplement impatient, vous pouvez dire au ‘ssh’ exécutable de fournir une journalisation avec le ‘verbose’ commandes: ‘-v’, ‘-vv’, ‘-vvv “. , Le plus prolixe de la sortie de la plus v. On est dans la commande ci-dessus, mais celui ci-dessous devrait fournir beaucoup plus de sortie:

Heureusement, il sera toujours juste fonctionner parfaitement si je n’ai jamais à étendre les informations de dépannage répertoriés ici [12].

Configuration Cron

La dernière étape est le script cron. J’utilise quelque chose comme ceci:

car il est facile de modifier les morceaux de la ligne de commande pour différents hôtes et chemins. J’ai l’habitude de l’appeler quelque chose comme “rsync-remotehost-sauvegardes» si elle contient des sauvegardes. Je teste le script trop, juste au cas où j’ai inséré soigneusement une erreur quelque part.
Quand je reçois le script en cours d’exécution avec succès, j’utilise “crontab-e” pour insérer une ligne pour cette nouvelle tâche cron:

pour un jour 5 heures de synchronisation, ou:

pour une semaine (5 heures le vendredi). Ceux mensuelles et annuelles sont plus rares pour moi, donc regarder “man crontab” ou ici pour obtenir des conseils sur ceux-ci.

Très bien! Sauf pour le quotidien «suivre avec des taches” chose, les insidieuses “vices cachés de configuration” partie, et «l’échec total de la logique humaine” inoubliable ensemble de problèmes, mon travail ici est fait. Amusez-vous!

notes:
[0] La raison derrière le choix d’une clé SSH sans mot de passe, sur les options comme ssh-agent ou porte-clés, c’est que le processus automatisé survivre à un redémarrage de la machine hôte et exécuter à l’heure prévue, sans aucune intervention de ma part (toutes les machines de façon automatisés sont toujours accessible). Si vous n’avez pas ces exigences, les autres options peuvent prêter votre mise en œuvre plus de sécurité.
[1] Si remotehost seulement a installé SSH1, vous pouvez avoir besoin d’utiliser un autre type de clé. Au lieu de «rsa” vous devrez utiliser “rsa1 ‘. Vous pouvez utiliser ‘dsa’ au lieu de ‘rsa’, mais il ne serez encore utile pour une connexion SSH2 (et longueur de clé peut être un problème comme indiqué ici – merci @ avenjamin). SSH2 connexions sont plus sûrs que SSH1 connexions, mais vous aurez à chercher ailleurs pour les détails à ce sujet (“man ssh-keygen” et Google). En outre, la création de la clé peut être fait avec la commande (ssh-keygen-b 2048-f fichier de clés-t rsa-N”) pour automatiser le “aucune partie du mot de passe clé”, ou (ssh-keygen-b 2048-f fichier de clés -q-t rsa-N”) pour éliminer toute sortie de la commande.
[2] Certaines configurations utilisent le fichier ‘authorized_keys2’ au lieu de ‘authorized_keys’. Cherchez «AuthorizedKeysFile” dans / etc / ssh / sshd_config.
[3] Si vous utilisez un autre shell que bash (ou autre shell compatible Bourne), comme “csh” ou “tcsh”, les commandes répertoriées peuvent ne pas fonctionner. Avant de les exécuter, lancer un bash (ou ‘sh’, ou ‘ksh », ou« zsh ») en utilisant la commande shell bash (ou’ sh ‘, ou’ ksh ‘, ou’ zsh). Après avoir terminé les commandes, vous devrez quitter le shell “bash”, puis quitter le shell de votre hôte se reproduit normalement.
[4] Rappelez-vous de ne pas insérer des sauts de ligne dans le “authorized_keys” fichier. Les informations clés, et les commandes insérées associé à cette touche, devraient tous être sur une seule ligne. La clé que vous générez (le truc absurde sur la touche de ligne) sera différent de celui d’ici.
[5] J’ai vu un hôte ignorer une adresse IPv4 bien présenté et la place voir la connexion entrante comme une sorte IPv6-ish de l’adresse (“:: fff: 10.1.1.1”). J’ai trouvé l’adresse dans «/ var / log / messages ‘sur une Fedora Core 3 Linux hôte, et il ne permet les connexions à partir de cet hôte avec la version IPv6-ish dans le fichier’ authorized_keys ‘.
[6] Une autre option pour la validation (et plus) est le script Perl situé ici: http://www.inwap.com/mybin/miscunix/?rrsync, mais il est plus compliqué. Une version de ce script Perl est maintenant livré avec la source de rsync ici: http://www.samba.org/ftp/unpacked/rsync/support/rrsync (avec des améliorations). Si vous écrivez un script personnalisé, dans la langue que vous trouverez des chambres confortables, regarder à l’intérieur celui-ci pour des suggestions.
[7] Au moment où le script ‘validate-rsync’ fonctionne, une connexion SSH a été faite avec la clé SSH vous en rapport avec cette commande dans le fichier ‘authorized_keys de. Cet exemple de script tente essentiellement de revenir “Rejeté” à autre qu’une commande qui commence par “rsync – serveur” tout ce qui est ce que rsync sur ssh fait à l’autre bout de la connexion. J’ai trouvé cela en exécutant «ps auxw | grep rsync ‘sur l’extrémité distante de la connexion après l’initialisation d’un travail de rsync longue course, mais un pro de rsync dit que vous pouvez ajouter-v-v-n’ à vos options de ligne de commande pour rsync et il affichera la commande qu’il utilisera sur la fin du serveur, donc l’utiliser pour faire votre commande de script plus précise si vous le souhaitez. Les six premières lignes «rejetés» essaient de elimate symboles shell qui permettra à une personne d’exécuter plus d’une commande dans une session (par exemple, un court rsync et une certaine maîtrise vilain vous ne voulez pas courir à distance). Vous pouvez également forcer le transfert pour être lue en changeant la commande “rsync – serveur – expéditeur *” (merci David Fred).
[8] En permissions sur les fichiers, je veux dire les permissions de fichiers sécurisés. En cela, vous êtes essentiellement défendez remotehost de remoteuser, de sorte que remoteuser ne serait pas en mesure de modifier cette configuration en aucune façon. Cela signifie que remoteuser ne sera pas propriétaire, ou être capable d’écrire le script de validation ou même fichier remoteusers authorized_keys. À ce stade, cependant, vous voudrez peut-être envisager d’utiliser “l’utilisateur Match” dans / etc / ssh / sshd_config et utiliser ChrootDirectory et / ou ForceCommand pour les contenir si la sécurité est très important pour vous. Aller aussi loin que vous voyez un besoin d’aller. (Merci Yanek Martinson).
[9] “PermitRootLogin no” fait ce qu’il dit: l’utilisateur root n’est pas autorisé à se connecter via SSH. “PermitRootLogin-commandes forcées seule” exige que toutes les connexions, via SSH en tant que root, doivent utiliser l’authentification par clé publique (avec une clé comme ‘thishost-rsync-key.pub’) et qu’une commande est associée à cette touche (comme ‘validate-rsync’). Pour plus d’explications, utilisez la commande “homme sshd_config”. Si vous utilisez Ubuntu, s’il vous plaît assurez-vous que le paquet «openssh-server ‘est installé (il n’est pas installé par défaut).
[10] Tous les types de commutateurs de ligne de commande SSH peuvent être inclus (cité) dans le Rsync ‘-e’ interrupteur de commande en ligne, comme les connexions de port du serveur SSH non-standard (par exemple: “-p 2222″ si SSH écoute sur le port 2222 ), en plus de la clé privée («-i identity_file”) interrupteur. (Par Funke a suggéré que cette référence et http://mike-hostetler.com/blog/2007/12/rsync-non-standard-ssh-port).
[11] Vous pouvez trouver ce fichier journal SSH sera écrit par la recherche dans deux fichiers: / etc / ssh / sshd_config »et« / etc / syslog.conf. «sshd_config ‘contient le paramètre” SyslogFacility “, qui par défaut est réglé sur” AUTH “, mais Red Hat met généralement à” authpriv “. Quoi qu’il en soit, n’oubliez pas le réglage et le chercher dans le fichier “syslog.conf. Habituellement, vous trouverez une ligne avec «authpriv. *« Suivi par certains onglets, puis le fichier journal que vous recherchez. Ne faites pas attention aux lignes avec ‘authpriv.none’ en eux, car ils sont probaby prennent dans un de nombreux types de messages, mais rejetant ceux de l’installation de syslog ‘authpriv.
[12] Peu probable.

liens:

Comments are closed.