syyskuu 11, 2020
Articles
Ei kommentteja

rsync eri käyttäjän kanssa

Työskentelen kahden AWS: n Ubuntu-ilmentymän kanssa (joihin käytän pem-avainta päästäksesi niihin).

Asetin rsyncin molemmille instansseille, ja se toimii, jos käytän oletuskäyttäjää, joka on ubuntu @ ipaddress. Jos kuitenkin yritän käyttää rsynciä toisen käyttäjän kanssa (kirjoitan sudo su - jenkins tai jopa kirjoittamalla sudo ennen rsync-komentoa), saan seuraavan virheen. 

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]

Vaiheet, jotka olen suorittanut:

Olen yrittänyt luoda ssh-avaimen (käyttämällä ssh-keygenia) kirjautuneena sisään nimellä jenkins ja lisännyt sen authorized_keys -tiedosto sekä /home/ubuntu/.ssh/authorized_keys -kohdassa (josta minä suoritan rsync: n) että jopa $JENKINS_HOME/.ssh/authorized_keys (missä yritin suorittaa rsyncin myös sieltä).

Yritin jopa käyttää pem-avainta samaan asiaan, mikä ei myöskään toiminut.

Tässä on mitä minä ”yritän suorittaa

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

Ja h Ei vain avaintiedostolla

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

PS: Ainoa syy, miksi en halua käyttää sitä Ubuntu Käyttäjä johtuu siitä, että saan failed: Permission denied (13) moniin asioihin (koska tiedostot ovat jenkinsin omistuksessa).

Lopullinen tavoite:

I ”Yritän pitää varmuuskopion jenkins-ilmentymän varmuuskopioiduna jatkuvasti ensisijaisen ilmentymän kanssa tekemällä cronjob:

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

Kommentit

  • Lisäsitkö ssh-avaimen etäisäntän valtuutetut_avaimet-tiedostoon tai palvelimeen, jossa suoritat rsync-komentoa?
  • Kysymys ei ole ’ t melko selvä. Jokaisessa rsync-ajossa sinulla on lähde ja kohde. Voitteko selvittää lähde- ja kohdesysteemit? Vianmääritystarkoituksiin suosittelen pitämään kiinni vain ssh: stä rsync: n päällä, koska rsync käyttää ssh: tä. Kokeile käyttää ssh -vvv jenkins @ < target > -lähdettä ja liittää lähtö tähän.
  • Epäonnistun: Lupa evätään (13) monille asioille (koska tiedostot ovat jenkinsin omistuksessa) Joten miksi et suorittaisi rsync-tiedostoa ” jenkins ” käyttäjä?
  • Kirjoitit minä ’ yritin luoda ssh-avaimen (käyttämällä ssh-keygenia) kirjautuneena sisään jenkins-tiedostona ja lisäsi sen molempien /home/ubuntu/.ssh/authorized_keys (jossa i ’ m ajaa rsync-tiedostoa) -valtuutuksiin. sinun on lisättävä avain kohde -järjestelmän valtuutettujen avainten tiedostoon.

Vastaa

Tiedän, että se on vanha viesti, mutta vain siinä tapauksessa, että se voi auttaa muita ihmisiä …

Sinun on erotettava kaksi asiaa:

  • kuka div id = ”4806972ff3”>

