september 11, 2020
Articles
Ingen kommentarer

rsync med annen bruker

Jeg jobber med to ubuntu-forekomster på AWS (som jeg bruker en pem-nøkkel for å få tilgang til dem).

Jeg setter opp rsync for begge tilfeller, og det fungerer hvis jeg bruker standardbrukeren som er ubuntu @ ipaddress. Men hvis jeg prøver å bruke rsync med en annen bruker (jeg skriver sudo su - jenkins for eksempel eller til og med å skrive sudo før rsync-kommandoen), så får jeg følgende feil. 

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]

Fremgangsmåte som jeg har tatt:

Jeg har prøvd å lage en ssh-nøkkel (ved hjelp av ssh-keygen) mens jeg er logget inn som jenkins og la det til i authorized_keys fil i både /home/ubuntu/.ssh/authorized_keys (der jeg kjører rsync fra) og til og med $JENKINS_HOME/.ssh/authorized_keys (der jeg prøvde å kjøre rsync derfra også).

Jeg prøvde til og med å bruke pem-tasten til å gjøre det samme, og det fungerte heller ikke.

Her er hva jeg «Jeg prøver å løpe

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

Og h ere er med nøkkelfilen

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

PS: Den eneste grunnen til at jeg ikke vil kjøre den med ubuntu brukeren er fordi jeg får failed: Permission denied (13) på mange ting (siden filene eies av jenkins).

Sluttmål:

Jeg «Jeg prøver å holde backup-jenkins-forekomsten sikkerhetskopiert hele tiden med den primære forekomsten ved å gjøre en cronjob:

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

Kommentarer

  • Har du lagt til ssh-nøkkelen i den eksterne verten autoriserte_keys-filen eller på serveren der du kjører kommandoen rsync?
  • Spørsmålet er ikke ‘ t helt klart. I hver rsync-kjøring har du en kilde og destinasjon. Kan du avklare kilde- og destinasjonssystemene? For feilsøkingsformål anbefaler jeg å holde med bare ssh over rsync, fordi rsync vil bruke ssh. Prøv å bruke ssh -vvv jenkins @ < target > fra kilden og lime utgangen her.
  • Jeg mislyktes: Tillatelse nektet (13) for mange ting (siden filene eies av jenkins) Så hvorfor ikke utføre rsync som » jenkins » bruker?
  • Du skrev Jeg ‘ har prøvd å lage en ssh-nøkkel (ved hjelp av ssh-keygen) mens du er logget på som jenkins og la det til i autoriserte_keys-filen i begge /home/ubuntu/.ssh/authorized_keys (der jeg ‘ kjører rsync fra) , men du bør legge til nøkkelen til filen authorised_keys på destinasjon -systemet.

Svar

Jeg vet at det er et gammelt innlegg, men bare hvis det kan hjelpe andre mennesker …

Du må skille mellom to ting:

  • hvem oppretter SSH-tilkoblingen .
  • hvilken ekstern bruker som eier filene som du vil kopiere.

Oversikt 

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

La oss si at du vil rsynkronisere:

  • Fra:
    • Maskin: srcmachine
    • Bruker: srcuser
    • Katalog: /var/lib/jenkins
  • Til:
    • Maskin: destmachine
    • Bruker: destuser til etabler SSH-tilkoblingen .
    • Katalog: /tmp
    • Eier av 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

Trikset er å fortelle å kjøre rsync på den eksterne maskinen med en annen bruker (jenkins) enn den som oppretter SSH-forbindelsen (destuser).

Krav

SSH-tilgang 

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

Ikke glem å begrense tillatelser for ~/.ssh : 

chmod 700 ~/.ssh

sudoer for destuser

destuser må ha privilegiet å gjøre sudo -u jenkins rsync.

Generelt sett setter vi destuser et medlem av sudoers. For å gjøre dette, på root @ destmachine: 

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

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

sudo su jenkins echo $USER

Hvis det returnerer: 

jenkins

betyr det at du er logget som jenkins bruker, og det betyr at rsync -kommandoen din vil fungere også, fordi eskaladeprivilegiet til jenkins fungerer.

Merk om en dårlig løsning: opprett SSH-forbindelsen med destinasjonsbrukeren jenkins

Hvorfor ikke » gjø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, som betyr at den kjører en tjeneste som avslører en port (80 eller så) for ekstern HTTP-tilgang, og det betyr at det er MULIG at det er et sikkerhetsbrudd gjennom Jenkins-tjenesten over HTTP for å få tilgang.

Derfor har vi www-data bruker og lignelser til å kjøre de forskjellige tjenestene. I tilfelle de blir hacket fra portene de utsetter, kan de ikke gjøre mye:

  • alt er skrivebeskyttet for dem.
  • bortsett fra å skrive i /var/log/THE_SERVICE.

Så tillater SSH-tilgang for jenkins brukeren utsetter et overflateangrep (og slik er det for SSH-tilgang som root !!).

Hvis du dessuten vil synkronisere som en annen bruker (root, www-data osv.), må du kopiere SSH-nøkkel offentlig nøkkel til disse kontoene (plagsom).

God løsning : Du bør angi SSH-tilgang så få som mulig til brukerkontoer (destuser) at KAN eskalere til «tjenestekontoen» du vil ha (jenkins, root osv.).

Svar

Jeg hadde et lignende problem med rsyncing som en annen bruker. Løste det ved å kjøre neste 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

Vær oppmerksom på at du kanskje må spille med nøkler for å kunne kjøre rsync som en annen bruker.

Svar 

sudo -u jenkins -i rsync ...

med ingen anførselstegn .

Alternativet -i gjør sudo -kommandoen med brukerens miljø inkludert ssh-nøkler, .profile, .bash_profile osv.

Fra sudo mannen:

-i, --login

Kjør skallet som er angitt av målbrukerens passorddatabaseoppføring som et påloggingsskall Dette betyr at påloggingsspesifikke ressursfiler som .profile, .bash_profile eller .login leses av skallet. Hvis en kommando er spesifisert, overføres den til skallet for utføring via skallet «s -c. Hvis ingen kommando er spesifisert, utføres et interaktivt skall. sudo prøver å bytte til brukerens hjemmekatalog før du kjører skallet. Kommandoen kjøres i et miljø som ligner på det en bruker ville mottatt ved pålogging. Merk at de fleste skjell oppføre seg annerledes når en kommando er spesifisert i forhold til en interaktiv økt, se skallhåndboken for detaljer. Seksjonen Kommandomiljø i sudoers(5) manualen dokumenterer hvordan alternativet -i påvirker miljøet der en kommando kjøres når sudoers-politikken er i bruk.

Svar

Jeg har lignende problem.
I løse dette ved hjelp av cron. Men cron må kjøre med spesifikk bruker (eks: jenkins)

Bare lag cron-jobb: 

$ crontab -u jenkins -e

og fyll cron med ditt behov. 

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

Kommentarer

  • Hvis rsync er mislyktes på grunn av et autentiseringsproblem. Hvordan vil forslaget ditt hjelpe?

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *