ssh-agentおよびscreen


8

StackOverflowに戻ってしばらくして、ssh-agentとcrontabについてこの質問をしました。Linuxシステムのssh-agentとscreenについて同様の質問があります。

つまり、私のMacでは、システムの起動時にssh-agentが起動するので、いつでもそれを利用できます。私がLinux(redhat el5 / fedora)でX-Windowsを使用している場合、それは正しいと思います。ただし、これはリモートサーバーマシンであり、常にssh経由でログインしています。

私はssh-keysを適切に設定したいので、svn updateまたはcommit中にパスワードを何度も入力する必要がありませんでした。セッションごとに1回パスフレーズを入力できてうれしいので、パスワードなしのsshキーをチームが作成しないようにしています。

短い間、私がログアウトしたときにssh-agentを強制終了するコマンドと組み合わせて、私の.bash_profileで「eval `ssh-agent -s`」を実行するように見えましたが、うまくいきました。ただし、長時間実行されるインタラクティブなプログラムや開発環境を管理するために、画面を多用しています。先ほど説明したようにssh-agentを起動および停止すると、ターミナルを終了するときにssh-agentが強制終了され、そのssh-agentインスタンスを参照していた画面のサブセッションが破棄されます。

では、どうすればscreenを使用し、sshキーでパスワードを使用し、パスフレーズを常に入力する必要がないコンソールユーザーになることができますか?

回答:


4

次の設定では、を呼び出すためのラッパーは必要ありませんscreen。さらに、/tmp(結果として生じるセキュリティリスクとともに)使用を回避します。

  1. 〜/ tmpディレクトリがあることを確認してください:

    mkdir ~/tmp
    
  2. .screenrc次の行に追加します。

    setenv SSH_AUTH_SOCK "$HOME/tmp/ssh-agent-screen"
    
    • これにより、insideはscreensshパスの変更ではなく、常に同じ場所でソケットを探します。
    • setenvシェルコマンドではなく画面であるため、使用するシェルを使用する必要があります。
  3. .bash_profile次の行に追加します。

    [ -n "$SSH_AUTH_SOCK" ] && [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ] && ln -sf "$SSH_AUTH_SOCK" "$HOME/tmp/ssh-agent-screen"
    
    • これは、固定された場所(にssh見える場所)から実際の場所にリンクし、の起動後に表示される必要がありますssh-agent
    • が設定されていない[ -n "$SSH_AUTH_SOCK" ]場合に使用すると、エラーが適切に防止SSH_AUTH_SOCKされます。
    • [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ]画面がソースの場合、$ HOME / tmp / ssh-agent-screenをそれ自体にリンクする画面セッションを防止します.bash_profile
  4. で開始ssh-agentする代わりに、.bash_profileで接続することを検討できますssh -A(エージェント転送を使用して、リモートマシンにエージェントを使用させるため)。

このセットアップ後は、標準の画面コマンドを使用できます。既存のセッションを再作成するか、セッション内のSSH_AUTH_SOCKを手順2の固定場所に手動で設定するだけで済みます。

アイデアのこのウェブサイトへのクレジット。の使用は避けました/tmpこの答えは似ていますが、追加のエイリアスを使用しています。


2

代わりにinitscriptからssh-agentを起動できます.bash_profileか?たとえば、私は置くかもしれません

su -c 'ssh-agent -s > ~/.ssh_agent_env' myusername

/etc/conf.d/localRHEL / Fedoraはおそらく別のシステムを使用していますが、の適切な部分で。コメントで指摘したように、ターミナルセッションはエージェントに接続できる必要があります。そのため、このコマンドは.ssh_agent_envユーザーのホームディレクトリにファイルを作成します。次に追加できます

[ -f ~/.ssh_agent_env ] && source ~/.ssh_agent_env >/dev/null

の中で.bash_profile

あなたができるもう一つのことは、以下を入れて .bash_profile

ps -U myusername | grep -q ssh-agent || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

これは、ssh-agentまだ実行されていない場合にのみ開始されます。その後、それを殺す必要はありません。