muodostaa SSH-yhteyden .

  • mikä etäkäyttäjä omistaa kopioitavat tiedostot .

    • Yleiskatsaus 

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

    Sanotaan, että haluat synkronoida:

    • Lähettäjä:
      • Kone: srcmachine
      • Käyttäjä: srcuser
      • Hakemisto: /var/lib/jenkins
    • Vastaanottaja:
      • Kone: destmachine
      • Käyttäjä: destuser – muodosta SSH-yhteys .
      • Hakemisto: /tmp
      • Lopullisten tiedostojen omistaja: jenkins.

    Ratkaisu 

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

    Selitykset 

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

    Temppu on kertoa suorittaa rsync etäkoneella toisen käyttäjän kanssa (jenkins) kuin SSH-yhteyden muodostavan käyttäjän kanssa (destuser).

    Vaatimukset

    SSH-käyttöoikeus 

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

    Älä unohda rajoittaa käyttöoikeuksia kohteelle ~/.ssh : 

    chmod 700 ~/.ssh

    sudoer destuser

    destuser täytyy olla etuoikeus tehdä sudo -u jenkins rsync.

    Yleensä asetamme destuser sudoers -jäsen. Voit tehdä tämän valitsemalla root @ destmachine: 

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

    Jos haluat testata sitä ennen rsync, voit kirjautua sisään destuser @ destmachine ja suorittaa tämä: 

    sudo su jenkins echo $USER

    Jos se palaa: 

    jenkins

    se tarkoittaa, että olet kirjautunut sisään jenkins -käyttäjänä, ja se tarkoittaa, että komento rsync toimii myös, koska escalade-etuoikeus jenkins toimii.

    Huomautus virheellisestä ratkaisusta: muodosta SSH-yhteys kohdekäyttäjään jenkins

    Miksi ei ” t vain teemme tämän?

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

    koska jenkins on ”service” -tili, mikä tarkoittaa, että se käyttää palvelua, joka paljastaa portin (80 tai niin) ulkoiselle HTTP-pääsylle, ja se tarkoittaa, että on mahdollista, että Jenkins-palvelun kautta HTTP: n kautta tapahtuu tietoturvaloukkaus pääsyn saamiseksi.

    Siksi meillä on www-data käyttäjä ja vastaavat palvelut suorittamaan erilaisia palveluita. Jos heidät murtautuvat paljastamastaan portista, he eivät voi tehdä paljon:

    • kaikki on vain luettavissa heille.
    • paitsi kirjoittaminen /var/log/THE_SERVICE.

    Joten sallitaan jenkins -käyttäjän SSH-käyttö paljastaa pintahyökkäyksen (ja niin on SSH-pääsylle root !!).

    Lisäksi, jos haluat synkronoida toisena käyttäjänä (root, www-data jne.), sinun on kopioitava SSH-avaimen julkinen avain näille tileille (hankala).

    Hyvä ratkaisu : Sinun on määritettävä SSH-käyttöoikeus mahdollisimman vähän käyttäjätileille (destuser), joka VOI eskaloida haluamasi ”palvelu” -tili (jenkins, root jne.).

    Vastaa

    Minulla oli samanlainen ongelma rsynkronoinnissa toisena käyttäjänä. Ratkaisi sen suorittamalla seuraava komento: 

    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

    Huomaa, että ehkä sinun täytyy pelata avaimilla, jotta voit suorittaa rsyncin toisena käyttäjänä.

    Vastaa 

    sudo -u jenkins -i rsync ...

    ei lainausmerkkejä .

    Vaihtoehto -i saa komennon sudo ajamaan käyttäjän ympäristössä, mukaan lukien ssh-avaimet, .profile, .bash_profile jne.

    Mieheltä sudo:

    -i, --login

    Suorita kohdekäyttäjän salasanatietokannan määrittämä kuori kirjautumissuorana . Tämä tarkoittaa, että kirjautumiskohtaiset resurssitiedostot, kuten .profile, .bash_profile tai .login Jos komento on määritetty, se välitetään komentotulkille suoritettavaksi komentotulkin ”s -c avulla. Jos komentoa ei määritetä, suoritetaan interaktiivinen kuori. sudo yrittää vaihtaa käyttäjän kotihakemistoon ennen komentotulkin suorittamista. Komento suoritetaan ympäristössä, joka on samanlainen kuin se, jonka käyttäjä saa sisäänkirjautumisen yhteydessä. Huomaa, että useimmat kuoret käyttäytyä eri tavalla, kun komento on määritetty, vuorovaikutteiseen istuntoon verrattuna; lisätietoja on shellin käsikirjassa. sudoers(5) -käsikirjan komentoympäristö-osio dokumentoi, kuinka -i -vaihtoehto vaikuttaa ympäristöön, jossa komento suoritetaan sudoers-käytännön ollessa käyttö.

    Vastaa

    Minulla on samanlainen ongelma.
    I ratkaise tämä käyttämällä cronia. Mutta cronin on suoritettava tietyn käyttäjän (esim. Jenkins) kanssa.

    Tee vain cron-työ: 

    $ crontab -u jenkins -e

    täytä sitten cron tarpeellasi. 

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

    Kommentit

    • Jos rsync on epäonnistui todennusongelman vuoksi, miten ehdotuksesi auttaa?

    Vastaa

    Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *