☰

이 rsync + ssh cron 작업에서 '권한 거부(공개 키)' 오류가 발생하는 이유는 무엇입니까?

tag-icon • tag-icon permissions ssh backup cron rsync
이 rsync + ssh cron 작업에서 '권한 거부(공개 키)' 오류가 발생하는 이유는 무엇입니까?

매일 원격 서버와 동기화하려는 로컬 드라이브에 자주 백업합니다.

대상 서버는 SSH 키(비밀번호 없음) 액세스 전용으로 구성됩니다. 해당 서버의 기본 SSH 키는 암호로 보호되어 있으므로무인 백업에 사용할 두 번째 SSH 키(암호로 보호되지 않음) + 사용자 생성- 이렇게 하면 cron이 실행될 때 암호 문구를 입력하기 위해 참석할 필요가 없습니다.

cron과 rsync를 사용하고 있으며 모든 명령이 개별적으로 작동하지만 결합하면 실패합니다.

문제 해결이 실행되는 동안 내가 얻은 가장 먼 거리

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/"

이는 오류를 반환합니다.

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]

이 문제를 추가로 해결하는 방법에 대한 팁이 있습니까?

지금까지 시도한 내용은 다음과 같습니다. 아이디어가 없습니다.

  1. 크론이 확실히 실행 중입니다ps aux | grep cron

  2. /var/log/syslog에는 특별한 내용이 없습니다.Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

  3. 백업 사용자가 작업할 때 터미널에서 원격 서버로 SSHssh [email protected]

  4. 터미널에서 명령을 실행하면 완벽하게 작동합니다.rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

  5. backups-user 키에 대한 경로를 수동으로 지정해도 아무런 효과가 없습니다.rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

  6. 작동하지 않는 명령을 간단한 테스트 명령으로 교체하면 작동합니다.echo "Hello world" > ~/Desktop/test.txt

  7. 컴퓨터 앞에서 소리 지르거나 욕하는 것은 효과가 없었습니다(그러나 일시적으로 기분이 좋아졌습니다).

편집 1:

여기 내 crontab 파일과 그것이 호출하는 스크립트가 있습니다.

...
# m h  dom mon dow   command
MAILTO=""
* * * * * sh /home/tom/Documents/Scripts/offsite-backup

그리고

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/

편집 2:

명확히 하기 위해 /var/log/auth.log대상 서버에는 Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user root더 이상 로컬에서 매분 cron을 실행하지 않기 때문에 혼란스럽습니다. 그러나 서버 로그에는 매분마다 새 항목이 계속 표시됩니다. Crontab 파일모두서버의 사용자(루트 포함)는 비어 있으며 아무 작업도 수행하지 않습니다.

또한 '백업 전용' 사용자는 서버에서만 생성되었으며 제한된 권한을 가지며 전용 SSH 키가 내 데스크톱 컴퓨터에 복사되었습니다. 명령을 수동으로 실행할 때 모든 것이 작동하기 때문에 이것이 갈 길이라고 가정합니다.

위에 게시된 crontab 파일은 내 데스크탑 컴퓨터에 있는 사용자 'tom'을 위한 것입니다. 내 의도는 '백업 전용' 사용자로 서버에 로그인해야 하는 스크립트를 호출하도록 하는 것입니다. 방금 내부 명령이 아닌 백업 스크립트를 실행해 보았는데 성공적으로 연결되어 작동했습니다. 작동하지 않는 cron 작업을 만든 동일한 사용자인 'tom' 사용자로 데스크탑에서 실행했습니다. 성공적인 로그인에 해당하는 서버 로그의 출력은 다음과 같습니다.

Sep 11 08:35:31 <hostname> sshd[25071]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Sep 11 08:35:32 <hostname> sshd[25071]: Accepted publickey for backups-only from <desktop IP> port 54242 ssh2: RSA e2:e6:07:27:c1:continues...
Sep 11 08:35:32 <hostname> sshd[25071]: pam_unix(sshd:session): session opened for user backups-only by (uid=0)
Sep 11 08:35:32 <hostname> systemd-logind[638]: New session 12 of user backups-only.
Sep 11 08:36:00 <hostname> sshd[25133]: Received disconnect from <desktop IP>: 11: disconnected by user
Sep 11 08:36:00 <hostname> sshd[25071]: pam_unix(sshd:session): session closed for user backups-only

답변1

명령줄에서 모든 것이 제대로 작동하므로 오류는 Permission denied (publickey)SSH 부분이 rsync지정된 사용자 이름과 다른 ID 파일을 사용하고 있음을 의미합니다.

에서얀의 코멘트원래 질문에서는 를 rsync사용하여 명령 에 ID 파일을 지정할 수 있습니다 -e 'ssh -i /path/to/identity.file' ....

아래 명령을 사용하여 cron의 새로운 환경으로 시작하고 파일의 전체 경로를 지정하면 분명히 문제가 해결됩니다.

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [email protected]:/backups/desktop/"

나는 아직도 이 발견에 정말로 관심이 있다. 아마도 cron, 최소한의 환경 변수로 시작한다는 사실 및 ssh-agent와 관련이 있을 것입니다. 며칠 안에 동일한 시나리오를 설정하여 테스트하고 보고할 예정입니다.

