☰

概要

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。

おすすめ記事