☰

Überblick

tag-icon • tag-icon ubuntu ssh rsync aws
Überblick

Ich arbeite mit zwei Ubuntu-Instanzen auf AWS (für den Zugriff darauf verwende ich einen PEM-Schlüssel).

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 - jenkinsbeispielsweise oder sogar sudovor dem rsync-Befehl), erhalte ich den folgenden Fehler.

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 angemeldet war, jenkinsund habe diesen authorized_keyssowohl /home/ubuntu/.ssh/authorized_keys(von wo aus ich rsync ausführe) als auch $JENKINS_HOME/.ssh/authorized_keys(von wo aus ich auch versucht habe, rsync auszuführen) der Datei hinzugefügt.

Ich habe sogar versucht, dasselbe mit dem PEM-Schlüssel zu tun, aber das hat auch nicht funktioniert.

Hier ist, was ich versuche auszuführen

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

Und hier ist die 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 es nicht mit dem Ubuntu-Benutzer ausführen möchte, ist, dass ich failed: Permission denied (13)auf viele Dinge stoße (da die Dateien Jenkins gehören).

Endziel:

Ich versuche, die Backup-Jenkins-Instanz ständig zusammen mit der primären Instanz zu sichern, indem ich einen Cronjob ausführe:

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

Antwort1

Man muss 2 Dinge unterscheiden:

  • WHOstellt die SSH-Verbindung her.
  • welcheDer Remote-Benutzer besitzt die Dateiendie Sie kopieren möchten.

Überblick

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

Nehmen wir an, Sie möchten rsync verwenden:

  • Aus:
    • Maschine:srcmachine
    • Benutzer:srcuser
    • Verzeichnis:/var/lib/jenkins
  • Zu:
    • Maschine:destmachine
    • Benutzer: destuserandie SSH-Verbindung herstellen.
    • Verzeichnis:/tmp
    • Endgültiger Besitzer der Dateien: jenkins.

Lösung

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

Erläuterungen

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

rsyncDer Trick besteht darin , auf dem Remote-Computer einen anderen Benutzer ( ) auszuführen jenkinsals den, der die SSH-Verbindung ( destuser) 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 Folgendes einzuschränken ~/.ssh:

chmod 700 ~/.ssh

sudoer für diedestuser

Sie destusermüssen das Privileg haben, dies zu tun sudo -u jenkins rsync.

Im Allgemeinen setzen wir den destuserals Mitglied des sudoers. Dazu auf dem root@ destmachine:

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

Um es vorher zu testen rsync, können Sie sich beim destuser@ anmelden destmachineund Folgendes ausführen:

sudo su jenkins
echo $USER

Wenn es zurückkommt:

jenkins

Dies bedeutet, dass Sie als Benutzer angemeldet sind jenkinsund dass Ihr rsyncBefehl auch funktioniert, da die Berechtigungserweiterung jenkinsfunktioniert.

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

Warum machen wir das nicht einfach?

(srcmachine)         (rsync)   (destmachine)
  srcuser           -- SSH -->    jenkins

[~/.ssh/id_rsa]                [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]

weil jenkinses sich um ein „Dienst“-Konto handelt, was bedeutet, dass es einen Dienst ausführt, der einen Port ( 80oder so) für den externen HTTP-Zugriff verfügbar macht, und es bedeutet, dass es MÖGLICH ist, dass es durch den Jenkins-Dienst zu einer Sicherheitsverletzung kommt, um über HTTP Zugriff zu erhalten.

Aus diesem Grund haben wir www-dataBenutzer und ähnliche, um die verschiedenen Dienste auszuführen. Falls sie über die Ports, die sie freigeben, gehackt werden, können sie nicht viel tun:

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

Wenn dem jenkinsBenutzer also SSH-Zugriff gewährt wird, stellt dies einen Oberflächenangriff dar (und das ist beim SSH-Zugriff genauso root!!).

rootWenn Sie darüber hinaus als anderer Benutzer ( , usw.) rsync verwenden möchten www-data, müssen Sie Ihren öffentlichen SSH-Schlüssel in diese Konten kopieren (mühselig).

Gute Lösung: Sie solltenMöglichst wenige SSH-Zugriffe auf Benutzerkonten( destuser) DasKANN eskalierenzu dem gewünschten „Dienst“-Konto ( jenkins, root, usw.).

Antwort2

Ich hatte ein ähnliches Problem mit rsyncing wie ein anderer Benutzer. Es wurde durch Ausführen des folgenden Befehls gelöst:

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 Schlüsseln herumspielen müssen, um rsync als anderer Benutzer ausführen zu können.

Antwort3

sudo -u jenkins -i rsync ...

mitkeine Anführungszeichen.

Die -iOption bewirkt, dass der sudoBefehl mit der Umgebung des Benutzers einschließlich SSH-Schlüsseln usw. ausgeführt wird .profile..bash_profile

Vom sudoMann:

-i, --login

Führen Sie die Shell, die durch den Kennwortdatenbankeintrag des Zielbenutzers angegeben ist, als Anmelde-Shell aus. Dies bedeutet, dass anmeldespezifische Ressourcendateien wie .profileoder .bash_profilevon .loginder Shell gelesen werden. Wenn ein Befehl angegeben ist, wird er über die Option der Shell zur Ausführung an die Shell übergeben -c. Wenn kein Befehl angegeben ist, wird eine interaktive Shell ausgeführt. sudoversucht, vor dem Ausführen der Shell in das Home-Verzeichnis des Benutzers zu wechseln. Der Befehl wird in einer Umgebung ausgeführt, die der ähnelt, die ein Benutzer beim Anmelden erhalten würde. Beachten Sie, dass sich die meisten Shells bei Angabe eines Befehls anders verhalten als bei einer interaktiven Sitzung. Weitere Informationen finden Sie im Handbuch der Shell. Der Abschnitt „Befehlsumgebung“ im sudoers(5)Handbuch dokumentiert, wie sich die -iOption auf die Umgebung auswirkt, in der ein Befehl ausgeführt wird, wenn die sudoers-Richtlinie verwendet wird.

Antwort4

Ich habe ein ähnliches Problem.
Ich löse es mit cron. Aber cron muss mit einem bestimmten Benutzer ausgeführt werden (z. B. Jenkins).

Machen Sie einfach einen Cron-Job:

$ crontab -u jenkins -e

Füllen Sie dann cron mit Ihrem Bedarf.

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

verwandte Informationen