Știu că este o postare veche, dar în caz că poate ajuta alte persoane …

Trebuie să diferențiați 2 lucruri:

• cine stabilește conexiunea SSH .
• care utilizator la distanță deține fișierele pe care doriți să le copiați.

Prezentare generală

(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser | | sudo su jenkins | v jenkins 

Să spunem că doriți să sincronizați:

• De la:
  • Mașină: srcmachine
  • Utilizator: srcuser
  • Director: /var/lib/jenkins
• Către:
  • Mașină: destmachine
  • Utilizator: destuser pentru a stabili conexiunea SSH .
  • Director: /tmp
  • Proprietarul fișierului final: jenkins.

Soluție

rsync --rsync-path "sudo -u jenkins rsync" -avP --delete /var/lib/jenkins destuser@destmachine:/tmp 

Explicații

 --rsync-path=PROGRAM specify the rsync to run on the remote machine 

Trucul este de spus pentru a rula rsync pe computerul la distanță cu un alt utilizator (jenkins) decât cel care stabilește conexiunea SSH (destuser).

Cerințe

Acces SSH

(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub] 

Nu uitați să restricționați permisiunile pentru ~/.ssh :

chmod 700 ~/.ssh 

sudoer pentru destuser

destuser trebuie să aibă privilegiul de a face sudo -u jenkins rsync.

În general, setăm destuser ca un membru al sudoers. Pentru a face acest lucru, pe root @ destmachine:

cat > /etc/sudoers.d/destuser << EOF destuser ALL=(ALL) NOPASSWD:ALL EOF 

Pentru a-l testa înainte de rsync, vă puteți conecta la destuser @ destmachine și puteți rula aceasta:

sudo su jenkins echo $USER 

Dacă revine:

jenkins 

înseamnă că sunteți conectat ca jenkins utilizator și înseamnă că comanda dvs. rsync va funcționa la fel, deoarece privilegiul escaladei la jenkins funcționează.

Notă despre o soluție greșită: stabiliți conexiunea SSH cu utilizatorul de destinație jenkins

De ce să nu ” noi doar facem asta?

(srcmachine) (rsync) (destmachine) srcuser -- SSH --> jenkins [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub] 

deoarece jenkins este un cont de „serviciu”, ceea ce înseamnă că rulează un serviciu care expune un port (80 aproximativ) pentru acces HTTP extern și înseamnă că este POSIBIL să existe o încălcare a securității prin intermediul serviciului Jenkins peste HTTP pentru a avea acces.

De aceea avem www-data utilizator și similare pentru a rula diferitele servicii. În cazul în care sunt pirate din porturile pe care le expun, nu pot face multe:

• totul este doar pentru citire pentru ei.
• cu excepția scrierii în /var/log/THE_SERVICE.

Permițând astfel Accesul SSH pentru utilizatorul jenkins expune un atac de suprafață (și așa este pentru accesul SSH ca root !!).

Mai mult, dacă doriți să rsync ca alt utilizator (root, www-data etc.), va trebui să copiați Cheie publică cheie SSH pentru acele conturi (supărătoare).

Soluție bună : ar trebui să setați acces SSH cât mai puțin posibil la conturile de utilizator (destuser) care POATE escalada la contul de „serviciu” pe care îl doriți (jenkins, root etc.).

Am avut o problemă similară cu rsyncing ca un alt utilizator. A rezolvat-o executând următoarea comandă:

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 

Vă rugăm să rețineți că poate va trebui să jucați cu tastele pentru a putea rula rsync ca alt utilizator.

sudo -u jenkins -i rsync ... 

cu fără ghilimele .

Opțiunea -i face ca comanda sudo să ruleze cu mediul utilizatorului, inclusiv cheile ssh, .profile, .bash_profile etc.

De la sudo om:

-i, --login

Rulați shell-ul specificat de intrarea bazei de date a parolei utilizatorului țintă ca shell de conectare . Aceasta înseamnă că fișierele de resurse specifice autentificării, cum ar fi .profile, .bash_profile sau .login să fie citit de shell. Dacă este specificată o comandă, aceasta este transmisă shell-ului pentru executare prin opțiunea shell „s -c. Dacă nu este specificată nicio comandă, se execută un shell interactiv. sudo încearcă să se schimbe în directorul de acasă al acelui utilizator înainte de a rula shell-ul. Comanda este executată cu un mediu similar celui pe care un utilizator l-ar primi la conectare. Rețineți că majoritatea shell-urilor comportați-vă diferit atunci când este specificată o comandă în comparație cu o sesiune interactivă; consultați manualul shell-ului pentru detalii. Secțiunea Mediu de comandă din manualul sudoers(5) documentează modul în care opțiunea -i afectează mediul în care se execută o comandă atunci când se află politica sudoers utilizați.

Am o problemă similară.
I rezolva acest lucru folosind cron. Dar cron trebuie să ruleze cu un anumit utilizator (ex: jenkins)

Doar faceți cron job:

$ crontab -u jenkins -e 

apoi completați cron cu nevoile dvs.

*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log 

Comentarii

• Dacă rsync este nu a reușit din cauza unei probleme de autentificare cum vă va ajuta sugestia?