☰

概要

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

私は AWS 上で 2 つの Ubuntu インスタンスを操作しています (これらにアクセスするには pem キーを使用します)。

両方のインスタンスに rsync を設定しましたが、ubuntu@ipaddress であるデフォルト ユーザーを使用すると動作します。ただし、別のユーザーで rsync を使用しようとすると (sudo su - jenkinsたとえば、sudorsync コマンドの前に入力すると)、次のエラーが発生します。

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]

私が実行した手順:

ログイン中に ssh キー (ssh-keygen を使用) を作成し、jenkinsそれを(rsync を実行している場所) と(そこからも rsync を実行しようとした場所)authorized_keysの両方のファイルに追加しました。/home/ubuntu/.ssh/authorized_keys$JENKINS_HOME/.ssh/authorized_keys

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 つの点を区別する必要があります。

  • 誰がSSH接続を確立する。
  • どれのリモートユーザーがファイルを所有しているコピーしたいもの。

概要

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

rsync を実行したいとします。

  • から：
    • 機械：srcmachine
    • ユーザー：srcuser
    • ディレクトリ：/var/lib/jenkins
  • に：
    • 機械：destmachine
    • ユーザー: destusertoSSH接続を確立する。
    • ディレクトリ：/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

sudoerのdestuser

destuserを行う権限を持っている必要がありますsudo -u jenkins rsync。

destuser一般的に、を のメンバーとして設定しますsudoers。これを行うには、root@で次の操作を行いますdestmachine。

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

事前にテストするにはrsync、destuser@にログオンしてdestmachine以下を実行します。

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]

これは「サービス」アカウントであるためjenkins、外部 HTTP アクセス用にポート (またはポート番号) を公開するサービスが実行され80、HTTP 経由で Jenkins サービスにアクセスすることでセキュリティ侵害が発生する可能性があることを意味します。

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

  • 彼らにとってすべてが読み取り専用です。
  • に書き込むことを除いて/var/log/THE_SERVICE。

したがって、ユーザーに SSH アクセスを許可すると、jenkins表面攻撃にさらされることになります (SSH アクセスの場合も同様ですroot!!)。

さらに、別のユーザー ( root、www-dataなど) として rsync を実行する場合は、SSH キーの公開キーをそれらのアカウントにコピーする必要があります (面倒です)。

良い解決策: 設定する必要がありますユーザーアカウントへの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によって読み取られます。コマンドが指定されている場合は、シェルのオプションを介してシェルに渡され、実行されます。コマンドが指定されていない場合は、対話型シェルが実行されます。は、 シェルを実行する前に、そのユーザのホーム ディレクトリへの変更を試みます。コマンドは、ユーザがログイン時に受け取る環境と同様の環境で実行されます。ほとんどのシェルは、コマンドが指定された場合と対話型セッションとで動作が異なることに注意してください。詳細については、シェルのマニュアルを参照してください。マニュアルのコマンド環境のセクションには、 sudoers ポリシーの使用時に、オプションがコマンドの実行環境にどのように影響するかが記載されています。.bash_profile.login-csudosudoers(5)-i

答え4

私も同様の問題を抱えています。cron
を使ってこの問題を解決しました。ただし、cron は特定のユーザー (例: jenkins) で実行する必要があります。

cron ジョブを作成するだけです:

$ crontab -u jenkins -e

次に、必要に応じて cron を入力します。

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

関連情報