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を実行しています) from)および_$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
_
私はそれが古い投稿であることを知っていますが、念のために他の人を助けることができます...
あなたは2つのことを区別する必要があります:
(srcmachine) (rsync) (destmachine)
srcuser -- SSH --> destuser
|
| Sudo su jenkins
|
v
jenkins
Rsyncしたいとしましょう:
srcmachine
srcuser
/var/lib/jenkins
destmachine
destuser
to 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
)とは別のユーザー(jenkins
)でリモートマシン上でdestuser
を実行するように指示することです。
(srcmachine) (rsync) (destmachine)
srcuser -- SSH --> destuser
[~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside
[~/.ssh/id_rsa.pub]
~/.ssh
の権限を制限することを忘れないでください:
chmod 700 ~/.ssh
destuser
のsudoerdestuser
には、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
コマンドも機能することを意味します。
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
で書くことを除いて。したがって、jenkins
ユーザーにSSHアクセスを許可すると、表面攻撃が発生します(したがって、SSHアクセスの場合はroot
!!として)。
さらに、別のユーザー(root
、www-data
など)としてrsyncを実行する場合は、SSHキーの公開鍵をそれらのアカウントにコピーする必要があります(面倒)。
適切な解決策:ユーザーアカウントへのSSHアクセスをできるだけ少なくする(destuser
)that CAN escaladateを "必要なサービス」アカウント(jenkins
、root
など)。
別のユーザーと同様の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を実行できるようにするには、キーを操作する必要がある場合があることに注意してください。