september 11, 2020
Articles
Geen reacties

rsync met verschillende gebruiker

Ik werk met twee ubuntu-instanties op AWS (die ik een pem-sleutel gebruik om ze te openen).

Ik heb rsync voor beide instanties ingesteld, en het werkt als ik de standaardgebruiker gebruik, ubuntu @ ipadres. Als ik rsync echter probeer te gebruiken met een andere gebruiker (ik typ sudo su - jenkins bijvoorbeeld of zelfs als ik sudo typ vóór het rsync-commando), dan krijg ik de volgende foutmelding. 

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]

Stappen die ik heb genomen:

Ik heb geprobeerd een ssh-sleutel te maken (met ssh-keygen) terwijl ik was ingelogd als jenkins en die aan de authorized_keys bestand in zowel /home/ubuntu/.ssh/authorized_keys (waar ik de rsync vanaf draai) en zelfs $JENKINS_HOME/.ssh/authorized_keys (waar ik vanaf daar ook rsync probeerde uit te voeren).

Ik heb zelfs geprobeerd de pem-sleutel te gebruiken om hetzelfde te doen en dat werkte ook niet.

Hier is wat ik “ik probeer uit te voeren

rsync -avuh --delete -e ssh jenkins@ipaddress:/var/lib/jenkins/* /var/lib/jenkins

En h ere “s met het sleutelbestand

rsync -avuh --delete -e "ssh -i path/to/key.pem" [email protected]:/var/lib/jenkins/* /var/lib/jenkins

PS: de enige reden waarom ik het niet wil uitvoeren met de ubuntu user is omdat ik failed: Permission denied (13) voor veel dingen krijg (aangezien de bestanden eigendom zijn van jenkins).

Einddoel:

I “Ik probeer constant een back-up te houden van de jenkins-instantie met de primaire instantie door een cronjob uit te voeren:

*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins

Opmerkingen

  • Heb je de ssh-key toegevoegd aan het geautoriseerde_keys-bestand van de remote hosts of op de server waarop je het rsync-commando uitvoert?
  • De vraag isn ‘ t vrij duidelijk. Bij elke rsync-run heb je een bron en een bestemming. Kunt u de bron- en doelsystemen verduidelijken? Voor het oplossen van problemen raad ik aan om gewoon ssh over rsync te gebruiken, omdat rsync ssh zal gebruiken. Probeer ssh -vvv jenkins @ < target > uit de bron te gebruiken en plak de uitvoer hier.
  • Ik krijg mislukt: toestemming geweigerd (13) voor veel dingen (aangezien de bestanden eigendom zijn van jenkins) Dus waarom zou je de rsync niet uitvoeren als de ” jenkins ” gebruiker?
  • Je schreef ik ‘ heb geprobeerd een ssh-sleutel te maken (met ssh-keygen) terwijl je bent ingelogd als jenkins en dat hebt toegevoegd aan het bestand Authorized_keys in /home/ubuntu/.ssh/authorized_keys (waarbij ik ‘ m de rsync vanaf) , maar je zou de sleutel moeten toevoegen aan het bestand Authorized_keys op het bestemmings systeem.

Answer

Ik weet dat het een oud bericht is, maar voor het geval het andere mensen kan helpen …

Je moet twee dingen onderscheiden:

  • wie brengt de SSH-verbinding tot stand .
  • welke externe gebruiker bezit de bestanden die je wilt kopiëren.

Overzicht 

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

Laten we zeggen dat u wilt rsync:

  • Van:
    • Machine: srcmachine
    • Gebruiker: srcuser
    • Directory: /var/lib/jenkins
  • Aan:
    • Machine: destmachine
    • Gebruiker: destuser om de SSH-verbinding tot stand te brengen .
    • Directory: /tmp
    • Uiteindelijke eigenaar van bestanden: jenkins.

Oplossing 

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

Uitleg 

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

De truc is om te vertellen om rsync op de externe machine uit te voeren met een andere gebruiker (jenkins) dan degene die de SSH-verbinding tot stand brengt (destuser).

Vereisten

SSH-toegang 

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

Vergeet niet de rechten op ~/.ssh te beperken : 

chmod 700 ~/.ssh

sudoer voor de destuser

De destuser moet het voorrecht hebben om sudo -u jenkins rsync te doen.

In het algemeen stellen we de destuser in als een lid van de sudoers. Om dit te doen, op de root @ destmachine: 

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

Om het te testen vóór rsync, kunt u inloggen op de destuser @ destmachine en uitvoeren this: 

sudo su jenkins echo $USER

Als het terugkeert: 

jenkins

betekent dit dat u bent ingelogd als jenkins gebruiker, en het betekent dat uw rsync -opdracht ook zal werken, omdat het privilege escaleren naar jenkins werkt.

Opmerking over een slechte oplossing: breng de SSH-verbinding tot stand met de bestemmingsgebruiker jenkins

Waarom niet ” doen we dit gewoon?

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

omdat jenkins een “service” -account is, wat betekent dat het een service uitvoert die een poort vrijgeeft (80 of zo) voor externe HTTP-toegang, en het betekent dat het MOGELIJK is dat er een beveiligingsinbreuk is via de Jenkins-service via HTTP om toegang te krijgen.

Daarom hebben we www-data gebruiker en soortgelijke om de verschillende services uit te voeren. Voor het geval ze gehackt worden vanuit de poorten die ze blootleggen, kunnen ze “niet veel doen:

  • alles is alleen-lezen voor hen.
  • behalve schrijven in /var/log/THE_SERVICE.

Dus toestaan SSH-toegang voor de jenkins -gebruiker legt een oppervlakte-aanval bloot (en zo is het voor SSH-toegang als root !!).

Bovendien, als je wilt rsyncen als een andere gebruiker (root, www-data, etc.), zou je je SSH-sleutel openbare sleutel voor die accounts (lastig).

Goede oplossing : je moet SSH-toegang zo min mogelijk instellen tot gebruikersaccounts (destuser) die KAN escaleren naar het “service” -account dat u wilt (jenkins, root, etc.).

Antwoord

Ik had een soortgelijk probleem met rsyncing als een andere gebruiker. Het is opgelost door het volgende commando uit te voeren: 

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

Houd er rekening mee dat je misschien met toetsen moet spelen om rsync als een andere gebruiker te kunnen uitvoeren.

Antwoord 

sudo -u jenkins -i rsync ...

met geen aanhalingstekens .

De -i optie zorgt ervoor dat het sudo commando wordt uitgevoerd met de omgeving van de gebruiker inclusief ssh-sleutels, .profile, .bash_profile etc.

Van de sudo man:

-i, --login

Voer de shell uit die is gespecificeerd door de wachtwoorddatabase van de doelgebruiker als een login-shell . Dit betekent dat inlogspecifieke bronbestanden zoals .profile, .bash_profile of .login worden gelezen door de shell. Als een commando is gespecificeerd, wordt het doorgegeven aan de shell voor uitvoering via de shell “s -c optie. Als er geen commando is opgegeven, wordt een interactieve shell uitgevoerd. sudo probeert naar de homedirectory van die gebruiker te gaan voordat de shell wordt uitgevoerd. De opdracht wordt uitgevoerd in een omgeving die lijkt op de omgeving die een gebruiker zou ontvangen bij het inloggen. Merk op dat de meeste shells gedragen zich anders wanneer een commando is gespecificeerd in vergelijking met een interactieve sessie, raadpleeg de shell-handleiding voor details. De sectie Opdrachtomgeving in de sudoers(5) handleiding documenteert hoe de optie -i de omgeving beïnvloedt waarin een opdracht wordt uitgevoerd wanneer het sudoers-beleid is ingesteld gebruik.

Antwoord

Ik heb een soortgelijk probleem.
I los dit op met cron. Maar cron moet draaien met een specifieke gebruiker (bijv: jenkins).

Maak gewoon cron job: 

$ crontab -u jenkins -e

vul dan cron met je behoefte. 

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

Reacties

  • Als de rsync is mislukt vanwege een authenticatieprobleem, hoe zal uw suggestie helpen?

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *