Создание обратного SSH-соединения crontab с использованием скрипта

У меня есть компьютер за NAT, который устанавливает обратное SSH-соединение с моим Digitalocean VPC. Я использую это обратное SSH-соединение из дома, чтобы войти в свой офисный компьютер (я уполномочен на это), копировать файлы и делать другие важные вещи.

Хотя и не часто, я заметил, что мой офисный компьютер перезагружается (из-за сбоя питания и т. Д.) И разрывает обратное соединение SSH, которое он установил с моим VPC. В подобных случаях я не могу подключиться с домашнего компьютера к офисному ПК.

Я запускаю следующий сценарий, чтобы сделать обратное соединение + динамический прокси-сервер для анонимизации моего трафика (поскольку я не обязан обмениваться данными для просмотра), сгенерированного на офисном ПК.

autossh -CD 8080 -i digitalOcean -R 8081:localhost:22 root@IPofDigitalOceanPC

Ни при каких обстоятельствах я не смогу снова запустить этот сценарий на моем офисном ПК после перезагрузки, поскольку меня там нет. Для решения этой проблемы я установил следующий crontab.

Примечание. Файл rev.sh содержит вышеуказанную строку. Сертификат "digitalOcean" и rev.sh находится в Ubuntu home. Поэтому, когда я выполняю ./rev.sh в своем терминале Ubuntu, я получаю динамический прокси, а также доступ к своему серверу DigitalOcean. Этот метод работает на 100%.

Однако, когда я устанавливаю crontab следующим способом, мой компьютер с Ubuntu никогда не создает динамический прокси. Я вижу это, потому что когда я проверяю этот прокси из Google Chrome, он говорит, что прокси отказывается от соединения.

Вот cronjobs, которые я пробовал как cronjobs root. Я также пробовал их как обычный пользователь, но они не работали.

@reboot bash /home/user/rev.sh 
@reboot /home/user/rev.sh 
@reboot cd /home/user && ./rev.sh

Затем я установил crontab за несколько минут до текущего времени и дождался его запуска.

24 12 * * * bash /home/user/rev.sh
24 12 * * * /home/user/rev.sh
24 12 * * * reboot 

Они тоже не выполнялись.

Я также пробовал 48 15 * * * bash /home/user/rev.sh >> test3 и */1 * * * * reboot -f >> test, но test3 и test ничего не имеют. Однако файлы были созданы! crontab!

Пожалуйста, будьте любезны, чтобы помочь мне определить мою ошибку. На моем сайте много похожих вопросов по моей проблеме. Поэтому я привел много ответов, но ни один из них не помог.

6
задан 17 November 2016 в 13:20

1 ответ

Лучшее решение состояло бы в том, чтобы использовать сторожевой таймер. сторожевой таймер является демоном, который будет следить за рабочими процессами и если они выйдут, то автоматически перезапустит их.

Сторожевой таймер установки на Ubuntu 16.04

sudo apt-get install watchdog

Как сторожевой таймер работает

watchdog(8) демон выполнит сценарии в /etc/watchdog.d с аргументом test или repair. (см. TEST DIRECTORY раздел watchdog(8) страница справочника). Ваш сторожевой сценарий обрабатывает те два аргумента, когда он проверяет, чтобы видеть, выполняет ли процесс и принимает меры для восстановления его.

Можно настроить сторожевой таймер путем изменения /etc/watchdog.conf (См. watchdog.conf(5)).

Пример watchdog.d сценарий

Возьмите, например, /etc/watchdog.d/autossh_script (который имеет 755 полномочия и принадлежат root).

Примечание: Вы, возможно, должны настроить $targetuser переменная среды в сценарии в качестве примера. sam мое имя пользователя.

#!/bin/bash

targetuser=sam

runTest=false
runRepair=false

case $1 in
  test)
    runTest=true
  ;;
  repair)
    runRepair=true
    repairExitCode=$2
  ;;
  *)
    echo 'Error: script needs to be run by watchdog' 1>&2
    exit 1
  ;;
esac

if ${runTest}; then
  #run a test here which will tell the status of your process
  #the exit code of this script will be the repairExitCode if it is non-zero
  if ! pgrep autossh &> /dev/null; then
    #autossh not running; notify watchdog to repair
    exit 1
  else
    #autossh running; no action necessary
    exit 0
  fi
fi

if ${runRepair}; then
  #take an action to repair the affected item
  #use a case statement on $repairExitCode to handle different failure cases
  su - ${targetuser} -c 'nohup autossh -f -- -NCD 8080 -i digitalOcean -R 8081:localhost:22 root@IPofDigitalOceanPC'
  exit 0
fi
  • Я добавил -N к Вашему ssh команда в сценарии в качестве примера, таким образом, это только запускает туннель, но не пытается создать оболочку входа в систему.
  • Я добавил -f кому: autossh так, чтобы это работало в фоновом режиме.
  • Сценарий в качестве примера использует простое pgrep шаблон. Однако можно далее сузить тест определенному пользователю или даже использовать шаблон для процесса. Посмотрите pgrep(1) поскольку, как далее настроить Ваш тест с помощью pgrep.

Конфигурирование сторожевого таймера

/etc/watchdog.conf и /etc/defaults/watchdog места состоят в том, чтобы настроить сторожевой таймер. Посмотрите watchdog.conf(5).

Одной вещью отметить являются пользовательские сценарии, выполняются один раз во второй по умолчанию. Я рекомендую увеличить это по крайней мере до 30 секунд, если у Вас нет потребности в большем количестве проверки в реальном времени. Корректируйтесь interval начинание watchdog.conf.

Поиск и устранение неисправностей

Вы, возможно, должны создать /etc/watchdog.d каталог перед Вашим сценарием.

/var/log/watchdog/* содержит связанные со сторожевым таймером журналы и ошибки. Если Ваши выводы сценария к stdout или stderr затем это будет записано там. В моей системе я замечаю, что мой сценарий выполняется test или repair примерно один раз во второй. При использовании эха в сценарии, это должно только быть временным для отладки целей только. Иначе отбрасывание вывода рекомендуется кроме случая ошибок.

Если Ваш сценарий не работает вообще, затем проверяют полномочия: ls -l /etc/watchdog.d.

1
ответ дан 17 November 2016 в 23:20

Другие вопросы по тегам:

Похожие вопросы: