Tại sao công việc cron rsync + ssh này mang lại cho tôi lỗi 'Quyền bị từ chối (khóa công khai)'?

Tôi thường xuyên sao lưu vào một ổ đĩa cục bộ mà tôi muốn đồng bộ hóa hàng ngày với một máy chủ từ xa.

Máy chủ đích được cấu hình chỉ để truy cập khóa SSH (không có mật khẩu). Vì khóa SSH chính của tôi cho máy chủ đó được bảo vệ bằng cụm mật khẩu, tôi đã tạo khóa SSH thứ hai (không được bảo vệ cụm mật khẩu) + để sử dụng cho các bản sao lưu không giám sát - theo cách này tôi không phải có mặt để nhập cụm mật khẩu của mình khi cron chạy .

Tôi đang sử dụng cron và rsync, và tất cả các lệnh hoạt động riêng lẻ, nhưng không thành công khi kết hợp.

Lần xa nhất tôi có trong khi xử lý sự cố đang chạy

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

trả về lỗi

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]

Bất kỳ lời khuyên về cách khắc phục sự cố này hơn nữa?

Đây là những gì tôi đã thử cho đến nay và tôi không có ý tưởng:

1. Cron chắc chắn đang chạy ps aux | grep cron

2. Không có gì bất thường trong / var / log / syslog Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. SSH trong Terminal đến máy chủ từ xa khi người dùng sao lưu hoạt động ssh backups-user@XX.XX.XX.XX

4. Chạy lệnh trong Terminal hoạt động hoàn hảo rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

5. Chỉ định thủ công đường dẫn đến khóa người dùng sao lưu không có hiệu lực rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

6. Thay thế lệnh không hoạt động bằng lệnh kiểm tra đơn giản hoạt động echo "Hello world" > ~/Desktop/test.txt

7. Hét lên / chửi rủa máy tính không có tác dụng (nhưng tạm thời khiến tôi cảm thấy tốt hơn).

Chỉnh sửa 1:

Đây là tập tin crontab của tôi và tập lệnh mà nó gọi.

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

và

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

Chỉnh sửa 2:

Nói rõ hơn, /var/log/auth.logtrên máy chủ đích chứa dòng Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootĐiều này thật khó hiểu vì tôi không còn chạy cron mỗi phút cục bộ, nhưng một mục mới vẫn xuất hiện mỗi phút trong nhật ký máy chủ. Các tệp Crontab cho tất cả người dùng (bao gồm cả root) trên máy chủ đều trống và không làm gì cả.

Ngoài ra, người dùng 'chỉ sao lưu' chỉ được tạo trên máy chủ và với các quyền hạn chế, với khóa SSH chuyên dụng được sao chép vào máy tính để bàn của tôi. Tôi cho rằng đây là cách để đi vì mọi thứ đều hoạt động khi chạy các lệnh theo cách thủ công.

Tệp crontab được đăng ở trên là dành cho tôi, người dùng 'tom' trên máy tính để bàn của tôi. Mục đích của tôi là để nó gọi tập lệnh sẽ đăng nhập vào máy chủ dưới dạng 'chỉ sao lưu' của người dùng. Tôi vừa thử chạy tập lệnh sao lưu (chứ không phải lệnh bên trong nó) và nó đã kết nối và làm việc thành công. Tôi đã chạy nó trên máy tính để bàn của mình với tư cách là người dùng 'tom', cùng một người dùng đã tạo ra công việc định kỳ không hoạt động. Đây là đầu ra từ nhật ký máy chủ tương ứng với thông tin đăng nhập thành công đó

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

Vì mọi thứ đều hoạt động tốt từ dòng lệnh, lỗi Permission denied (publickey)có nghĩa là phần SSH rsyncđang sử dụng một tệp nhận dạng khác với tên người dùng được chỉ định.

Từ nhận xét của Jan về câu hỏi ban đầu, chúng tôi có thể chỉ định tệp nhận dạng trong rsynclệnh bằng cách sử dụng -e 'ssh -i /path/to/identity.file' ....

Sử dụng lệnh dưới đây để bắt đầu với một môi trường mới trong cron và chỉ định đường dẫn đầy đủ đến tệp rõ ràng sẽ giải quyết được vấn đề:

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

_{Tôi vẫn thực sự quan tâm đến phát hiện này. Nó có thể phải làm với cron, thực tế là nó bắt đầu với các biến môi trường tối thiểu và tác nhân ssh. Tôi sẽ thiết lập kịch bản tương tự trong một vài ngày để kiểm tra và báo cáo lại.}

Tôi vừa giải quyết vấn đề này khiến tôi bận rộn ..

Không thể kết nối trong RSYNC qua SSH, mặc dù đã quy định danh tính cho SSH ... Không có gì được thực hiện ... Rupync nói "quyền bị từ chối" và ssh nói với tôi "read_passphrase: không thể mở / dev / tty: Không có thiết bị hoặc địa chỉ của loại này"

Nhưng tôi đã đọc một bài đăng giải thích rằng crontab có môi trường riêng không giống với root. Tôi đã biết điều đó nhưng tôi không hiểu tác động của nó đối với SSH khi sử dụng SSH-AGENT

Nhưng các trao đổi khóa SSH của tôi được thực hiện với PassPhrase ... vì vậy nếu môi trường khác và RSYNC của tôi qua SSH mong đợi một cụm mật khẩu không thể nhập => thông tin gỡ lỗi SSH cũng chỉ ra lỗi:

