Nie można ssh zalogować się do zdalnego komputera przy użyciu skryptu powłoki w Crontab

Poniżej znajduje się skrypt, który próbuję uruchomić, który działa bez żadnych problemów

for i in `seq 200 2100`
do
  usr=(`ssh -t -t -o ConnectTimeout=60 machine$1 finger | tail -1 | awk '{print$1}'`) 
  echo $usr
done

Ale kiedy dodam go do crontab, nie daje mi to użytkownika.

22  12  *  *  *  sh /home/subrahmanyam/Scripts/who.sh

Proszę o przemyślenie .....

może być uruchomiony demon cron, więc musimy uwzględnić niektóre pliki binarne ...?

Możesz nawiązywać połączenia ssh w ramach sesji cron. Musisz skonfigurować uwierzytelnianie za pomocą klucza publicznego, aby mieć dostęp bez hasła. Aby to zadziałało, musisz mieć PubkeyAuthentication yesna każdym serwerze zdalnym sshd_config.

Możesz utworzyć parę kluczy prywatny / publiczny z hasłem lub bez niego. Jeśli używasz hasła (zalecanego), musisz także uruchomić ssh-agent. Bez hasła musisz tylko dodać parametr -i your_identity_filedo sshwiersza poleceń. sshużyje $HOME/.ssh/id_rsadomyślnie.

Powtórzyłem twój przykład, używając pary kluczy z hasłem. Oto jak to zrobiłem.

1) Utworzono parę kluczy za pomocą hasła. Zapisałem klucz prywatny jako ~/.ssh/id_rsa_test, który domyślnie powinien mieć odpowiednie uprawnienia. Możemy wprowadzić puste hasło, aby go nie użyć.

john@coffee:~$ ssh-keygen -N "somephrase" -f .ssh/id_rsa_test
Generating public/private rsa key pair.
Your identification has been saved in .ssh/id_rsa_test.
Your public key has been saved in .ssh/id_rsa_test.pub.
[snip]

2) Wysłał klucz publiczny do serwerów, zrobił to samo dla wszystkich. Pamiętaj, że muszą mieć PubkeyAuthenticationwłączone.

john@coffee:~$ ssh-copy-id -i .ssh/id_rsa_test server1
The authenticity of host 'server1 (11.22.33.1)' can't be established.
RSA key fingerprint is 79:e8:0d:f5:a3:33:1c:ae:f5:24:55:86:82:31:b2:76.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,11.22.33.1' (RSA) to the list of known hosts.
john@server1's password: 
Now try logging into the machine, with "ssh 'server1'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

3) Uruchom ssh-agent jako usługę z -s. To nie zabije, jeśli się wylogujesz. Jego wyjściem jest poprawny skrypt powłoki, ustawiający środowisko, aby klient ssh wiedział, jak się z nim połączyć. Zapisujemy to w pliku (naprawdę potrzebna jest tylko pierwsza linia).

john@coffee:~$ ssh-agent -s | head -n 1 > ssh-agent.cf 
john@coffee:~$ cat ssh-agent.cf 
SSH_AUTH_SOCK=/tmp/ssh-VhyKL22691/agent.22691; export SSH_AUTH_SOCK;

4) Załadowałem powyższe do naszego obecnego środowiska, dzięki czemu możemy użyć ssh-adddo dodania naszego klucza prywatnego ssh-agent. hasło z góry.

john@coffee:~$ source ssh-agent.cf 
john@coffee:~$ ssh-add  .ssh/id_rsa_test
Enter passphrase for .ssh/id_rsa_test: 
Identity added: .ssh/id_rsa_test (.ssh/id_rsa_test)

5) Zweryfikowano, że został dodany.

john@coffee:~$ ssh-add -l
2048 96:58:94:67:da:67:c0:5f:b9:0c:40:9b:52:62:55:6a .ssh/id_rsa_test (RSA)

6) Skrypt, którego użyłem, nieco zmodyfikowany niż twój. Zauważ, że nie umieściłem polecenia ssh w nawiasach i nie używam odwrotnych znaków $(), co jest lepszą alternatywą dla zastępowania poleceń (jest to bashkompatybilne, nie wspomniałeś o używanej powłoce). Użyłem dokładnie tego samego polecenia ssh, co twoje.

john@coffee:~$ cat foo.sh 
#!/bin/bash

source /home/john/ssh-agent.cf
for server in server1 server2; do
    usr=$(ssh -t -t -o ConnectTimeout=60 $server finger | tail -1 | awk '{print $1}')
    date=$(ssh -o ConnectTimeout=60 $server date)
    echo "$server - $date - $usr" >> /home/john/foo.log
done

7) Mój crontab (zauważ, że mój shtak naprawdę jest bash)

john@coffee:~$ crontab -l
# m h  dom mon dow   command
*/1  *  *  *  *  sh /home/john/foo.sh

8) Wyjście

john@coffee:~$ tail -n 4 foo.log
server1 - Wed Mar 23 14:12:03 EET 2011 - john
server2 - Wed Mar 23 14:12:04 EET 2011 - john
server1 - Wed Mar 23 14:13:03 EET 2011 - john
server2 - Wed Mar 23 14:13:04 EET 2011 - john

Jedynym problemem związanym z używaniem hasła jest to, że musisz wprowadzić je ręcznie przynajmniej raz. Tak więc powyższe nie będzie działać automatycznie po ponownym uruchomieniu.

Kto wpisuje hasło? Zadanie cron nie może dostać się do twojego agenta ssh, więc klucz publiczny nie będzie działał.

Musisz podać sshplik klucza jawnie (patrz -iopcja), ponieważ nie może on wysłać zapytania do agenta; i ten klucz musi mieć puste hasło.

Zamiast przechowywać plik tymczasowy, jak to robił forcefsck, wolę używać go finddo wyszukiwania na aktywnym agencie.

W temacie skryptu, który potrzebuje ssh-agent, używam:

export SSH_AUTH_SOCK=$(find /run/user/$(id -u)/ -mindepth 2 -maxdepth 2 -path '*keyring-*' -name 'ssh' -print -quit 2>/dev/null)

Wyszukuje ssh-agentgniazdo i zwraca pierwsze. Jest ograniczony tylko do bieżącego użytkownika, dlatego nie będziesz przypadkowo próbował użyć innych użytkowników i nie otrzymasz błędu odmowy uprawnień. Będziesz także musiał być zalogowany z aktywnym ssh-agent. (Ubuntu uruchamia agenta podczas uruchamiania GUI).

Jeśli umieścisz to w innym skrypcie, musisz wywołać go za pomocą sourcelub, .ponieważ trzeba ustawić SSH_AUTH_SOCKzmienną.

Użyj ssh-cron, aby skonfigurować zaplanowane połączenia SSH w celu zabezpieczenia serwerów bez ujawniania kluczy SSH, ale używając agenta SSH.

Możesz uruchomić swój 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'"