2番目の提案の少し異なる代替手段として、ssh-agentプロセスの存在を確認する代わりに、ファイルの存在を確認することができます~/.ssh_agent_env

[ -f ~/.ssh_agent_env ] || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

すべてが適切に機能していれば、2つの方法に大きな違いはありません。


initscriptのアイデアは興味深いものです。基本的に、システムの起動時にそれを開始したいすべてのユーザーのために開始しますか?それはうまくいくかもしれません。気になるユーザーはあまりいません。パスフレーズをまったく持たないよりもはるかに優れているかどうかは興味深い質問です。これは、マシンの再起動ごとに一度だけ入力する必要があることを意味していると思います。うーん。それと2番目の提案はどちらも、ssh-agentがすでに実行されている場合は、それに接続できる新しいターミナルセッションに依存しています。私はないんだけど、完全に確認してください、それは簡単ですが、私はまだ試していません。アイデアをありがとう!
マイケルH.10年

@khedron:はい。ただし/etc/conf.d/local、エージェントを使用するユーザーごとに1行(または同等の行)を入力して、ユーザーごとに個別のssh-agentプロセスを起動する必要があります。あなたが言っているように、あなたが膨大な数のユーザーを持っていないなら、それはそれほど悪くはないでしょう。あなたは、エージェントに接続するターミナルセッションについて(私が考慮し忘れていた)良い点を挙げます。回答の編集内容をご覧ください。
デビッドZ


2

より良いアプローチは、sshエージェント転送-Aオプション)を使用することです。これにより、sshを使用するユーザーは、送信元のマシン(おそらく実際に座っているワークステーション)で実行されているssh-agentのキーを使用できます。


これにより、アカウントを侵害する攻撃者が、そのエージェントがアクセスできる他のマシン上のアカウントを侵害することもできます。したがって、sshエージェントの転送を最小限に抑えるようにします。
ポールプライス

2

sshエージェントの転送をフォローアップすると、ログアウトして再度ログインし、セッションに再接続すると、転送されたssh資格情報がデフォルトでスクリーンセッションで使用できなくなることがわかります。

ただし、これを回避するには、画面でSSH_AUTH_SOCK環境変数を既知の値に設定し、その既知の場所を現在の認証ソケットに更新します。

このシェル関数を使用して画面を再入力し、ssh auth sockを修正します。

function sr () { 
    if [ ${+STY} = 1 ] ;then 
            echo already in screen\!
    else
            if [ "${SSH_AUTH_SOCK}x" != "x" ]; then
                    if [ ! -d /tmp/screenssh ]; then
                            mkdir /tmp/screenssh 
                    fi
                    rm -f /tmp/screenssh/socket
                    ln -s $SSH_AUTH_SOCK /tmp/screenssh/socket
                    echo $REMIP > /tmp/screenssh/remip
            fi                
            screen -DR
    fi
}

そして私は私の.screenrcにこれを持っています:

setenv SSH_AUTH_SOCK /tmp/screenssh/socket

お役に立てれば。


/ tmpを使用すると、マシン上の他の誰かがパスを知っていれば、ファイルを破壊することができます。
Blaisorblade 2013

1

私があなたの言うことを正しく理解している場合は、スクリーンセッションが必要です。このセッションでは、ときどき切り離して再接続しますが、ssh-agentのパスワード(秘密鍵のパスワード)を再入力する必要はありません。

ssh-agentをサブシェルで起動し、そのサブシェルにとどまるよりも、screenを起動するのが最も簡単な方法だと思います。すなわち

screen
ssh-agent bash
ssh-add   # enter your password once

# some commands, some logins and logouts to remote servers via ssh public key

# <ctrl>+<a>, <ctrl>+<d> to detach screen
# you can now logout from this computer
# login again

# reattach to your screen
screen -r
# ssh-agent is still running

それが本質的に私がすることです。私はscreenを使用して、内部の「タブ」の1つにssh-agentの権限があることを示すラベルを付け、svnの作業などに使用します。数時間後にssh-agentに再認証を強制する余分なしわがありますが、うん、これは基本的に私がいるところです。
マイケルH.
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.