ssh-agent и crontab-есть ли хороший способ заставить их встретиться?
Я написал простой скрипт, который каждую ночь отправляет журналы активности svn нашим разработчикам. До сих пор я запускал его на той же машине, что и репозиторий svn, поэтому мне не нужно было беспокоиться об аутентификации, я мог просто использовать стиль адреса svn:///.
теперь я запускаю скрипт на домашнем компьютере, получая доступ к удаленному репозиторию, поэтому мне пришлось перейти на svn+ssh: / / paths. С ssh-key красиво настроен, мне никогда не нужно вводить пароли для доступа к репозиторию svn под обычные обстоятельства.
однако crontab не имел доступа к моим ssh-ключам / ssh-агенту. Я прочитал об этой проблеме несколько мест в интернете, и она также упоминается здесь, без разрешения:
почему СШ не из кронтаб, но succedes при выполнении из командной строки?
моим решением было добавить это в верхнюю часть скрипта:
### TOTAL HACK TO MAKE SSH-KEYS WORK ###
eval `ssh-agent -s`
это, кажется, работает под MacOSX 10.6.
мой вопрос в том, как ужасно ли это, и есть ли лучший способ?
10 ответов
когда вы запускаете ssh-agent-s, он запускает фоновый процесс, который вам нужно будет убить позже. Итак, минимум состоит в том, чтобы изменить свой Хак на что-то вроде:
eval `ssh-agent -s`
svn stuff
kill $SSH_AGENT_PID
однако, я не понимаю, как этот хак работает. Просто запуск агента без запуска ssh-add не будет загружать ключи. Возможно, ssh-агент MacOS ведет себя иначе, чем его страница руководства говорит, что делает.
дополнительно...
Если ваш ключ имеют passhphrase, брелок спрошу еще (действителен до перезагрузки машины или убить SSH-агента).
брелок-это то, что вам нужно! Просто установите его и добавьте следующий код в ваш .файл:
keychain ~/.ssh/id_dsa
поэтому используйте код ниже в своем скрипте для загрузки переменных среды ssh-agent:
. ~/.keychain/$HOSTNAME-sh
Примечание: keychain также генерирует код для csh и рыбных раковин.
скопировал ответ из https://serverfault.com/questions/92683/execute-rsync-command-over-ssh-with-an-ssh-agent-via-crontab
у меня была похожая проблема. Мой скрипт (который полагался на ключи ssh) работал, когда я запускал его вручную, но не удалось при запуске с crontab.
вручную определение соответствующего ключа с помощью
ssh -i /path/to/key
не работает.
но в конце концов я узнал, что SSH_AUTH_SOCK был пуст, когда crontab запускал SSH. Не знаю почему, но я просто ... --4-->
env | grep SSH
скопировать возвращаемое значение, и добавил Это определение в голове моей список задач.
SSH_AUTH_SOCK="/tmp/value-you-get-from-above-command"
Я не понимаю, что здесь происходит, но это исправило мою проблему. Теперь crontab работает гладко.
один из способов восстановить pid и сокет запущенного ssh-агента будет.
SSH_AGENT_PID=`pgrep -U $USER ssh-agent`
for PID in $SSH_AGENT_PID; do
let "FPID = $PID - 1"
FILE=`find /tmp -path "*ssh*" -type s -iname "agent.$FPID"`
export SSH_AGENT_PID="$PID"
export SSH_AUTH_SOCK="$FILE"
done
Это, конечно, предполагает, что у вас установлен pgrep в системе, и есть только один ssh-агент работает или в случае нескольких из них он будет принимать тот, который pgrep находит последним.
мое решение-на основе pra-немного улучшено, чтобы убить процесс даже при сбое скрипта:
eval `ssh-agent`
function cleanup {
/bin/kill $SSH_AGENT_PID
}
trap cleanup EXIT
ssh-add
svn-stuff
обратите внимание, что я должен вызвать ssh-add на моей машине (scientific linux 6).
настроить автоматизированные процессы без автоматизированных взломов пароля / парольной фразы, Я использую отдельный IdentityFile, который не имеет парольной фразы, и ограничиваю записи authorized_keys целевых машин с помощью from="automated.machine.com" ... и т.д.
Я настроил хост remoteAuto .ssh / config:
Host remoteAuto
HostName remote.machine.edu
IdentityFile ~/.ssh/id_localAuto
и пульт.машина.Эду:ssh/authorized_keys с:
...
from="192.168.1.777" ssh-rsa ABCDEFGabcdefg....
...
тогда ssh не нуждается во внешней аутентифицированной авторизации, предоставленной ssh-agent или брелок.
вдохновленный некоторыми другими ответами здесь (особенно vpk), я придумал следующую запись crontab, которая не требует внешнего скрипта:
PATH=/usr/bin:/bin:/usr/sbin:/sbin
* * * * * SSH_AUTH_SOCK=$(lsof -a -p $(pgrep ssh-agent) -U -F n | sed -n 's/^n//p') ssh hostname remote-command-here
вот решение, которое будет работать, если вы не можете использовать keychain и если вы не можете запустить ssh-агент из своего скрипта (например, потому что ваш ключ защищен парольной фразой).
запустите это один раз:
nohup ssh-agent > .ssh-agent-file &
. ssh-agent-file
ssh-add # you'd enter your passphrase here
в скрипте, который вы запускаете из cron:
# start of script
. ${HOME}/.ssh-agent-file
# now your key is available
конечно, это позволяет любому, кто умеет читать~/.ssh-agent-file' и соответствующий сокет для использования ваших учетных данных ssh, поэтому используйте с осторожностью в любой многопользовательской среде.
предполагая, что вы уже настроили настройки SSH и что скрипт отлично работает с терминала, используя брелок это, безусловно, самый простой способ убедиться, что скрипт отлично работает и в crontab.
поскольку keychain не входит в большинство производных Unix/Linux, вот пошаговая процедура.
1. загрузите соответствующий пакет rpm в зависимости от версии ОС из http://pkgs.repoforge.org/keychain/. Пример для CentOS 6:
wget http://pkgs.repoforge.org/keychain/keychain-2.7.0-1.el6.rf.noarch.rpm
2. установить пакет:
sudo rpm -Uvh keychain-2.7.0-1.el6.rf.noarch.rpm
3. создание файлов ключей для вашего SSH-ключа, они будут расположены в~/.каталог ключей. Пример id_rsa:
keychain ~/.ssh/id_rsa
4. добавьте следующую строку в сценарий в любом месте перед первой командой, которая использует аутентификацию SSH:
source ~/.keychain/$HOSTNAME-sh
Я лично пробовал чтобы избежать использования дополнительных программ для этого, но все остальное, что я попробовал не сработало. И это сработало просто отлично.