39

svn アクティビティ ログを毎晩開発者にメールで送信する簡単なスクリプトを作成しました。今までsvnリポジトリと同じマシンで動かしていたので、認証の心配はなく、svnのfile:///アドレススタイルをそのまま使えました。

現在、自宅のコンピューターでスクリプトを実行し、リモート リポジトリにアクセスしているため、svn+ssh:// パスに変更する必要がありました。ssh-key が適切に設定されているため、通常の状況では svn リポジトリにアクセスするためにパスワードを入力する必要はありません。

ただし、crontab は私の ssh-keys / ssh-agent にアクセスできませんでした。私はこの問題についてウェブ上のいくつかの場所で読んだことがありますが、ここでもほのめかされていますが、解決策はありません。

ssh が crontab から失敗するのに、コマンドラインから実行すると成功するのはなぜですか?

私の解決策は、これをスクリプトの先頭に追加することでした：

### TOTAL HACK TO MAKE SSH-KEYS WORK  ###
eval `ssh-agent -s`

これは MacOSX 10.6 で動作するようです。

私の質問は、これがどれほどひどいものかということです。より良い方法はありますか?

4

11 に答える 11

37

加えて...

キーにパスフレーズがある場合、キーチェーンは 1 回尋ねます (マシンを再起動するか、ssh-agent を強制終了するまで有効です)。

キーチェーンはあなたが必要とするものです! インストールして、.bash_profile に次のコードを追加するだけです。

keychain ~/.ssh/id_dsa

したがって、スクリプトで以下のコードを使用して、ssh-agent 環境変数をロードします。

. ~/.keychain/$HOSTNAME-sh

注: keychain は、csh および fish シェルへのコードも生成します。

https://serverfault.com/questions/92683/execute-rsync-command-over-ssh-with-an-ssh-agent-via-crontabから回答をコピーしました

于 2011-08-02T18:58:56.967 に答える
23

ssh-agent -s を実行すると、後で強制終了する必要があるバックグラウンド プロセスが起動します。したがって、最低限、ハックを次のように変更する必要があります。

eval `ssh-agent -s` 
svn stuff
kill $SSH_AGENT_PID

ただし、このハックがどのように機能するのかわかりません。ssh-add を実行せずにエージェントを実行するだけでは、キーはロードされません。おそらく、MacOS の ssh-agent は、マニュアル ページに記載されている動作とは異なる動作をしている可能性があります。

于 2010-02-05T17:25:28.430 に答える
10

同様の問題がありました。私のスクリプト (ssh キーに依存していた) は、手動で実行すると機能しましたが、crontab で実行すると失敗しました。

適切なキーを手動で定義する

ssh -i /path/to/key

うまくいきませんでした。

しかし、最終的に、crontab が SSH を実行しているときに SSH_AUTH_SOCK が空であることがわかりました。正確な理由はわかりませんでしたが、

env | grep SSH

戻り値をコピーし、この定義を crontab の先頭に追加しました。

SSH_AUTH_SOCK="/tmp/value-you-get-from-above-command"

ここで何が起こっているのかについては詳しくありませんが、問題は解決しました。crontab がスムーズに実行されるようになりました。

于 2011-04-28T18:32:09.370 に答える
6

実行中の ssh-agent の pid とソケットを回復する 1 つの方法は、次のとおりです。

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-agent が 1 つしかないことを前提としています。複数の場合は、pgrep が最後に見つけたものを使用します。

于 2011-12-12T16:58:41.063 に答える
4

ここでの他の回答 (特に 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
于 2016-06-02T15:32:35.440 に答える
4

すでに SSH 設定を構成しており、スクリプトがターミナルから正常に機能すると仮定すると、キーチェーンを使用することは、スクリプトが crontab でも正常に機能することを確認する最も簡単な方法です。

ほとんどの Unix/Linux 派生製品にはキーチェーンが含まれていないため、ここでは段階的な手順を説明します。

1. OS のバージョンに応じて適切な 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 キーのキーチェーン ファイルを生成します。これらは ~/.keychain ディレクトリにあります。id_rsa の例:

keychain ~/.ssh/id_rsa

4. SSH 認証を使用する最初のコマンドの前の任意の場所に、次の行をスクリプトに追加します。

source ~/.keychain/$HOSTNAME-sh

私は個人的に、これに追加のプログラムを使用することを避けようとしましたが、私が試した他のすべてはうまくいきませんでした。そして、これはうまくいきました。

于 2014-02-28T04:20:52.937 に答える
2

あなたのソリューションは機能しますが、他の回答ですでに示されているように、毎回新しいエージェントプロセスが生成されます。

私は同様の問題に直面しましたが、このブログ投稿と、 githubのブログで言及されている Wayne Walker によるシェル スクリプトが役立つことがわかりました。

幸運を！

于 2016-02-23T12:50:10.607 に答える
2

キーチェーンを使用できず、スクリプトから ssh-agent を起動できない場合 (たとえば、キーがパスフレーズで保護されているため) に機能する解決策を次に示します。

これを 1 回実行します。

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 認証情報を使用できるようになるため、マルチユーザー環境では注意して使用してください。

于 2014-05-08T15:24:05.720 に答える