Settembre 11, 2020
Articles
Nessun commento

rsync con un utente diverso

Sto lavorando con due istanze di ubuntu su AWS (che uso una chiave pem per accedervi).

Ho impostato rsync per entrambe le istanze e funziona se utilizzo lutente predefinito che è ubuntu @ ipaddress. Tuttavia, se provo a utilizzare rsync con un altro utente (sto digitando sudo su - jenkins per esempio o anche digitando sudo prima del comando rsync), quindi ottengo il seguente errore. 

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]

Passaggi che ho eseguito:

Ho provato a creare una chiave ssh (utilizzando ssh-keygen) mentre ero connesso come jenkins e lho aggiunto al authorized_keys file sia in /home/ubuntu/.ssh/authorized_keys (da cui “sto eseguendo rsync) che in $JENKINS_HOME/.ssh/authorized_keys (da dove ho provato a eseguire rsync anche da lì).

Ho anche provato a usare il tasto pem per fare la stessa cosa e nemmeno questo ha funzionato.

Ecco cosa ho “Sto provando a eseguire

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

E h ere “s con il file chiave

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

PS: Lunico motivo per cui non voglio eseguirlo con ubuntu utente è perché ottengo failed: Permission denied (13) su molte cose (poiché i file sono di proprietà di jenkins).

Obiettivo finale:

I “Sto cercando di mantenere costantemente il backup dellistanza jenkins di backup con listanza principale eseguendo un cronjob:

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

Commenti

  • Hai aggiunto la chiave ssh sul file authorized_keys degli host remoti o sul server su cui stai eseguendo il comando rsync?
  • La domanda non è ‘ t abbastanza chiaro. In ogni esecuzione di rsync hai una sorgente e una destinazione. Potete chiarire i sistemi di origine e di destinazione? Per la risoluzione dei problemi, consiglio di restare con solo ssh su rsync, perché rsync userà ssh. Prova a utilizzare ssh -vvv jenkins @ < target > dallorigine e incolla loutput qui.
  • Non riesco: autorizzazione negata (13) su molte cose (poiché i file sono di proprietà di jenkins) Allora perché non eseguire rsync come ” jenkins ” utente?
  • Hai scritto I ‘ ho provato a creare una chiave ssh (utilizzando ssh-keygen) dopo aver effettuato laccesso come jenkins e averlo aggiunto al file authorized_keys in entrambi /home/ubuntu/.ssh/authorized_keys (dove ‘ sto eseguendo rsync da) , ma dovresti aggiungere la chiave al file authorized_keys sul sistema destinazione .

Risposta

So che è un vecchio post, ma nel caso possa aiutare altre persone …

Devi differenziare 2 cose:

  • chi stabilisce la connessione SSH .
  • quale utente remoto possiede i file che desideri copiare.

Panoramica 

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

Supponiamo che desideri eseguire nuovamente la sincronizzazione:

  • Da:
    • Macchina: srcmachine
    • Utente: srcuser
    • Directory: /var/lib/jenkins
  • A:
    • Macchina: destmachine
    • Utente: destuser per stabilire la connessione SSH .
    • Directory: /tmp
    • Proprietario file finale: jenkins.

Soluzione 

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

Spiegazioni 

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

Il trucco è dire eseguire rsync sulla macchina remota con un altro utente (jenkins) diverso da quello che stabilisce la connessione SSH (destuser).

Requisiti

Accesso SSH 

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

Non dimenticare di limitare le autorizzazioni su ~/.ssh : 

chmod 700 ~/.ssh

sudoer per destuser

destuser deve avere il privilegio di eseguire sudo -u jenkins rsync.

In generale, impostiamo destuser come un membro del sudoers. A tale scopo, su root @ destmachine: 

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

Per testarlo prima del rsync, puoi accedere a destuser @ destmachine ed eseguire questo: 

sudo su jenkins echo $USER

Se restituisce: 

jenkins

significa che sei loggato come utente jenkins e significa che anche il comando rsync funzionerà, perché il privilegio di escalade a jenkins funziona.

Nota su una cattiva soluzione: stabilire la connessione SSH con lutente di destinazione jenkins

Perché don ” facciamo solo questo?

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

perché jenkins è un account “servizio”, il che significa che esegue un servizio che espone una porta (80 o giù di lì) per laccesso HTTP esterno e significa che è POSSIBILE che vi sia una violazione della sicurezza tramite il servizio Jenkins su HTTP per ottenere laccesso.

Questo è il motivo per cui abbiamo www-data utente e simili per eseguire i diversi servizi. Nel caso in cui vengano violati dalle porte che espongono, non possono “fare molto:

  • tutto è di sola lettura per loro.
  • tranne la scrittura in /var/log/THE_SERVICE.

Quindi permettendo Laccesso SSH per lutente jenkins espone un attacco di superficie (e così è per laccesso SSH come root !!).

Inoltre, se desideri eseguire nuovamente la sincronizzazione come un altro utente (root, www-data, ecc.), dovresti copiare il tuo Chiave SSH chiave pubblica per questi account (problematica).

Buona soluzione : devi impostare l accesso SSH il meno possibile per gli account utente (destuser) che PU eseguire lescaladation di a laccount “servizio” che desideri (jenkins, root e così via).

Risposta

Ho avuto un problema simile con rsyncing come un altro utente. Risolto eseguendo il comando successivo: 

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

Si noti che forse sarà necessario giocare con i tasti per poter eseguire rsync come un altro utente.

Rispondi 

sudo -u jenkins -i rsync ...

con senza virgolette .

Lopzione -i fa eseguire il comando sudo con lambiente dellutente, comprese le chiavi ssh, .profile, .bash_profile ecc.

Da sudo man:

-i, --login

Esegui la shell specificata dalla voce del database delle password dellutente di destinazione come shell di accesso . Ciò significa che i file di risorse specifici per laccesso come .profile, .bash_profile o .login essere letto dalla shell. Se viene specificato un comando, viene passato alla shell per lesecuzione tramite lopzione shell “s -c. Se non viene specificato alcun comando, viene eseguita una shell interattiva. sudo tenta di passare alla directory home di quellutente prima di eseguire la shell. Il comando viene eseguito con un ambiente simile a quello che un utente riceverebbe al momento del login. Nota che la maggior parte delle shell si comportano in modo diverso quando viene specificato un comando rispetto a una sessione interattiva, consultare il manuale della shell per i dettagli. La sezione Ambiente di comando nel manuale sudoers(5) documenta come lopzione -i influisce sullambiente in cui viene eseguito un comando quando la politica sudoers è in utilizzare.

Risposta

Ho un problema simile.
I risolverlo usando cron. Ma cron deve essere eseguito con un utente specifico (es: jenkins)

Basta fare cron job: 

$ crontab -u jenkins -e

quindi riempire cron con le tue necessità. 

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

Commenti

  • Se rsync è fallito a causa di un problema di autenticazione, in che modo il tuo suggerimento sarà daiuto?

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *