szeptember 11, 2020
Articles
Nincs hozzászólás

rsync különböző felhasználókkal

Két ubuntu példánnyal dolgozom az AWS-en (amelyek eléréséhez pem kulcsot használok).

Mindkét példányhoz beállítottam az rsync alkalmazást, és akkor működik, ha az alapértelmezett felhasználót használom, amely az ubuntu @ ipaddress. Ha azonban megpróbálom más felhasználóval használni az rsync alkalmazást (“beírom a > például, vagy akár beírok sudo az rsync parancs elé), akkor a következő hibát kapom. 

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]

Lépések, amelyeket megtettem:

Megpróbáltam létrehozni egy ssh kulcsot (az ssh-keygen használatával), miközben bejelentkeztem jenkins néven, és hozzáadtam a authorized_keys fájl mind a /home/ubuntu/.ssh/authorized_keys fájlban (ahonnan az “rsync-et futtatom), akár a $JENKINS_HOME/.ssh/authorized_keys (ahol az rsync-et is onnan próbáltam futtatni).

Még a pem kulcsot is megpróbáltam ugyanazt csinálni, és ez sem működött.

Itt van, amit én “próbálok futni

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

És h nincsenek a kulcsfájllal

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

PS: Az egyetlen ok, amiért nem akarom az ubuntuval futtatni a felhasználó azért van, mert sok mindenre failed: Permission denied (13) -t kapok (mivel a fájlok jenkins tulajdonában vannak).

Végcél:

I “Megpróbálom folyamatosan fenntartani a biztonsági mentés jenkins példányát az elsődleges példánnyal egy cronjob segítségével:

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

Megjegyzések

  • Hozzáadta az ssh-kulcsot a távoli gazdagép-hitelesített_kulcs fájlhoz vagy ahhoz a kiszolgálóhoz, ahol az rsync parancsot futtatja?
  • A kérdés nem ‘ t teljesen egyértelmű. Minden rsync futtatásban van forrás és cél. Tudja tisztázni a forrás és cél rendszert? Hibaelhárítás céljából azt javaslom, hogy ragaszkodjon az ssh-hez az rsync felett, mert az rsync az ssh-t fogja használni. Próbálja meg használni az ssh -vvv jenkins @ < target > forrást, és ide illessze be a kimenetet.
  • Meghibásodtam: Sok mindenre megtagadták az engedélyt (13) (mivel a fájlok a jenkins tulajdonában vannak) Tehát miért nem hajtja végre az rsync-et ” jenkins ” felhasználó?
  • Ön írta I ‘ Megpróbáltam létrehozni egy ssh kulcsot (az ssh-keygen használatával) miközben jenkins-ként jelentkezett be, és hozzáadta ezt az autor_kulcs fájlhoz mindkét /home/ubuntu/.ssh/authorized_keys-ben (ahol i ‘ m futja az rsync-et) hozzá kell adnia a kulcsot a rendeltetési hely rendszer Authorized_keys fájljához.

Válasz

Tudom, hogy ez egy régi bejegyzés, de csak arra az esetre, ha más embereknek segíthetne …

Két dolgot meg kell különböztetnie:

  • ki létrehozza az SSH kapcsolatot .
  • mely távoli felhasználóé a másolni kívánt fájlok.

Áttekintés 

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

Mondjuk ki, hogy újra akarsz szinkronizálni:

  • Feladó:
    • Gép: srcmachine
    • Felhasználó: srcuser
    • Könyvtár: /var/lib/jenkins
  • Címzett:
    • Gép: destmachine
    • Felhasználó: destuser – létrehozza az SSH-kapcsolatot .
    • Könyvtár: /tmp
    • Végső fájltulajdonos: jenkins.

Megoldás 

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

Magyarázat 

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

A trükk elmondani rsync futtatása a távoli gépen egy másik felhasználóval (jenkins), mint az, aki létrehozza az SSH-kapcsolatot (destuser).

Követelmények

SSH hozzáférés 

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

Ne felejtsd el korlátozni a ~/.ssh engedélyeket : 

chmod 700 ~/.ssh

sudoer a destuser

