Не удается подключиться к удаленному компьютеру с помощью сценария оболочки в 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

Пожалуйста, дайте свои мысли .....

может быть, cron demon работает, поэтому нам нужно включить несколько бинарных файлов ...?


1
В доступе отказано (publickey, gssapi-keyex, gssapi-with-mic, пароль). В доступе отказано (publickey, gssapi-keyex, gssapi-with-mic, пароль). В доступе отказано (publickey, gssapi-keyex, gssapi-with-mic, пароль).

Каковы ваши намерения с этим? Чего ты пытаешься достичь. Точно так же вы знаете, что мы не можем помочь в любой злонамеренной деятельности, если вы этого хотите
Тимоти Фрю

Ответы:


14

Вы можете создавать ssh-соединения в cron-сессии. Вам нужно настроить аутентификацию с открытым ключом, чтобы иметь доступ без пароля. Чтобы это работало, вы должны иметь PubkeyAuthentication yesна каждом удаленном сервере sshd_config.

Вы можете создать пару секретный / открытый ключ с парольной фразой или без нее. Если вы используете фразу-пароль (рекомендуется), вам также нужно запустить ssh-agent. Без ключевой фразы вам нужно всего лишь добавить параметр -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-agent как сервис с -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/…
Лучостейн

4

Кто вводит пароль? Задание cron не может попасть в ваш ssh-agent, поэтому открытый ключ не будет работать.

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


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

Если у ssh есть какой-то смысл, он использует /dev/ttyвместо пароля пароль stdin; это не сработает от cron.
geekosaur

Пробовал давать вариант -i но не повезло! ---- ssh -o ConnectTimeout = 60 -i /home/subrahmanyam/.ssh/known_hosts машина $ 1 палец | хвост -1 | awk '{print $ 1}' ------ ВНИМАНИЕ: Незащищенный частный ключевой файл! Разрешения 0640 для '/home/user/.ssh/known_hosts' слишком открыты. Рекомендуется, чтобы ваши файлы закрытых ключей НЕ были доступны другим. Этот закрытый ключ будет игнорироваться. плохие разрешения: игнорировать ключ:

Почему это жалуется known_hosts? Но да, вам нужно следить за разрешениями - файл закрытого ключа должен быть в режиме 0600 или даже 0400, принадлежащем вам. Если вам нужен какой-то другой пользователь, чтобы иметь возможность использовать его, вы должны изучить POSIX ACL или аналогичные.
geekosaur

Если подумать, я увидел там GSSAPI, так что есть еще одна возможность получить keytab и использовать его для kinitработы cron. Тем не менее, keytabs также требуют такой же заботы в разрешениях; но, 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 запускает агент при запуске графического интерфейса).

Если вы поместите это в другой скрипт, вам нужно будет вызвать его с помощью 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.