Giấy phép ssh chỉ bị từ chối trong công việc định kỳ

Có một vấn đề rất lạ. Tôi đã tạo một tập lệnh bash nhỏ chạy lệnh trên máy chủ từ xa thông qua ssh (sử dụng xác thực khóa chung).

Khi tôi chạy tập lệnh này theo cách thủ công từ dòng lệnh, nó hoạt động tốt, nhưng khi được đặt trong /etc/cron.hay thì nó bị Permission denied, please try again.lỗi.

• Tôi rõ ràng đặt khóa trong tập lệnh bằng cách sử dụng ssh -i /root/.ssh/id_rsa user@remote "command";
• tập lệnh đang chạy với quyền root (tôi đã thêm một echo `id` > /tmp/whoami.logđể kiểm tra lại); và
• Khóa ssh không được bảo vệ bằng mật khẩu ...

Hệ thống là máy chủ Ubuntu 12.04, tôi không có nhiều quyền truy cập ở phía xa để khắc phục sự cố, nhưng như tôi đã nói, chạy ssh bằng tay hoặc cùng một tập lệnh bash từ dòng lệnh hoạt động.

Bất cứ ý tưởng tại sao điều này đang xảy ra hoặc làm thế nào để khắc phục nó ??

cập nhật

Hóa ra tôi đã nhầm, và khóa ssh được bảo vệ bằng mật khẩu (với móc khóa tải ssh-agent), do đó tại sao nó không thành công từ tập lệnh mà không phải khi chạy từ phiên bash. Thêm . ~/.keychain/$HOSTNAME-shvào kịch bản của tôi đã giải quyết vấn đề (nhờ @grawity, người đã chỉ cho tôi đi đúng hướng và cung cấp câu trả lời toàn diện).

Các lệnh tương tác và công việc định kỳ chạy trong các môi trường khác nhau - cụ thể, phiên tương tác có thể có tác nhân SSH đang chạy hoặc Kerberos TGT được lưu trữ. Do cách thức sshđặt hàng phương thức xác thực, bạn không thể chắc chắn rằng khóa của bạn được sử dụng chỉ vì bạn đã thêm -itùy chọn.

• Nếu một tác nhân SSH đang chạy, sshmáy khách luôn thử các khóa tác nhân trước khi sử dụng bất kỳ khóa được chỉ định rõ ràng nào.

• Nếu mạng sử dụng Kerberos và có Kerberos TGT, OpenSSH sẽ sử dụng nó trước khi thử xác thực khóa công khai.

Tôi không biết gì về môi trường của bạn, nhưng cả hai khả năng này đều dễ kiểm tra:

1. Thêm unset SSH_AUTH_SOCKvà unset KRB5CCNAMEtrước sshlệnh, sau đó chạy thủ công tập lệnh đã sửa đổi.

   Điều này sẽ ngăn tập lệnh nhìn thấy đại lý hoặc vé Kerberos và sẽ chỉ sử dụng khóa được chỉ định rõ ràng.

2. Thêm -vtùy chọn vào ssh. Điều này sẽ hiển thị chi tiết hơn về cách xác thực xảy ra.

Bạn cũng có thể thêm -oIdentitiesOnly=yesvào sshlệnh; điều này sẽ buộc nó sử dụng khóa được chỉ định .

Và nếu bạn thêm mẹo truy cập đại lý từ cron - thậm chí tốt hơn

Điều này thường không được khuyến khích, vì các đại lý thường được liên kết chặt chẽ với phiên đăng nhập tương tác của bạn. Cụ thể, nó chỉ bắt đầu khi bạn đăng nhập và bị giết khi bạn đăng xuất - và nó cần mật khẩu của bạn để thực sự mở khóa các khóa SSH (giả sử chúng được bảo vệ bằng mật khẩu).

Bạn đã đề cập đến "Keychain" - đây là chương trình OS X hay tập lệnh Linux? (Tôi không biết nhiều về kiến ​​trúc của Mac OS X, nhưng AFAIK nó khiến việc truy cập ssh-agent của người dùng từ một cronjob trở nên khó khăn hơn nhiều ).

Một cách giải quyết khác cho vấn đề này là đặt cron thành ssh vào hộp cục bộ để lần lượt chạy lệnh ssh thay vì chạy tệp hoặc lệnh bằng đường dẫn tuyệt đối cục bộ của nó. Điều này lưu trữ KRB5CCNAME và hoạt động ở nơi / path / lệnh không.

# Fails:
0 * * * * /home/user/sshscript.sh

# Works:
0 * * * * /usr/bin/ssh user@localhost /home/user/sshscript.sh

#!/bin/bash
# Works:
unset SSH_AUTH_SOCK
unset KRB5CCNAME
/usr/bin/ssh user@localhost /home/user/sshscript.sh

Bạn có thể sử dụng ssh-cron để thiết lập các kết nối SSH được lên lịch tới các máy chủ bảo mật mà không để lộ các khóa SSH của bạn, nhưng sử dụng tác nhân SSH.

bạn có thể chạy tập lệnh hoặc lệnh của bạn trong crontab như:

0 * * * * bash -c -l "/home/user/sshscript.sh"

hoặc là

0 * * * * bash -c -l "ssh root @ yourhost 'echo $ HOSTNAME'"