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
- Maschine:
- An:
- Maschine:
destmachine
- Benutzer:
destuser
bis stellt die SSH-Verbindung her . - Verzeichnis:
/tmp
- Endgültiger Dateibesitzer:
jenkins
.
- Maschine:
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 Handbuchsudoers(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?