"debug1: read_passphrase: không thể mở / dev / tty: Không có thiết bị hoặc địa chỉ như vậy" => Vâng, không TTY = không có mật khẩu = không được phép

Trên máy của tôi, tôi sử dụng "Keychain" để khởi chạy tác nhân SSH để tôi không phải nhập lại cụm mật khẩu mỗi khi tôi thử kết nối từ xa. Keychain tạo một tệp chứa thông tin sau

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; xuất SSH_AUTH_SOCK; SSH_AGENT_PID = 18893; xuất SSH_AGENT_PID;

==> Lệnh SSH-AGENT trả về cùng một thông tin.

Vì vậy, cuối cùng, chính những thông tin này liên quan đến phiên hiện tại cho phép xác thực trong tương lai của phiên hiện tại mà không cần nhập cụm mật khẩu vì đã được thực hiện trước đó và ghi nhớ ...

==> Giải pháp là có ... nó là đủ trong tập lệnh do crontab khởi chạy và để "nguồn" tệp chứa thông tin này hoặc thực hiện trên dòng lệnh DS crontab ...

ví dụ: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh foo@my-server.fr :. >> / var / log / check_connexion.log 2> & 1 hoặc sử dụng lệnh "source /home/foo/keychain/foo.server.org-sh" trong tập lệnh bắt đầu kết nối bằng SSH.

=> Với nguồn này, không phải lo lắng nữa. Thông tin của SSH_AUTH_SOCK và SSH_AGENT_PID được tải trong môi trường của Crontab và do đó được biết, RSYNC trên SSH hoạt động mà không gặp vấn đề gì.

Nó đã giữ cho tôi bận rộn nhưng bây giờ, nó hoạt động :)

Hãy cẩn thận cho những người sử dụng SSH Agent Forwarding:

Nếu bạn thấy hành vi này khi gỡ lỗi tập lệnh trên máy chủ từ xa, thì đó là vì ngay cả với -e "ssh -i /path/to/key"cờ, ssh sẽ sử dụng khóa cục bộ (chuyển tiếp) của bạn chứ không phải tập lệnh trên máy chủ.

Ví dụ cụ thể: Tôi có một tập lệnh trên máy chủ dev lấy dữ liệu từ "máy chủ dữ liệu" bằng cách sử dụng rsync trên ssh. Khi tôi đăng nhập vào máy chủ dev và chạy nó, tất cả đều ổn, nhưng khi chạy từ cron, tôi bị từ chối. Thêm một số chi tiết vào quy trình SSH (cờ -vv) Tôi nhận thấy như sau:

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).

Điều khiến tôi băn khoăn ở đây là tình cờ, tôi tình cờ có một tên người dùng khác trên máy chủ cục bộ ("nighty") so với máy chủ dev ("juanr").

Lưu ý cách nó đánh dấu khóa trên máy chủ dev là "tường minh", nhưng vẫn sử dụng khóa được chuyển tiếp từ máy tính xách tay của tôi để đăng nhập. Thực hiện ssh-copy-idtại thời điểm này không giải quyết được gì, vì đơn giản là nó cài đặt lại khóa được chuyển tiếp chứ không phải là từ nhà phát triển máy chủ. Nếu bạn sử dụng ssh-copy-id với chuyển tiếp tác nhân, bạn cần chỉ định khóa nào sẽ cài đặt với cờ -i : ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Bạn đã thử thủ thuật cũ để dọn dẹp các tập tin máy chủ chưa? Ý tôi là:

rm ~/.ssh/known_hosts

Thật đáng để thử vì ssh sẽ xây dựng lại nó và bạn sẽ thoát khỏi những thứ cũ kỹ. Tất nhiên bạn cũng có thể loại bỏ các phần thuộc về một IP / Host cụ thể.

Câu hỏi khác: Công việc cron của bạn đang chạy theo UID của bạn hay nó đang chạy dưới dạng cron người dùng hoặc root?

Sử dụng rrsynctập lệnh cùng với khóa ssh chuyên dụng như sau:

Máy chủ từ xa

mkdir ~/bin
gunzip /usr/share/doc/rsync/scripts/rrsync.gz -c > ~/bin/rrsync
chmod +x ~/bin/rrsync

Máy tính cục bộ

ssh-keygen -f ~/.ssh/id_remote_backup -C "Automated remote backup"      #NO passphrase
scp ~/.ssh/id_remote_backup.pub devel@10.10.10.83:/home/devel/.ssh

Máy tính điều khiển từ xa

cat id_remote_backup.pub >> authorized_keys

Chuẩn bị cho dòng mới được thêm vào như sau

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

Vì vậy, kết quả trông giống như

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...vp Automated remote backup

ĐỊA PHƯƠNG

Đặt trong crontabtập lệnh sau với sự xcho phép:

#!/bin/sh
echo ""
echo ""
echo "CRON:" `date`
set -xv
rsync -e "ssh -i $HOME/.ssh/id_remote_backup" -avzP devel@10.10.10.83:/ /home/user/servidor 

Nguồn: http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

Để thử và gỡ lỗi, hãy thêm vào phần ssh "ssh -v" bằng cách này bạn có thể có chế độ dài dòng với một số thông tin hữu ích.

Chỉnh sửa: Từ trang người đàn ông:

-v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection,
             authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

Tôi nghĩ rằng bạn chưa cấu hình đúng tệp sshd_config. Xác nhận rằng PermitRootLogin yesvà PubkeyAuthentication yes để bảo trì từ xa.