11 września, 2020
Articles
Brak komentarzy

rsync z innym użytkownikiem

Pracuję z dwoma instancjami ubuntu w AWS (do których używam klucza PEM, aby uzyskać do nich dostęp).

Skonfigurowałem rsync dla obu instancji i działa, jeśli używam domyślnego użytkownika, którym jest ubuntu @ ipaddress. Jeśli jednak spróbuję użyć rsync z innym użytkownikiem (piszę sudo su - jenkins na przykład lub nawet wpisując sudo przed poleceniem rsync), pojawia się następujący błąd. 

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]

Kroki, które podjąłem:

Próbowałem utworzyć klucz ssh (używając ssh-keygen) będąc zalogowanym jako jenkins i dodałem go do authorized_keys plik w obu /home/ubuntu/.ssh/authorized_keys (gdzie i „m uruchamiam rsync z), a nawet $JENKINS_HOME/.ssh/authorized_keys (gdzie również próbowałem uruchomić rsync z tego miejsca).

Próbowałem nawet użyć klucza pem do zrobienia tego samego i to też nie zadziałało.

Oto, co ja „m próbuję uruchomić

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

I h Ere „s z plikiem klucza

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

PS: Jedyny powód, dla którego nie chcę go uruchamiać z ubuntu user jest ponieważ otrzymuję failed: Permission denied (13) z wielu rzeczy (ponieważ pliki są własnością jenkinsa).

Cel końcowy:

I „m próbuję utrzymać kopię zapasową instancji Jenkinsa w ciągłym tworzeniu kopii zapasowej instancji podstawowej, wykonując cronjob:

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

Komentarze

  • Czy dodałeś klucz ssh w pliku kluczy autoryzowanych hostów zdalnych lub na serwerze, na którym uruchamiasz polecenie rsync?
  • Pytanie brzmi: nie ' t całkiem jasne. W każdym uruchomieniu rsync masz źródło i miejsce docelowe. Czy możesz wyjaśnić systemy źródłowe i docelowe? Dla celów rozwiązywania problemów zalecam trzymanie się po prostu ssh zamiast rsync, ponieważ rsync użyje ssh. Spróbuj użyć ssh -vvv jenkins @ < target > ze źródła i wkleić tutaj wynik.
  • Błąd: odmowa uprawnień (13) na wiele rzeczy (ponieważ pliki są własnością jenkinsa) Dlaczego więc nie wykonać rsync jako ” jenkins ” użytkownik?
  • Napisałeś I ' próbowałeś utworzyć klucz ssh (używając ssh-keygen) będąc zalogowanym jako jenkins i dodając to do pliku allowed_keys w obu /home/ubuntu/.ssh/authorized_keys (gdzie i ' m uruchamiam rsync z) , ale powinieneś dodawać klucz do pliku authorised_keys w systemie docelowym .

Odpowiedź

Wiem, że to stary post, ale na wszelki wypadek, gdyby mógł pomóc innym …

Musisz rozróżnić dwie rzeczy:

  • kto ustanawia połączenie SSH .
  • który użytkownik zdalny jest właścicielem plików , które chcesz skopiować.

Przegląd 

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

Powiedzmy, że chcesz wykonać rsync:

  • From:
    • Machine: srcmachine
    • Użytkownik: srcuser
    • Katalog: /var/lib/jenkins
  • Do:
    • Maszyna: destmachine
    • Użytkownik: destuser do nawiąż połączenie SSH .
    • Katalog: /tmp
    • Właściciel plików końcowych: jenkins.

Rozwiązanie 

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

Wyjaśnienia 

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

Sztuczka polega na tym, aby powiedzieć do uruchomienia rsync na zdalnym komputerze z innym użytkownikiem (jenkins) niż ten, który nawiązuje połączenie SSH (destuser).

Wymagania

Dostęp SSH 

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

Nie zapomnij ograniczyć uprawnień do ~/.ssh : 

chmod 700 ~/.ssh

sudoer dla destuser

destuser musi mieć uprawnienie do wykonywania sudo -u jenkins rsync.

