11 září, 2020
Articles
Žádné komentáře

rsync s jiným uživatelem

Pracuji se dvěma instancemi ubuntu na AWS (ke kterým k nim používám klíč pem).

Nastavil jsem rsync pro obě instance a funguje to, když použiji výchozího uživatele, kterým je ubuntu @ ipaddress. Pokud se však pokusím použít rsync s jiným uživatelem (zadávám sudo su - jenkins například nebo dokonce zadáním sudo před příkazem rsync), pak se zobrazí následující chyba. 

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]

Kroky, které jsem přijal:

Pokusil jsem se vytvořit klíč ssh (pomocí ssh-keygen), když jsem přihlášen jako jenkins a přidal jsem ho do authorized_keys soubor v /home/ubuntu/.ssh/authorized_keys (odkud spouštím rsync) i $JENKINS_HOME/.ssh/authorized_keys (kde jsem se také pokusil spustit rsync odtamtud).

Dokonce jsem se pokusil použít totéž i pomocí klíče pem a to také nefungovalo.

Tady je to, co jsem „pokouším se spustit

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

A h s klíčovým souborem

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

PS: Jediný důvod, proč jej nechci spouštět s ubuntu uživatel je proto, že dostávám failed: Permission denied (13) spoustu věcí (protože soubory vlastní Jenkins).

Konečný cíl:

I „Snažím se udržet záložní instanci Jenkinse neustále zálohovanou primární instancí pomocí cronjob:

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

Komentáře

  • Přidali jste ssh-key do souboru vzdálených hostitelů authorized_keys nebo na server, na kterém spouštíte příkaz rsync?
  • Otázka není ' t zcela jasný. V každém běhu rsync máte zdroj a cíl. Můžete objasnit zdrojový a cílový systém? Pro účely řešení problémů doporučuji držet se pouze ssh přes rsync, protože rsync použije ssh. Zkuste použít ssh -vvv jenkins @ < target > ze zdroje a vložit výstup sem.
  • Zlyhal jsem: Oprávnění odepřeno (13) na spoustu věcí (protože soubory vlastní Jenkins) Proč tedy neprovést rsync jako " jenkins " uživatel?
  • Napsali jste Pokusil jsem se ' vytvořit klíč ssh (pomocí ssh-keygen) když jste přihlášeni jako Jenkins a přidali to do souboru authorized_keys v obou /home/ubuntu/.ssh/authorized_keys (kde i ' m běží rsync z) , ale měli byste přidávat klíč do souboru authorized_keys v cílovém systému.

Odpovědět

Vím, že se jedná o starý příspěvek, ale pro případ, že by mohl pomoci ostatním lidem …

Musíte rozlišovat 2 věci:

  • kdo naváže připojení SSH .
  • který vzdálený uživatel vlastní soubory , které chcete zkopírovat.

Přehled 

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

Řekněme, že chcete rsync:

  • Od:
    • Stroj: srcmachine
    • Uživatel: srcuser
    • Adresář: /var/lib/jenkins
  • Komu:
    • Stroj: destmachine
    • Uživatel: destuser do navázat připojení SSH .
    • Adresář: /tmp
    • Vlastník finálních souborů: jenkins.

Řešení 

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

Vysvětlení 

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

Trik je říct spustit rsync na vzdáleném počítači s jiným uživatelem (jenkins) než s tím, kdo naváže připojení SSH (destuser).

Požadavky

Přístup SSH 

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

Nezapomeňte omezit oprávnění pro ~/.ssh : 

chmod 700 ~/.ssh

sudoer pro destuser

destuser musí mít oprávnění dělat sudo -u jenkins rsync.

Obecně nastavujeme destuser jako člen sudoers. Za tímto účelem na stránce root @ destmachine: 

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

Chcete-li to před rsync otestovat, můžete se přihlásit do destuser @ destmachine a spustit toto: 

sudo su jenkins echo $USER

Pokud se vrátí: 

jenkins

znamená to, že jste přihlášeni jako jenkins uživatel, což znamená, že bude fungovat i váš rsync příkaz, protože privilegium escalade k jenkins funguje.

Poznámka ke špatnému řešení: navázat spojení SSH s cílovým uživatelem jenkins

Proč ne “ Prostě to děláme?

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

protože jenkins je účet „služby“, což znamená, že provozuje službu, která vystavuje port (80 nebo tak) pro externí přístup HTTP a znamená to, že je MOŽNÉ, aby došlo k narušení zabezpečení prostřednictvím služby Jenkins přes HTTP, aby se získal přístup.

Proto máme www-data uživatele a podobné služby, které provozují různé služby. V případě, že budou hacknuti z portů, které vystavují, nemohou dělat mnoho:

  • vše je pro ně jen pro čtení.
  • kromě zápisu do /var/log/THE_SERVICE.

povoleno Přístup SSH pro uživatele jenkins vystavuje povrchový útok (a tak je pro přístup SSH jako root !!).

Navíc, pokud chcete rsync použít jako jiný uživatel (root, www-data atd.), budete muset zkopírovat Veřejný klíč SSH k těmto účtům (problematické).

Dobré řešení : Pro uživatelské účty byste měli nastavit přístup SSH co nejméně „fc37a0f7d5″>

(destuser), které MŮŽE eskalovat do požadovaný „servisní“ účet (jenkins, root atd.).

odpověď

S rsyncingem jsem měl podobný problém jako jiný uživatel. Vyřešil to spuštěním dalšího příkazu: 

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

Upozorňujeme, že možná budete muset hrát s klávesami, abyste mohli rsync spouštět jako jiný uživatel.

Odpověď 

sudo -u jenkins -i rsync ...

bez bez uvozovek .

Díky možnosti -i je příkaz sudo spuštěn s prostředím uživatele, včetně klíčů ssh, .profile, .bash_profile atd.

Od sudo muže:

-i, --login

Jako přihlašovací shell spusťte prostředí zadané v databázi hesel cílového uživatele. . To znamená, že soubory prostředků specifických pro přihlášení, například .profile, .bash_profile nebo .login budou číst shellem. Pokud je zadán příkaz, je předán shellu k provedení prostřednictvím možnosti shellu „s -c. Pokud není zadán žádný příkaz, provede se interaktivní prostředí. sudo se před spuštěním prostředí pokusí změnit domovský adresář daného uživatele. Příkaz je spuštěn v prostředí podobném tomu, které by uživatel obdržel při přihlášení. Pamatujte, že většina skořápek chovat se jinak, když je zadán příkaz ve srovnání s interaktivní relací; podrobnosti najdete v příručce prostředí. Sekce prostředí příkazů v příručce sudoers(5) dokumentuje, jak možnost -i ovlivňuje prostředí, ve kterém je spuštěn příkaz, když je zásada sudoers použít.

Odpovědět

Mám podobný problém.
I vyřešte to pomocí cron. Ale cron musí běžet s konkrétním uživatelem (např. Jenkins).

Stačí vytvořit úlohu cronu: 

$ crontab -u jenkins -e

a poté vyplnit cron podle potřeby. 

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

Komentáře

  • Pokud je rsync selhalo kvůli problému s ověřením, jak pomůže váš návrh?

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *