Не вдається ввімкнути віддалений комп'ютер за допомогою скрипта оболонки в Crontab


11

Нижче наведено сценарій, який я намагаюся запустити, який працює без жодних проблем

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

Але як тільки я додаю його до crontab, він не дає мені користувача.

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

Будь ласка, дайте свої думки .....

може бути, крон демон працює, тому нам потрібно включити кілька двійкових файлів ...?


1
У дозволі відмовлено (publickey, gssapi-keyex, gssapi-with-mic, password). У дозволі відмовлено (publickey, gssapi-keyex, gssapi-with-mic, password). У дозволі відмовлено (publickey, gssapi-keyex, gssapi-with-mic, password).

Які ваші наміри щодо цього? Чого ти намагаєшся досягти. Просто ви знаєте, що ми не можемо допомогти в будь-якій зловмисній діяльності, якщо це ваш намір
Тімоті Фроу

Відповіді:


14

Ви можете встановити ssh-з'єднання протягом сеансу cron. Вам потрібно встановити автентифікацію відкритого ключа для доступу без пароля. Щоб це працювало, вам потрібно мати PubkeyAuthentication yesв кожному віддаленому сервері sshd_config.

Ви можете створити пару приватного / відкритого ключа із паролем або без нього. Якщо ви використовуєте парольну фразу (рекомендовану), вам також потрібно запустити ssh-агент. Без парольної фрази вам потрібно лише додати параметр -i your_identity_fileдо sshкомандного рядка. sshвикористовуватиметься $HOME/.ssh/id_rsaза замовчуванням.

Я повторив ваш приклад, використовуючи пару ключів із парольною фразою. Ось як я це зробив.

1) Створено пару ключів із парольною фразою. Збережено приватний ключ як ~/.ssh/id_rsa_test, який повинен мати правильні дозволи за замовчуванням. Ми можемо ввести порожню парольну фразу, оскільки вона не використовується.

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) Надіслав відкритий ключ на сервери, зробив те саме для всіх. Пам’ятайте, що їх потрібно PubkeyAuthenticationвключити.

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) Запустіть ssh-агент як службу -s. Це не вб'є це, якщо ви вийдете з системи. Його вихід - дійсний сценарій оболонки, встановлюючи середовище, щоб ssh-клієнт знав, як до нього підключитися. Ми зберігаємо це у файлі (дійсно потрібен лише перший рядок).

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) Завантажили вищезазначене до нашого поточного середовища, щоб ми могли використовувати ssh-addдля додавання наш приватний ключ ssh-agent. фразу зверху.

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) Перевірено це додано.

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) Сценарій, який я використав, трохи змінений, ніж ваш. Зауважте, що я не вклав команду ssh у дужки та не скористався зворотними посиланнями $(), що є кращою альтернативою для заміни команд (це bashсумісно, ​​ви не згадали, яку оболонку ви використовуєте). Я використовував таку саму команду ssh, що і ваша.

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) Мій crontab (зауважте, що мій shє насправді bash)

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

8) Вихід

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

Єдина проблема використання парольної фрази полягає в тому, що вам потрібно ввести її вручну хоча б один раз. Отже, вищезгадане не працюватиме автоматично після перезавантаження.


Чудово - дякую. Я можу жити з відсутністю автоматичного перезавантаження після перезавантаження, принаймні.
Пітер Мунс

Використовуйте ssh-cron для встановлення запланованих підключень SSH для захисту серверів, не піддаючи SSH-ключі, але використовуючи SSH-агент. unix.stackexchange.com/questions/8903/…
Luchostein

4

Хто вводить пароль? Завдання cron не може отримати ваш ssh-агент, тому відкритий ключ не працюватиме.

Вам потрібно надати sshчіткий файл ключа (див. -iОпцію), оскільки він не може запитувати агент; і цей ключ повинен містити порожню парольну фразу.


Пробував також передаючи ім'я користувача та пароль - ssh -t -t -o ConnectTimeout = 60 користувач @ машина $ 1 палець | хвіст -1 | awk '{print $ 1}' </ home / user / passwd ---- я маю на увазі домашній каталог на NFS, тому він підключається до Everymachine

Якщо ssh має якийсь сенс, він використовує /dev/ttyдля читання пароля замість stdin; це не працюватиме з cron.
geekosaur

Спробував давати варіант -i, але не пощастило! ---- ssh -o ConnectTimeout = 60 -i /home/subrahmanyam/.ssh/ unknown_hosts машина $ 1 палець | хвіст -1 | awk '{print $ 1}' ------ ПОПЕРЕДЖЕННЯ: Незахищений приватний ключовий файл! Дозволи 640 для '/home/user/.ssh/known_hosts' занадто відкриті. Рекомендується, щоб файли вашого приватного ключа НЕ були доступні іншим. Цей приватний ключ буде проігноровано. погані дозволи: ігнорувати ключ:

Чому він скаржиться known_hosts? Але так, потрібно стежити за дозволами - файл приватного ключа повинен бути в режимі 0600 або навіть 0400, який належить вам. Якщо вам потрібен ще якийсь користувач, який зможе ним скористатися, ви подивитесь на POSIX ACL або подібні.
geekosaur

Подумайте про це, я побачив, як GSSAPI пропонують там, і ще одна можливість - отримати ключ-вкладку та використати її для роботи kinitв cron. Однак, клавіатурні вкладки також вимагають такої ж обережності в дозволах; але sshпринаймні на них не скаржаться.
geekosaur

1

Замість того, щоб зберігати тимчасовий файл, як Forcefsck, я вважаю за краще використовувати findдля пошуку активного агента.

У темі сценарію, який потребує ssh-agent, я використовую:

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

Він шукає ssh-agentсокет і повертає перший. Він обмежений лише поточним користувачем, тому ви випадково не спробуєте скористатися іншими користувачами та отримати помилку, у якій відмовлено у дозволі. Також вам потрібно буде вже ввійти в систему з активом ssh-agent. (Ubuntu запускає агент при запуску GUI).

Якщо ви помістите це в інший сценарій, вам потрібно буде зателефонувати до нього sourceабо .тому, що йому потрібно встановити SSH_AUTH_SOCKзмінну.


0

Використовуйте ssh-cron для встановлення запланованих підключень SSH для захисту серверів, не піддаючи SSH-ключі, але використовуючи SSH-агент.


0

Ви можете запустити свій скрипт або команду в crontab, наприклад:

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

або

0 * * * * bash -c -l "ssh root@yourhost 'echo $HOSTNAME'"
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.