september 11, 2020
Articles
Inga kommentarer

rsync med olika användare

Jag arbetar med två ubuntu-instanser på AWS (som jag använder en pem-nyckel för att komma åt dem).

Jag ställer in rsync för båda instanser, och det fungerar om jag använder standardanvändaren som är ubuntu @ ipaddress. Men om jag försöker använda rsync med en annan användare (jag skriver sudo su - jenkins till exempel eller till och med att skriva sudo före kommandot rsync), då får jag följande fel. 

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]

Steg som jag har tagit:

Jag har försökt skapa en ssh-nyckel (med ssh-keygen) medan jag är inloggad som jenkins och lade till det i authorized_keys -fil i både /home/ubuntu/.ssh/authorized_keys (där jag kör rsync från) och till och med $JENKINS_HOME/.ssh/authorized_keys (där jag försökte köra rsync därifrån också).

Jag försökte till och med använda pem-tangenten för att göra samma sak och det fungerade inte heller.

Här är vad jag ”jag försöker köra

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

Och h innan ”med nyckelfilen

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

PS: Den enda anledningen till att jag inte vill köra den med ubuntu användare beror på att jag får failed: Permission denied (13) på många saker (eftersom filerna ägs av jenkins).

Slutmål:

I ”jag försöker hålla säkerhetskopian av jenkins-instansen säkerhetskopierad konstant med den primära instansen genom att göra en cronjob:

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

Kommentarer

  • Har du lagt till ssh-nyckeln i filen fjärrvärden autoriserade_key eller på servern där du kör kommandot rsync?
  • Frågan är inte ’ t helt klart. I varje rsync-körning har du en källa och en destination. Kan du klargöra käll- och destinationssystem? För felsökningsändamål rekommenderar jag att du håller med bara ssh över rsync, eftersom rsync använder ssh. Försök använda ssh -vvv jenkins @ < target > från källan och klistra in utmatningen här.
  • Jag misslyckades: Tillstånd nekad (13) för många saker (eftersom filerna ägs av jenkins) Så varför inte utföra rsync som ” jenkins ” användare?
  • Du skrev Jag ’ har försökt skapa en ssh-nyckel (med ssh-keygen) medan du är inloggad som jenkins och lade till den i filen authorised_keys i båda /home/ubuntu/.ssh/authorized_keys (där jag ’ jag kör rsync från) , men du bör lägga till nyckeln till filen authorised_keys på destination -systemet.

Svar

Jag vet att det är ett gammalt inlägg, men bara om det kan hjälpa andra människor …

Du måste skilja på två saker:

  • vem skapar SSH-anslutningen .
  • vilken fjärranvändare äger filerna som du vill kopiera.

Översikt 

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

Låt oss säga att du vill rsync:

  • Från:
    • Maskin: srcmachine
    • Användare: srcuser
    • Katalog: /var/lib/jenkins
  • Till:
    • Maskin: destmachine
    • Användare: destuser till upprätta SSH-anslutningen .
    • Katalog: /tmp
    • Slutliga filägare: jenkins.

Lösning 

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

Förklaringar 

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

Tricket är att berätta att köra rsync på fjärrmaskinen med en annan användare (jenkins) än den som upprättar SSH-anslutningen (destuser).

Krav

SSH-åtkomst 

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

Glöm inte att begränsa behörigheter på ~/.ssh : 

chmod 700 ~/.ssh

sudoer för destuser

destuser måste ha privilegiet att göra sudo -u jenkins rsync.

I allmänhet ställer vi in destuser en medlem av sudoers. För att göra detta, på root @ destmachine: 

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

För att testa det före rsync kan du logga in på destuser @ destmachine detta: 

sudo su jenkins echo $USER

Om det returnerar: 

jenkins

betyder det att du är inloggad som jenkins -användare, och det betyder att ditt rsync -kommando fungerar också, eftersom escalade-privilegiet till jenkins fungerar.

Anmärkning om en dålig lösning: upprätta SSH-anslutningen med målanvändaren jenkins

Varför inte ” gör vi bara det här?

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

eftersom jenkins är ett ”service” -konto, vilket innebär att den kör en tjänst som exponerar en port (80 eller så) för extern HTTP-åtkomst, och det betyder att det är MÖJLIG att det finns en säkerhetsöverträdelse genom Jenkins-tjänsten via HTTP för att få åtkomst.

Därför har vi www-data användare och liknande för att köra de olika tjänsterna. Om de blir hackade från de portar de exponerar kan de inte göra mycket:

  • allt är skrivskyddat för dem.
  • utom att skriva i /var/log/THE_SERVICE.

Så tillåter SSH-åtkomst för jenkins -användaren exponerar en ytattack (och så är det för SSH-åtkomst som root !!).

Dessutom, om du vill rsync som en annan användare (root, www-data, etc.), måste du kopiera din SSH-nyckel offentlig nyckel till dessa konton (besvärande).

Bra lösning : Du bör ställa in SSH-åtkomst så få som möjligt till användarkonton (destuser) att KAN eskalera till det ”tjänst” -konto du vill ha (jenkins, root, etc.).

Svar

Jag hade ett liknande problem med rsyncing som en annan användare. Löste det genom att köra nästa 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

Observera att du kanske måste spela med tangenter för att kunna köra rsync som en annan användare.

Svar 

sudo -u jenkins -i rsync ...

med inga citat .

Alternativet -i gör att kommandot sudo körs med användarens miljö inklusive ssh-tangenter, .profile, .bash_profile etc.

Från sudo mannen:

-i, --login

Kör skalet som anges av målanvändarens lösenordsdatabaspost som inloggningsskal Detta innebär att inloggningsspecifika resursfiler som .profile, .bash_profile eller .login läsas av skalet. Om ett kommando specificeras skickas det till skalet för körning via skalet ”s -c. Om inget kommando anges, körs ett interaktivt skal. sudo försöker ändra till den användarens hemkatalog innan skalet körs. Kommandot körs i en miljö som liknar den som en användare skulle få vid inloggning. Observera att de flesta skalen beter sig annorlunda när ett kommando anges jämfört med en interaktiv session, se shell-handboken för mer information. Avsnittet Kommandomiljön i sudoers(5) handboken dokumenterar hur alternativet -i påverkar den miljö där ett kommando körs när sudoers-policyn finns använd.

Svar

Jag har liknande problem.
I lösa detta med cron. Men cron måste köras med specifik användare (ex: jenkins)

Gör bara cron-jobb: 

$ crontab -u jenkins -e

och fyll sedan cron med ditt behov. 

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

Kommentarer

  • Om rsync är misslyckades på grund av ett autentiseringsproblem hur hjälper ditt förslag?

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *