저는 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 사용)을 시도하고 jenkins에 추가했습니다. div id = “02bbf14171″>
파일은 /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
그리고 h 키 파일이 있습니다.
rsync -avuh --delete -e "ssh -i path/to/key.pem" [email protected]:/var/lib/jenkins/* /var/lib/jenkins
PS : 우분투로 실행하고 싶지 않은 유일한 이유 user는 내가 많은 일에서 failed: Permission denied (13)를 얻었 기 때문입니다 (파일은 jenkins가 소유하므로).
최종 목표 :
I “크론 작업을 수행하여 백업 젠킨스 인스턴스를 기본 인스턴스로 지속적으로 백업하려고합니다.
*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins
댓글
h3>
- 원격 호스트 authorized_keys 파일 또는 rsync 명령을 실행중인 서버에 ssh-key를 추가 했습니까?
- 질문은 ' 명확하지 않습니다. 모든 rsync 실행에는 소스와 대상이 있습니다. 소스 및 대상 시스템을 명확히 할 수 있습니까? 문제 해결을 위해 rsync는 ssh를 사용하므로 rsync보다 ssh 만 사용하는 것이 좋습니다. 소스에서 ssh -vvv jenkins @ < target >을 사용하고 여기에 출력을 붙여 넣으세요.
- 실패합니다 : 많은 일에 대한 권한이 거부되었습니다 (13). (파일은 jenkins가 소유하므로) " jenkins " 사용자입니까?
- ssh 키 생성을 시도한 내 ' 작성했습니다 (ssh-keygen 사용). jenkins로 로그인하여 /home/ubuntu/.ssh/authorized_keys (여기서 i ' m에서 rsync를 실행) 의 authorized_keys 파일에 추가했지만 대상 시스템의 authorized_keys 파일에 키를 추가해야합니다.
Answer
오래된 게시물이라는 것을 알고 있지만 다른 사람에게 도움이 될 수있는 경우를 대비하여 …
두 가지를 구분해야합니다.
- 누가 SSH 연결을 설정합니다 .
- 복사 할 파일을 소유 한 원격 사용자
개요
(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser | | sudo su jenkins | v jenkins 재 동기화를 원한다고 가정 해 보겠습니다.
- 보낸 사람 :
- 컴퓨터 :
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 연결을 설정 한 사용자 (iv id = “c4882b3f60)가 아닌 다른 사용자 (jenkins)와 함께 원격 시스템에서 rsync를 실행하려면 “>
).
요구 사항
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 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 사용자로, iv id = “7aa34de5d1″에 대한 에스컬레이드 권한이 있기 때문에 rsync 명령도 작동 함을 의미합니다. >
작동합니다.
나쁜 솔루션에 대한 참고 : 대상 사용자와 SSH 연결을 설정하십시오. jenkins
왜 안됩니까? 우리 그냥 이거?
(srcmachine) (rsync) (destmachine) srcuser -- SSH --> jenkins [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub] jenkins는 “서비스”계정이므로 포트를 노출하는 서비스를 실행 함을 의미합니다. (80 등) 외부 HTTP 액세스의 경우 HTTP를 통해 Jenkins 서비스를 통해 액세스 권한을 얻기 위해 보안 위반이 발생할 가능성이 있음을 의미합니다.
이것이 www-data 사용자 및 유사 사용자가 다른 서비스를 실행하는 이유입니다. 노출 된 포트에서 해킹 당할 경우 많은 작업을 수행 할 수 없습니다.
- 모든 것이 읽기 전용입니다.
-
/var/log/THE_SERVICE로 작성하는 것을 제외하고
따라서 jenkins 사용자의 SSH 액세스는 표면 공격을 노출합니다 (따라서 SSH 액세스의 경우 root !!).
또한 다른 사용자 (root, www-data 등)로 재 동기화하려면 해당 계정에 대한 SSH 키 공개 키 (문제).
좋은 솔루션 : 사용자 계정에 SSH 액세스를 가능한 한 적게 설정해야합니다. (destuser)는 를 원하는 “서비스”계정 (jenkins, root 등).
답변
다른 사용자로 rsync하는 것과 비슷한 문제가있었습니다. 다음 명령을 실행하여 문제를 해결했습니다.
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를 실행하려면 키를 사용해야 할 수도 있습니다.
p>
답변
sudo -u jenkins -i rsync ... 따옴표 없음 . p>
-i 옵션을 사용하면 sudo 명령이 ssh 키, , .bash_profile 등
sudo 사람 :
-i, --login대상 사용자의 비밀번호 데이터베이스 항목에 지정된 쉘을 로그인 쉘로 실행합니다. . 이는
.profile,.bash_profile또는.login와 같은 로그인 관련 리소스 파일이 명령이 지정되면 쉘의-c옵션을 통해 실행을 위해 쉘로 전달됩니다. 명령을 지정하지 않으면 대화 형 쉘이 실행됩니다.sudo는 셸을 실행하기 전에 해당 사용자의 홈 디렉토리로 변경을 시도합니다. 명령은 사용자가 로그인 할 때받는 환경과 유사한 환경에서 실행됩니다. 대부분의 셸은 대화식 세션과 비교할 때 명령이 지정 될 때 다르게 작동합니다. 자세한 내용은 쉘의 매뉴얼을 참조하십시오.sudoers(5)매뉴얼의 명령 환경 섹션은 sudoers 정책이있을 때-i옵션이 명령이 실행되는 환경에 미치는 영향을 설명합니다. 사용하십시오.
답변
비슷한 문제가 있습니다.
나 cron을 사용하여 이것을 해결하십시오. 하지만 크론은 특정 사용자 (예 : jenkins)로 실행해야합니다.
크론 작업을 만들기 만하면됩니다.
$ crontab -u jenkins -e 그런 다음 필요에 따라 크론을 채우세요.
*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log 댓글
-
rsync가 인증 문제로 인해 실패했습니다. 제안이 어떻게 도움이됩니까?