A destuser kiváltsággal kell rendelkeznie a sudo -u jenkins rsync elvégzéséhez.

Általában a destuser a sudoers tagja. Ehhez a root @ destmachine oldalon: 

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

A rsync előtti teszteléshez jelentkezzen be a destuser @ destmachine oldalra, és futtassa ez: 

sudo su jenkins echo $USER

Ha visszatér: 

jenkins

ez azt jelenti, hogy bejelentkezett jenkins felhasználóként, és ez azt jelenti, hogy a rsync parancsod is működni fog, mert a működik.

Megjegyzés egy rossz megoldásról: létre kell hozni az SSH-kapcsolatot a célfelhasználóval jenkins

Miért nem ” t ezt csináljuk?

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

mert a jenkins egy “service” fiók, ami azt jelenti, hogy olyan szolgáltatást futtat, amely kitesz egy portot (80 vagy így) a külső HTTP-hozzáféréshez, és ez azt jelenti, hogy LEHETSÉGES, hogy a Jenkins szolgáltatáson keresztül a HTTP-n keresztül biztonsági rés történt a hozzáférés megszerzéséhez.

Ezért van www-data felhasználó és hasonlók a különböző szolgáltatások futtatásához. Ha feltörnek az általuk kitett portokból, nem sokat tehetnek:

  • minden csak olvasható nekik.
  • kivéve a /var/log/THE_SERVICE nyelvű írást.

Tehát lehetővé téve A jenkins felhasználó SSH-hozzáférése felületi támadást tesz közzé (és így van ez az SSH-hozzáféréshez root !! néven is).

Ezenkívül, ha más felhasználóként szeretne szinkronizálni (root, www-data stb.), akkor át kell másolnia a SSH-kulcs nyilvános kulcs ezekhez a fiókokhoz (zavaró).

Jó megoldás : A lehető legkevesebbet kell beállítania az SSH hozzáférést a felhasználói fiókokhoz (destuser), amely képes átértékelni a a kívánt “service” fiókot (jenkins, root stb.).

Válasz

Hasonló problémám volt egy másik felhasználó rsyncelésével kapcsolatban. Megoldotta a következő parancs futtatásával: 

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

Felhívjuk figyelmét, hogy lehet, hogy kulcsokkal kell játszania ahhoz, hogy az rsync programot másik felhasználóként futtathassa.

Válasz 

sudo -u jenkins -i rsync ...

idézőjelek nélkül .

A -i beállítás lehetővé teszi a sudo parancs futtatását a felhasználó környezetével, beleértve az ssh kulcsokat, .profile, .bash_profile stb.

A sudo embertől:

-i, --login

Futtassa a célfelhasználó jelszó-adatbázisának beírt héját bejelentkezési héjként Ez azt jelenti, hogy a bejelentkezési specifikus erőforrásfájlok, például a .profile, .bash_profile vagy a .login Ha egy parancs meg van adva, akkor az a “s -c opción keresztül továbbításra kerül a shell számára végrehajtásra. Ha nincs megadva parancs, akkor interaktív shell kerül végrehajtásra. A sudo megpróbálja áttérni a felhasználó saját könyvtárára a shell futtatása előtt. A parancsot egy olyan környezettel futtatják, mint amelyet a felhasználó a bejelentkezéskor kap. Ne feledje, hogy a legtöbb shell viselkedjen másképp, amikor a parancs meg van adva, mint az interaktív munkamenet; a részletekért olvassa el a shell kézikönyvét. A Parancs környezet szakasz a sudoers(5) kézikönyvben dokumentálja, hogy a -i beállítás hogyan befolyásolja azt a környezetet, amelyben a parancs fut, amikor a sudoers házirend be van kapcsolva. használat.

Válasz

Hasonló problémám van.
I megoldja ezt a cron használatával. De a cron-nak konkrét felhasználóval kell futnia (pl: jenkins).

Csak készítsen cron-feladatot: 

$ crontab -u jenkins -e

majd töltse ki a cront az igényével. 

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

Megjegyzések

  • Ha a rsync sikertelen hitelesítési probléma miatt, hogyan segít a javaslat?

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük