ssh Odmowa dostępu tylko w zadaniu cron

Mając bardzo dziwny problem. Stworzyłem mały skrypt bash, który uruchamia polecenie na zdalnym hoście za pośrednictwem ssh (przy użyciu uwierzytelniania za pomocą klucza publicznego).

Kiedy uruchamiam ten skrypt ręcznie z wiersza poleceń, działa dobrze, ale po umieszczeniu w /etc/cron.hourly kończy się niepowodzeniem z Permission denied, please try again.błędem.

• Wyraźnie ustawiam klucz w skrypcie za pomocą ssh -i /root/.ssh/id_rsa user@remote "command";
• skrypt działa jako root (dodałem echo `id` > /tmp/whoami.logpodwójną kontrolę); i
• klucz ssh nie jest chroniony hasłem ...

System to serwer Ubuntu 12.04, nie mam dużego dostępu po stronie zdalnej do rozwiązywania problemów, ale jak powiedziałem, ręczne uruchamianie ssh lub tego samego skryptu bash z wiersza poleceń działa.

Każdy pomysł, dlaczego tak się dzieje lub jak to naprawić?

aktualizacja

okazuje się, że się pomyliłem, a klucz ssh był chroniony hasłem (z pękiem kluczy ładującym ssh-agenta), dlatego nie udało mu się to ze skryptu, ale nie podczas uruchamiania z sesji bash. Dodanie . ~/.keychain/$HOSTNAME-shdo mojego skryptu rozwiązało problem (dzięki @grawity, który wskazał mi właściwy kierunek i udzielił wyczerpującej odpowiedzi).

Polecenia interaktywne i zadania cron działają w różnych środowiskach - w szczególności sesja interaktywna może mieć uruchomionego agenta SSH lub przechowany Kerberos TGT. Ze względu na sposób sshzamawiania metod uwierzytelniania nie można mieć pewności, że klucz zostanie użyty tylko dlatego, że dodano -iopcję.

• Jeśli agent SSH jest uruchomiony, sshklient zawsze wypróbowuje klucze agenta przed użyciem jawnie określonych kluczy.

• Jeśli sieć korzysta z protokołu Kerberos i obecny jest protokół Kerberos TGT, OpenSSH użyje go przed próbą uwierzytelnienia za pomocą klucza publicznego.

Nic nie wiem o twoim środowisku, ale obie z tych możliwości są łatwe do sprawdzenia:

1. Dodaj unset SSH_AUTH_SOCKi unset KRB5CCNAMEprzed sshpoleceniem, a następnie ręcznie uruchom zmodyfikowany skrypt.

   Zapobiegnie to dostrzeżeniu przez skrypt agenta lub biletów Kerberos i będzie używał tylko wyraźnie określonego klucza.

2. Dodaj -vopcję do ssh. Spowoduje to wyświetlenie bardziej szczegółowych informacji o sposobie uwierzytelnienia.

Możesz także dodać -oIdentitiesOnly=yesdo sshpolecenia; to będzie zmusić go do korzystania z określonego klucza .

A jeśli dodasz wskazówki dotyczące uzyskiwania dostępu do agenta z crona - jeszcze lepiej

Zasadniczo nie jest to zalecane, ponieważ agent jest zwykle ściśle powiązany z interaktywną sesją logowania. W szczególności jest uruchamiany tylko po zalogowaniu, a zabijany po wylogowaniu - i potrzebuje twojego hasła, aby faktycznie odblokować klucze SSH (zakładając, że były chronione hasłem).

Wspomniałeś o „Keychain” - czy to program OS X, czy skrypt Linux? (Nie wiem dużo o architekturze Mac OS X, ale AFAIK znacznie utrudnia dostęp do ssh-agent użytkownika z cronjob ...)

Innym obejściem tego problemu jest ustawienie crona na ssh w polu lokalnym, aby z kolei uruchomić polecenie ssh zamiast uruchamiać plik lub polecenie przez jego lokalną, bezwzględną ścieżkę. To buforuje KRB5CCNAME i działa tam, gdzie / ścieżka / polecenie nie.

# 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

Możesz użyć ssh-cron do skonfigurowania zaplanowanych połączeń SSH do bezpiecznych serwerów bez ujawniania kluczy SSH, ale używając agenta SSH.

możesz uruchomić skrypt lub polecenie w crontab, takim jak:

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

lub

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