답변2

나를 바쁘게 만드는 이 문제를 방금 해결했습니다..

SSH에 대한 ID를 규정했음에도 불구하고 SSH를 통해 RSYNC에 연결할 수 없습니다...아무 작업도 수행되지 않습니다... Rsync에 "권한이 거부되었습니다"라고 표시되고 ssh에서는 "read_passphrase: /dev/tty를 열 수 없습니다: 이 유형의 장치 또는 주소가 없습니다"라고 표시됩니다.

그런데 crontab에는 루트와 동일하지 않은 자체 환경이 있다고 설명하는 게시물을 읽었습니다. 이미 알고 있었지만 SSH-AGENT를 사용할 때 SSH에 미칠 수 있는 영향을 이해하지 못했습니다.

하지만 내 SSH 키 교환은 PassPhrase를 사용하여 수행됩니다. 따라서 환경이 다르고 SSH를 통한 RSYNC에서 입력할 수 없는 암호 문구를 예상하는 경우 => SSH 디버그 정보에도 오류가 표시됩니다.

"debug1: read_passphrase: can not open /dev/tty: No such device or address" => 음 예 아니요 TTY = 암호 문구 없음 = 허용되지 않음

내 컴퓨터에서는 "키체인"을 사용하여 SSH 에이전트를 시작하므로 원격 연결을 시도할 때마다 암호를 다시 입력할 필요가 없습니다. 키체인은 다음 정보가 포함된 파일을 생성합니다.

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; SSH_AUTH_SOCK 내보내기; SSH_AGENT_PID = 18893; SSH_AGENT_PID 내보내기;

==> SSH-AGENT 명령은 동일한 정보를 반환합니다.

따라서 결국 이전에 이미 완료하고 기억했기 때문에 암호를 입력할 필요 없이 현재 세션의 향후 인증을 허용하는 것은 현재 세션과 관련된 이러한 정보입니다.

==> 해결책은 거기에 있습니다 ...crontab이 시작한 스크립트에서 이 정보가 포함된 파일을 "소스"하거나 crontab 명령줄에서 수행하는 것으로 충분합니다.

예: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh[이메일 보호됨]:. >> / var / log / check_connexion.log 2> & 1 또는 SSH를 사용하여 연결을 시작하는 스크립트에서 "source /home/foo/keychain/foo.server.org-sh" 명령을 사용하십시오.

=> 이 소싱으로 더 이상 걱정하지 마세요. SSH_AUTH_SOCK 및 SSH_AGENT_PID 정보는 Crontab 환경에 로드되므로 이를 알 수 있으므로 SSH를 통한 RSYNC는 문제 없이 작동합니다.

그것은 나를 바쁘게 만들었지만 지금은 작동합니다 :)

답변3

SSH 에이전트 전달을 사용하는 사람들을 위한 주의 사항:

원격 호스트에서 스크립트를 디버깅할 때 이 동작이 나타나면 플래그가 있어도 -e "ssh -i /path/to/key"ssh가 서버에 있는 키가 아닌 로컬(전달된) 키를 사용하기 때문입니다.

구체적인 예: SSH를 통해 rsync를 사용하여 "데이터 서버"에서 데이터를 가져오는 개발 서버에 스크립트가 있습니다. 개발 서버에 로그인하여 실행하면 모든 것이 정상이지만 cron에서 실행하면 권한이 거부됩니다. SSH 프로세스(flag -vv)에 약간의 자세한 정보를 추가하면 다음과 같은 사실을 발견할 수 있습니다.

debug2: key: /home/nighty/.ssh/id_rsa (0x562d8b974820),
debug2: key: /home/juanr/.ssh/id_rsa (0x562d8b962930), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/nighty/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 1a:19:08:9f:80:16:b1:db:55:42:9a:52:b2:49:9b:0a
debug1: Authentication succeeded (publickey).

여기서 힌트를 얻은 것은 우연히 로컬 호스트("nighty")와 개발 서버("juanr")의 사용자 이름이 다르다는 것입니다.

개발 서버의 키를 "명시적"으로 표시하지만 여전히 내 랩톱에서 전달된 키를 사용하여 로그인하는 방법에 유의하세요. ssh-copy-id이 시점에서 수행하면 아무 문제도 해결되지 않습니다. 왜냐하면 단순히 개발 서버에서 전달된 키가 아닌 전달된 키를 다시 설치하기 때문입니다. 섬기는 사람. 에이전트 전달과 함께 ssh-copy-id를 사용하는 경우 -i 플래그를 사용하여 설치할 키를 지정해야 합니다 ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

답변4

호스트 파일을 정리하는 오래된 방법을 이미 시도해 보셨나요? 내 말은:

rm ~/.ssh/known_hosts

ssh가 다시 빌드하고 오래된 내용을 제거하므로 시도해 볼 가치가 있습니다. 물론 특정 IP/호스트에 속한 부분을 제거할 수도 있습니다.

추가 질문: cron 작업이 UID로 실행되고 있습니까, 아니면 사용자 cron 또는 루트로 실행되고 있습니까?

관련 정보