Ogólnie rzecz biorąc, ustawiamy destuser jako członkiem grupy sudoers. Aby to zrobić, na root @ destmachine: 

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

Aby przetestować go przed rsync, możesz zalogować się na destuser @ destmachine i uruchomić to: 

sudo su jenkins echo $USER

Jeśli zwróci: 

jenkins

oznacza to, że jesteś zalogowany jako użytkownika jenkins, co oznacza, że polecenie rsync również będzie działać, ponieważ uprawnienie eskalacji do jenkins działa.

Uwaga o złym rozwiązaniu: ustanów połączenie SSH z użytkownikiem docelowym jenkins

Dlaczego nie ” czy po prostu to robimy?

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

ponieważ jenkins jest kontem „usługi”, co oznacza, że uruchamia usługę, która ujawnia port (80 lub coś podobnego) dla zewnętrznego dostępu HTTP, a to oznacza, że jest MOŻLIWE, że istnieje naruszenie bezpieczeństwa przez usługę Jenkins przez HTTP w celu uzyskania dostępu.

Dlatego właśnie mamy www-data użytkownika i podobieństwa do uruchamiania różnych usług. W przypadku włamania na porty, które ujawniają, nie mogą zrobić zbyt wiele:

  • wszystko jest dla nich tylko do odczytu.
  • oprócz pisania w /var/log/THE_SERVICE.

Pozwalając Dostęp SSH dla użytkownika jenkins naraża na atak powierzchniowy (i tak jest w przypadku dostępu SSH jako root !!).

Ponadto, jeśli chcesz wykonać rsync jako inny użytkownik (root, www-data itp.), musisz skopiować Klucz publiczny SSH do tych kont (kłopotliwe).

Dobre rozwiązanie : Powinieneś ustawić dostęp SSH do kont użytkowników jak najmniej (destuser), które MOŻE eskaladować do konto „service”, które chcesz (jenkins, root itp.).

Odpowiedź

Miałem podobny problem z rsyncingiem jako inny użytkownik. Rozwiązałem to, uruchamiając następną komendę: 

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

Pamiętaj, że być może będziesz musiał bawić się klawiszami, aby móc uruchomić rsync jako inny użytkownik.

Odpowiedź 

sudo -u jenkins -i rsync ...

bez cudzysłowów .

Opcja -i sprawia, że polecenie sudo działa w środowisku użytkownika, w tym z kluczami ssh, .profile, .bash_profile itd.

Od sudo man:

-i, --login

Uruchom powłokę określoną przez wpis bazy danych haseł użytkownika docelowego jako powłokę logowania . Oznacza to, że pliki zasobów związane z logowaniem, takie jak .profile, .bash_profile lub .login, będą być odczytywane przez powłokę. Jeśli podano polecenie, jest ono przekazywane do powłoki w celu wykonania za pośrednictwem opcji powłoki „s -c. Jeśli nie podano polecenia, wykonywana jest powłoka interaktywna. sudo próbuje przejść do katalogu domowego tego użytkownika przed uruchomieniem powłoki. Polecenie jest uruchamiane w środowisku podobnym do tego, które użytkownik otrzymałby podczas logowania. Należy pamiętać, że większość powłok zachowują się inaczej, gdy podano polecenie, w porównaniu z sesją interaktywną; szczegółowe informacje można znaleźć w podręczniku powłoki. Sekcja Środowisko poleceń w podręczniku sudoers(5) opisuje, w jaki sposób opcja -i wpływa na środowisko, w którym polecenie jest uruchamiane, gdy obowiązuje zasada sudoers użyj.

Odpowiedź

Mam podobny problem.
I rozwiąż to za pomocą crona. Ale cron musi działać z określonym użytkownikiem (np. Jenkins)

Po prostu wykonaj zadanie crona: 

$ crontab -u jenkins -e

, a następnie wypełnij crona swoimi potrzebami. 

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

Komentarze

  • Jeśli rsync jest nie powiodło się z powodu problemu z uwierzytelnianiem, w czym pomoże Twoja sugestia?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *