Je « travaille avec deux instances ubuntu sur AWS (à laquelle jutilise une clé pem pour y accéder).
Jai configuré rsync pour les deux instances, et cela fonctionne si jutilise lutilisateur par défaut qui est ubuntu @ ipaddress. Cependant, si jessaye dutiliser rsync avec un autre utilisateur (je « m tape sudo su - jenkins par exemple ou même en tapant sudo avant la commande rsync), alors jobtiens lerreur suivante.
Permission denied (publickey). rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.0] Étapes que jai suivies:
Jai essayé de créer une clé ssh (en utilisant ssh-keygen) en étant connecté en tant que jenkins et je lai ajoutée à authorized_keys fichier à la fois dans /home/ubuntu/.ssh/authorized_keys (où i « m exécute la rsync à partir de) et même $JENKINS_HOME/.ssh/authorized_keys (où jai essayé dexécuter rsync à partir de là aussi).
Jai même essayé dutiliser la touche pem pour faire la même chose et cela na pas fonctionné non plus.
Voici ce que jai « Jessaye de courir
rsync -avuh --delete -e ssh jenkins@ipaddress:/var/lib/jenkins/* /var/lib/jenkins
Et h ere « s avec le fichier clé
rsync -avuh --delete -e "ssh -i path/to/key.pem" [email protected]:/var/lib/jenkins/* /var/lib/jenkins
PS: La seule raison pour laquelle je ne veux pas lexécuter avec ubuntu lutilisateur est parce que jobtiens failed: Permission denied (13) sur beaucoup de choses (puisque les fichiers appartiennent à jenkins).
Objectif final:
I « Jessaie de garder linstance de sauvegarde jenkins constamment sauvegardée avec linstance principale en effectuant un cronjob:
*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins
Commentaires
- Avez-vous ajouté la clé ssh sur le fichier des hôtes distants allowed_keys ou sur le serveur sur lequel vous exécutez la commande rsync?
- La question nest pas ‘ t assez clair. Dans chaque exécution de rsync, vous avez une source et une destination. Pouvez-vous clarifier les systèmes source et de destination? À des fins de dépannage, je recommande de sen tenir uniquement à ssh sur rsync, car rsync utilisera ssh. Essayez dutiliser ssh -vvv jenkins @ < target > à partir de la source et collez la sortie ici.
- Jai échoué: Permission refusée (13) sur beaucoup de choses (puisque les fichiers appartiennent à jenkins) Alors pourquoi ne pas effectuer la rsync comme » jenkins » user?
- Vous avez écrit Jai ‘ essayé de créer une clé ssh (en utilisant ssh-keygen) tout en étant connecté en tant que jenkins et ajouté cela au fichier allowed_keys dans les deux /home/ubuntu/.ssh/authorized_keys (où je ‘ m exécutant la rsync à partir de) , mais vous devriez ajouter la clé au fichier allowed_keys sur le système destination .
Réponse
Je sais que cest un ancien message, mais juste au cas où cela pourrait aider dautres personnes …
Vous devez différencier 2 choses:
- qui établit la connexion SSH .
- quel utilisateur distant possède les fichiers que vous souhaitez copier.
Présentation
(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser | | sudo su jenkins | v jenkins Disons que vous voulez rsync:
- De:
- Machine:
srcmachine - Utilisateur:
srcuser - Répertoire:
/var/lib/jenkins
- Machine:
- À:
- Machine:
destmachine - Utilisateur:
destuserà établir la connexion SSH . - Répertoire:
/tmp - Propriétaire des fichiers finaux:
jenkins.
- Machine:
Solution
rsync --rsync-path "sudo -u jenkins rsync" -avP --delete /var/lib/jenkins destuser@destmachine:/tmp Explications
--rsync-path=PROGRAM specify the rsync to run on the remote machine Lastuce est de dire pour exécuter rsync sur la machine distante avec un autre utilisateur (jenkins) que celui qui établit la connexion SSH (destuser).
Conditions requises
Accès SSH
(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub] Noubliez pas de restreindre les autorisations sur ~/.ssh :
chmod 700 ~/.ssh sudoer pour le destuser
Le destuser doit avoir le privilège de faire sudo -u jenkins rsync.
En général, nous définissons destuser comme un membre de sudoers. Pour ce faire, sur le root @ destmachine:
cat > /etc/sudoers.d/destuser << EOF destuser ALL=(ALL) NOPASSWD:ALL EOF Pour le tester avant rsync, vous pouvez vous connecter à destuser @ destmachine et exécuter ceci:
sudo su jenkins echo $USER Sil renvoie:
jenkins cela signifie que vous êtes connecté en tant quutilisateur jenkins, et cela signifie que votre commande rsync fonctionnera également, car le privilège délever à jenkins fonctionne.
Remarque sur une mauvaise solution: établissez la connexion SSH avec lutilisateur de destination jenkins
Pourquoi ne pas » on fait juste ça?
(srcmachine) (rsync) (destmachine) srcuser -- SSH --> jenkins [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub] car jenkins est un compte « service », ce qui signifie quil exécute un service qui expose un port (80 environ) pour un accès HTTP externe, et cela signifie quil est POSSIBLE quil y ait une faille de sécurité via le service Jenkins via HTTP pour y accéder.
Cest pourquoi nous avons www-data utilisateurs et similaires pour exécuter les différents services. Au cas où ils seraient piratés à partir des ports quils exposent, ils ne peuvent « pas faire grand chose:
- tout est en lecture seule pour eux.
- sauf lécriture en
/var/log/THE_SERVICE.
Donc Laccès SSH pour lutilisateur jenkins expose une attaque de surface (et il en va de même pour laccès SSH en tant que root !!).
De plus, si vous voulez rsync en tant quun autre utilisateur (root, www-data, etc.), vous devrez copier votre Clé publique SSH pour ces comptes (problématique).
Bonne solution : vous devez définir laccès SSH aussi peu que possible aux comptes utilisateurs (destuser) qui PEUT escalader en le compte « service » souhaité (jenkins, root, etc.).
Réponse
Jai eu un problème similaire avec rsyncing en tant quautre utilisateur. Résolu le problème en exécutant la commande suivante:
rsync -avu -e "ssh -i my-key -o StrictHostKeyChecking=no -l user-i-want-to-use-in-rsync" ./local_dir remote_host:remote-host-dir Veuillez noter que vous devrez peut-être jouer avec les touches pour pouvoir exécuter rsync en tant quautre utilisateur.
Réponse
sudo -u jenkins -i rsync ... avec sans guillemets .
Loption -i fait exécuter la commande sudo avec lenvironnement de lutilisateur, y compris les clés ssh, .profile, .bash_profile etc.
De lhomme sudo:
-i, --loginExécutez le shell spécifié par lentrée de la base de données de mots de passe de lutilisateur cible comme shell de connexion . Cela signifie que les fichiers de ressources spécifiques à la connexion, tels que
.profile,.bash_profileou.loginêtre lue par le shell. Si une commande est spécifiée, elle est passée au shell pour exécution via loption shell « s-c. Si aucune commande nest spécifiée, un shell interactif est exécuté.sudotente de passer au répertoire de base de cet utilisateur avant dexécuter le shell. La commande est exécutée avec un environnement similaire à celui quun utilisateur recevrait lors de la connexion. Notez que la plupart des shells se comportent différemment lorsquune commande est spécifiée par rapport à une session interactive, consultez le manuel du shell pour plus de détails. La section Environnement de commande du manuelsudoers(5)décrit comment loption-iaffecte lenvironnement dans lequel une commande est exécutée lorsque la stratégie sudoers est en cours utiliser.
Réponse
Jai un problème similaire.
I résolvez ceci en utilisant cron. Mais cron doit fonctionner avec un utilisateur spécifique (ex: jenkins)
Il suffit de faire cron job:
$ crontab -u jenkins -e puis de remplir cron avec votre besoin.
*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log Commentaires
- Si
rsyncest échec en raison dun problème dauthentification, comment votre suggestion vous aidera-t-elle?