rsync mit einem anderen Benutzer

Ich arbeite mit zwei Ubuntu-Instanzen in AWS (auf die ich mit einem PEM-Schlüssel zugreifen kann).

Ich habe rsync für beide Instanzen eingerichtet und es funktioniert, wenn ich den Standardbenutzer ubuntu @ ipaddress verwende. Wenn ich jedoch versuche, rsync mit einem anderen Benutzer zu verwenden (ich tippe sudo su - jenkins Wenn Sie beispielsweise sudo vor dem Befehl rsync eingeben, wird der folgende Fehler angezeigt:

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] 

Schritte, die ich unternommen habe:

Ich habe versucht, einen ssh-Schlüssel (mit ssh-keygen) zu erstellen, während ich als jenkins angemeldet war, und diesen dem authorized_keys -Datei sowohl in /home/ubuntu/.ssh/authorized_keys (von wo aus ich den rsync ausführe) als auch in $JENKINS_HOME/.ssh/authorized_keys (wo ich auch versucht habe, rsync von dort aus auszuführen).

Ich habe sogar versucht, die PEM-Taste zu verwenden, um dasselbe zu tun, und das hat auch nicht funktioniert.

Hier ist, was ich bin Ich versuche

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

und h ere „s mit der Schlüsseldatei

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

PS: Der einzige Grund, warum ich sie nicht mit dem Ubuntu ausführen möchte Benutzer ist, weil ich failed: Permission denied (13) für viele Dinge bekomme (da die Dateien im Besitz von Jenkins sind).

Endziel:

I. Ich versuche, die Backup-Jenkins-Instanz durch Ausführen eines Cronjobs ständig mit der primären Instanz zu sichern:

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

Kommentare

  • Haben Sie den SSH-Schlüssel in der Datei „authorized_keys“ des Remote-Hosts oder auf dem Server hinzugefügt, auf dem Sie den Befehl „rsync“ ausführen?
  • Die Frage lautet nicht ‚ nicht ganz klar. In jedem rsync-Lauf haben Sie eine Quelle und ein Ziel. Können Sie die Quell- und Zielsysteme klären? Zur Fehlerbehebung empfehle ich, nur ssh über rsync zu verwenden, da rsync ssh verwendet. Versuchen Sie, ssh -vvv jenkins @ < target > aus der Quelle zu verwenden und die Ausgabe hier einzufügen.
  • Ich werde gescheitert: Die Berechtigung wurde für viele Dinge verweigert (13) (da die Dateien im Besitz von Jenkins sind). Warum also nicht den rsync als “ jenkins “ Benutzer?
  • Sie haben geschrieben Ich ‚ habe versucht, einen ssh-Schlüssel zu erstellen (mit ssh-keygen) während Sie als Jenkins angemeldet sind und dies der Datei „authorized_keys“ in beiden /home/ubuntu/.ssh/authorized_keys hinzugefügt haben (wobei ich ‚ den rsync von) ausführe Sie sollten den Schlüssel zur Datei authorized_keys auf dem Zielsystem hinzufügen.

Antwort

Ich weiß, dass es ein alter Beitrag ist, aber nur für den Fall, dass er anderen Menschen helfen kann …

Sie müssen zwei Dinge unterscheiden:

  • wer stellt die SSH-Verbindung her .
  • Welcher Remote-Benutzer besitzt die Dateien , die Sie kopieren möchten.

Übersicht

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

Nehmen wir an, Sie möchten rsync:

  • Von:
    • Maschine: srcmachine
    • Benutzer: srcuser
    • Verzeichnis: /var/lib/jenkins
  • An:
    • Maschine: destmachine
    • Benutzer: destuser bis stellt die SSH-Verbindung her .
    • Verzeichnis: /tmp
    • Endgültiger Dateibesitzer: jenkins.

Lösung

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

Erklärungen

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

Der Trick besteht darin, dies zu sagen rsync auf dem Remotecomputer mit einem anderen Benutzer (jenkins) als demjenigen ausführen, der die SSH-Verbindung herstellt ().

Anforderungen

SSH-Zugriff

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

Vergessen Sie nicht, die Berechtigungen für ~/.ssh einzuschränken :

chmod 700 ~/.ssh 

sudoer für den destuser

Der destuser muss die Berechtigung haben, sudo -u jenkins rsync auszuführen.

Im Allgemeinen setzen wir destuser auf ein Mitglied der sudoers. Dazu auf der root @ destmachine:

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

Um es vor rsync zu testen, können Sie sich bei destuser @ destmachine anmelden und ausführen dies:

sudo su jenkins echo $USER 

Wenn Folgendes zurückgegeben wird:

jenkins 

bedeutet dies, dass Sie angemeldet sind als jenkins Benutzer, und dies bedeutet, dass Ihr rsync -Befehl ebenfalls funktioniert, da das Eskalade-Privileg für jenkins funktioniert.

Hinweis zu einer schlechten Lösung: Stellen Sie die SSH-Verbindung mit dem Zielbenutzer her. jenkins

Warum nicht? “ Tun wir das einfach?

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

, weil jenkins ein „Dienst“ -Konto ist, was bedeutet, dass ein Dienst ausgeführt wird, der einen Port verfügbar macht (80 oder so) für externen HTTP-Zugriff. Dies bedeutet, dass möglicherweise eine Sicherheitsverletzung durch den Jenkins-Dienst über HTTP vorliegt, um Zugriff zu erhalten.

Aus diesem Grund haben wir www-data Benutzer und Ähnliches, um die verschiedenen Dienste auszuführen. Falls sie von den Ports gehackt werden, die sie verfügbar machen, können sie nicht viel tun:

  • Für sie ist alles schreibgeschützt.
  • außer Schreiben in /var/log/THE_SERVICE.

So erlaubt Der SSH-Zugriff für den Benutzer jenkins macht einen Oberflächenangriff sichtbar (und so ist er für den SSH-Zugriff als root !!).

Wenn Sie als anderer Benutzer rsyncieren möchten (root, www-data usw.), müssen Sie Ihre kopieren Öffentlicher SSH-Schlüsselschlüssel für diese Konten (problematisch).

Gute Lösung : Sie sollten SSH-Zugriff auf Benutzerkonten (destuser), dass zu eskalieren kann das gewünschte „Service“ -Konto (jenkins, root usw.).

Antwort

Ich hatte ein ähnliches Problem mit rsyncing als ein anderer Benutzer. Es wurde durch Ausführen des nächsten Befehls behoben:

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 

Bitte beachten Sie, dass Sie möglicherweise mit Tasten spielen müssen, um rsync als anderer Benutzer ausführen zu können.

Antwort

sudo -u jenkins -i rsync ... 

ohne Anführungszeichen .

Mit der Option -i wird der Befehl sudo mit der Umgebung des Benutzers ausgeführt, einschließlich der SSH-Schlüssel , .bash_profile usw.

Vom sudo man:

-i, --login

Führen Sie die vom Kennwortdatenbankeintrag des Zielbenutzers angegebene Shell als Anmeldeshell aus Dies bedeutet, dass anmeldespezifische Ressourcendateien wie .profile, .bash_profile oder .login dies tun Wird von der Shell gelesen. Wenn ein Befehl angegeben wird, wird er zur Ausführung über die Shell-Option „s -c an die Shell übergeben. Wenn kein Befehl angegeben wird, wird eine interaktive Shell ausgeführt. sudo versucht, vor dem Ausführen der Shell in das Ausgangsverzeichnis dieses Benutzers zu wechseln. Der Befehl wird in einer Umgebung ausgeführt, die derjenigen ähnelt, die ein Benutzer beim Anmelden erhalten würde. Beachten Sie, dass die meisten Shells Verhalten Sie sich anders, wenn ein Befehl angegeben wird als bei einer interaktiven Sitzung. Weitere Informationen finden Sie im Handbuch der Shell. Der Abschnitt Befehlsumgebung im Handbuch sudoers(5) dokumentiert, wie sich die Option -i auf die Umgebung auswirkt, in der ein Befehl ausgeführt wird, wenn sich die sudoers-Richtlinie befindet Verwenden Sie.

Antwort

Ich habe ein ähnliches Problem.
I. Löse dies mit cron. Cron muss jedoch mit einem bestimmten Benutzer (z. B. Jenkins) ausgeführt werden.

Machen Sie einfach einen Cron-Job:

$ crontab -u jenkins -e 

und füllen Sie dann cron mit Ihren Anforderungen.

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

Kommentare

  • Wenn die rsync ist Fehler aufgrund eines Authentifizierungsproblems Wie hilft Ihr Vorschlag?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.