☰

개요

tag-icon • tag-icon ubuntu ssh rsync aws
개요

저는 AWS에서 두 개의 우분투 인스턴스를 사용하고 있습니다(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

추신: 우분투 사용자와 함께 실행하고 싶지 않은 유일한 이유는 failed: Permission denied (13)많은 것을 얻기 때문입니다(파일이 jenkins의 소유이기 때문입니다).

최종 목표:

cronjob을 실행하여 지속적으로 백업되는 기본 인스턴스와 함께 백업 jenkins 인스턴스를 유지하려고 합니다.

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

답변1

다음 두 가지를 구별해야 합니다.

  • 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

관련 정보