☰

概要

tag-icon • tag-icon ubuntu ssh rsync aws
概要

私はAWSで2つのUbuntuインスタンスを使用しています（pemキーを使用してアクセスします）。

両方のインスタンスにrsyncを設定し、デフォルトのユーザーubuntu@ipaddressを使用すると機能します。ただし、他のユーザーとrsyncを試みると（sudo su - jenkinsたとえば、rsyncコマンドの前に入力している場合sudo）、次のエラーが発生します。

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]

私が取ったアクション：

jenkinsログイン時にsshキー（ssh-keygenを使用）を作成し、それをauthorized_keysファイル/home/ubuntu/.ssh/authorized_keys（rsyncを実行した場所）とさらに$JENKINS_HOME/.ssh/authorized_keys（rsyncを実行した場所）に追加してみました。

私はPemキーを使って同じことをしてみましたが、それはうまくいきませんでした。

私が走りたいのはこれです。

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

これがコアファイルです

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

PS：Ubuntuユーザーと一緒に実行したくない唯一の理由は、failed: Permission denied (13)多くのものが得られるからです（ファイルがjenkinsの所有であるため）。

最終目標：

cronjobを実行して、継続的にバックアップされているプラ​​イマリインスタンスと一緒にバックアップjenkinsインスタンスを維持したいと思います。

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

答え1

次の2つを区別する必要があります。

  • WHOSSH接続設定。
  • どのリモートユーザーがファイルを所有するコピーしたいコンテンツ。

概要

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

rsyncが欲しいとしましょう。

  • から：
    • 機械:srcmachine
    • ユーザー：srcuser
    • 目次：/var/lib/jenkins
  • 到着する：
    • 機械:destmachine
    • ユーザー:destuserにSSH接続設定。
    • 目次：/tmp
    • 最終ファイルの所有者: jenkins。

解決策

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

説明する

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

ヒントは、SSH接続を確立したユーザー（）以外のrsyncユーザー（）を使用してリモートシステムで実行するように指示することです。jenkinsdestuser

必要

SSHアクセス

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

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

次の権限を制限することを忘れないでください~/.ssh。

chmod 700 ~/.ssh

Sudorはdestuser

あなたはdestuserそれを行う特権を持っている必要がありますsudo -u jenkins rsync。

destuser一般的にの会員に設定いたしますsudoers。これを行うには、root@ on destmachine：と入力します。

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

以前にテストするには、@rsyncにログインして次のコマンドを実行できます。destuserdestmachine

sudo su jenkins
echo $USER

返される場合:

jenkins

これはjenkins、ユーザーとしてログインしたことを意味し、rsync特権の昇格が機能するため、コマンドも機能することを意味しますjenkins。

悪い解決策に注意してください：ターゲットユーザーへのSSH接続の設定jenkins

私たちはこれをしたらどうですか？

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

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

これは「サービス」アカウントであるため、外部HTTPアクセス用にjenkinsポート（またはその他）を公開するサービスを実行すること80を意味し、HTTP経由でJenkinsサービスにアクセスすることがセキュリティの脆弱性になる可能性があります。

そのため、www-dataユーザーに似た人が異なるサービスを実行しています。公開されたポートがハッキングされた場合、できることはあまりありません。

  • すべてが読み取り専用です。
  • に書くことに加えて/var/log/THE_SERVICE。

したがって、jenkinsユーザーにSSHアクセスを許可すると、サーフェス攻撃が公開されます（SSHアクセスも同様ですroot！）。

rootまた、他のユーザー（など）に再同期するには、www-dataSSHキー公開キーをそのアカウントにコピーする必要があります（これは面倒です）。

良い解決策：設定する必要がありますユーザーアカウントへのSSHアクセスをできるだけ最小限に抑えます。( destuser) それアップグレード可能必要なサービスアカウント（など）に追加しjenkinsてくださいroot。

答え2

私は他のユーザーとしてrsyncing中に同様の問題に直面しました。次のコマンドを実行して問題を解決しました。

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

他のユーザーとしてrsyncを実行するには、キーストロークを使用する必要があります。

答え3

sudo -u jenkins -i rsync ...

そして引用符なし。

この-iオプションを使用すると、SSH キーなどを含むsudoユーザー環境でコマンドが実行されます。.profile.bash_profile

男性の場合sudo：

-i, --login

ターゲットユーザーのパスワードデータベースエントリで指定されたシェルをログインシェルとして実行します。これは、シェルが.profile、またはなどのログイン固有のリソースファイルを読み取ることを意味します .bash_profile。.loginコマンドが指定されると、-cシェルのオプションで実行できるようにシェルに渡されます。コマンドを指定しないと、対話型シェルが実行されます。 sudoシェルを実行する前に、そのユーザーのホームディレクトリに変更してみてください。このコマンドは、ユーザーがログインしたときに受信したのと同様の環境で実行されます。ほとんどのシェルは、インタラクティブセッションと比較してコマンドを指定した場合、動作が異なります。詳細については、シェルのドキュメントを参照してください。sudoers(5)マニュアルのコマンド環境セクションには、-isudoersポリシーを使用するときにこのオプションがコマンドが実行される環境にどのように影響するかが記載されています。

答え4

同様の問題があります。
cronを使用してこの問題を解決しました。ただし、cronは特定のユーザー（jenkinsなど）で実行する必要があります。

cronが動作するようにしてください。

$ crontab -u jenkins -e

その後、必要に応じてcronを充填します。

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

関連情報