september 11, 2020
Articles
Ingen kommentarer

rsync med anden bruger

Jeg arbejder med to ubuntu-forekomster på AWS (som jeg bruger en pem-nøgle til at få adgang til dem).

Jeg opretter rsync til begge tilfælde, og det virker, hvis jeg bruger standardbrugeren, som er ubuntu @ ipaddress. Men hvis jeg prøver at bruge rsync med en anden bruger (jeg skriver sudo su - jenkins for eksempel eller endda skrive sudo før kommandoen rsync), så får jeg følgende fejl. 

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]

Trin, som jeg har taget:

Jeg har prøvet at oprette en ssh-nøgle (ved hjælp af ssh-keygen), mens jeg er logget ind som jenkins og tilføjede det til authorized_keys fil i både /home/ubuntu/.ssh/authorized_keys (hvor jeg kører rsync fra) og endda $JENKINS_HOME/.ssh/authorized_keys (hvor jeg også prøvede at køre rsync derfra).

Jeg prøvede endda at bruge pem-tasten til at gøre det samme, og det fungerede heller ikke.

Her er hvad jeg “Jeg prøver at køre

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

Og h ere er med nøglefilen

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

PS: Den eneste grund til, at jeg ikke vil køre det med ubuntu bruger skyldes, at jeg får failed: Permission denied (13) på mange ting (da filerne ejes af jenkins).

Slutmål:

I “Jeg forsøger at holde backup-jenkins-forekomsten sikkerhedskopieret konstant med den primære forekomst ved at udføre en cronjob:

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

Kommentarer

  • Føjede du ssh-nøglen til den eksterne værts autoriserede_keys-fil eller på den server, hvor du kører kommandoen rsync?
  • Spørgsmålet er ikke ‘ t helt klart. I hver rsync-kørsel har du en kilde og destination. Kan du afklare kilde- og destinationssystemerne? Til fejlfindingsformål anbefaler jeg at holde med bare ssh over rsync, fordi rsync bruger ssh. Prøv at bruge ssh -vvv jenkins @ < target > fra kilden og indsætte output her.
  • Jeg bliver mislykket: Tilladelse nægtet (13) på mange ting (da filerne ejes af jenkins) Så hvorfor ikke udføre rsync som ” jenkins ” bruger?
  • Du skrev Jeg ‘ har prøvet at oprette en ssh-nøgle (ved hjælp af ssh-keygen) mens du er logget ind som jenkins og tilføjede det til den autoriserede_keys-fil i begge /home/ubuntu/.ssh/authorized_keys (hvor jeg ‘ kører rsync fra) , men du skal tilføje nøglen til filen authorised_keys på destinationen -systemet.

Svar

Jeg ved, det er et gammelt indlæg, men bare hvis det kan hjælpe andre mennesker …

Du skal skelne mellem to ting:

  • hvem opretter SSH-forbindelsen .
  • hvilken fjernbruger ejer de filer , som du vil kopiere.

Oversigt 

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

Lad os sige, at du vil rsync:

  • Fra:
    • Maskine: srcmachine
    • Bruger: srcuser
    • Directory: /var/lib/jenkins
  • Til:
    • Maskine: destmachine
    • Bruger: destuser til etabler SSH-forbindelsen .
    • Directory: /tmp
    • Ejer af endelige filer: jenkins.

Løsning 

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

Forklaringer 

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

Tricket er at fortælle at køre rsync på fjernmaskinen med en anden bruger (jenkins) end den, der opretter SSH-forbindelsen (destuser).

Krav

SSH-adgang 

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

Glem ikke at begrænse tilladelser til ~/.ssh : 

chmod 700 ~/.ssh

sudoer til destuser

destuser skal have privilegiet at gøre sudo -u jenkins rsync.

Generelt indstiller vi destuser et medlem af sudoers. For at gøre dette skal du på root @ destmachine: 

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

For at teste det før rsync, kan du logge på destuser @ destmachine dette: 

sudo su jenkins echo $USER

Hvis det returnerer: 

jenkins

betyder det, at du er logget som jenkins bruger, og det betyder, at din rsync kommando også fungerer, fordi eskaladeprivilegiet til jenkins fungerer.

Bemærk om en dårlig løsning: Opret SSH-forbindelsen med destinationsbrugeren jenkins

Hvorfor don ” gør vi bare dette?

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

fordi jenkins er en “service” -konto, hvilket betyder at den kører en tjeneste, der udsætter en port (80 eller deromkring) til ekstern HTTP-adgang, og det betyder, at det er MULIG, at der er et sikkerhedsbrud gennem Jenkins-tjenesten via HTTP for at få adgang.

Derfor har vi www-data bruger og lignende til at køre de forskellige tjenester. Hvis de bliver hacket fra de porte, de udsætter, kan de ikke gøre meget:

  • alt er skrivebeskyttet for dem.
  • undtagen at skrive i /var/log/THE_SERVICE.

Så tillader SSH-adgang til jenkins brugeren udsætter et overfladeangreb (og det er således for SSH-adgang som root !!).

Hvis du desuden vil rsync som en anden bruger (root, www-data osv.), skal du kopiere din SSH-nøgle offentlig nøgle til disse konti (besværlig).

God løsning : Du skal indstille SSH-adgang så få som muligt til brugerkonti (destuser) at KAN eskalere til den “service” -konto, du vil have (jenkins, root osv.).

Svar

Jeg havde et lignende problem med rsyncing som en anden bruger. Løst ved at køre næste kommando: 

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

Bemærk, at du måske bliver nødt til at spille med taster for at kunne køre rsync som en anden bruger.

Svar 

sudo -u jenkins -i rsync ...

med ingen citater .

Indstillingen -i gør sudo kommandoen kørt med brugerens miljø inklusive ssh-nøgler, .profile, .bash_profile osv.

Fra sudo mand:

-i, --login

Kør den shell, der er angivet af målbrugerens adgangskodedatabaseindgang som en login-shell Dette betyder, at login-specifikke ressourcefiler som .profile, .bash_profile eller .login læses af skallen. Hvis en kommando er specificeret, sendes den til skallen til udførelse via skallen “s -c. Hvis der ikke er angivet nogen kommando, udføres en interaktiv skal. sudo forsøger at skifte til brugerens hjemmekatalog, før kørslen køres. Kommandoen køres i et miljø svarende til det, en bruger ville modtage ved log ind. Bemærk, at de fleste skaller opfører sig anderledes, når en kommando er specificeret sammenlignet med en interaktiv session; se shellhåndbogen for detaljer. Sektionen Kommandomiljø i sudoers(5) manualen dokumenterer, hvordan indstillingen -i påvirker det miljø, hvor en kommando køres, når sudoers-politikken er i brug.

Svar

Jeg har et lignende problem.
I løse dette ved hjælp af cron. Men cron skal køre med en bestemt bruger (f.eks: jenkins)

Lav bare cron-job: 

$ crontab -u jenkins -e

og udfyld derefter cron med dit behov. 

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

Kommentarer

  • Hvis rsync er mislykkedes på grund af et godkendelsesproblem, hvordan hjælper dit forslag?

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *