空のパスフレーズでSSHキーを使用しても大丈夫ですか?


34

sshキーの作成方法を初めて学んだとき、私が読んだチュートリアルではすべて、良いパスフレーズを選択する必要があると述べていました。しかし、最近、別のマシンにsshする必要のあるデーモンプロセスを設定するとき、ブートごとに認証する必要のないキーがある(と思われる)唯一の方法は、空のキーを作成することであることを発見しましたパスフレーズ。だから私の質問は、パスフレーズなしでキーを使用することに関する懸念は何ですか?

回答:


38

パスフレーズのないキーは、他の誰もそのキーにアクセスできないことに依存しています(そのキーはアクセスできるリソースにアクセスできません)。そのため、キーがその隣のマシンへのアクセスを許可し、両方のマシンが同じレベルの電子的および物理的セキュリティを持っている場合、それは本当に大したことではありません。

一方、キーがセキュリティの低いマシン上にある場合(おそらく、多くの信頼できないユーザーがいる、物理的に簡単にアクセスできる、またはパッチ適用体制で十分に最新に保たれていない)、おそらくパスフレーズなしのキーをそこに保持したい。

最終的には、セットアップの信頼性とそれを行うリスク/コストの重さです。攻撃者がキーにアクセスするリソースよりも、攻撃者がキーにアクセスする方が現実的に簡単ではないと確信できる場合、その後は大丈夫です。自信がない場合は、おそらくその理由を修正する必要があります:)


キーを使用してマシンにアクセスできるのは信頼できる人だけなので、私の質問に答えていると思います。ありがとう。
mozillalives

11

セキュリティを強化すると同時にセキュリティを強化する別のソリューション。これにより、常にパスワードを入力する必要がなくなります。

秘密鍵を暗号化する場合ssh-agentは、ワークステーションで暗号化されていない鍵を「キャッシュ」することができます。復号化されたキーを保存する場合は、実行するssh-add ~/.ssh/id_rsaか、秘密キーに名前を付けます。パスワードの入力を求められ、ログアウト、強制終了、ssh-agentまたはシャットダウンするまで、復号化されたキーをssh接続で使用できます。

あなたはできるkillと鍵を格納しssh-agent -k、キーがでメモリ内にあるために、あなたは一生を割り当てることができますssh-agent -t [seconds]ので、例えば、鍵を永久に復号化したくないが、ホストの周りで多くのsshを行いたい場合は、タイムアウトを5〜10分に設定できます。そのため、キーのパスワードを継続的に入力する必要はありません。

繰り返しますが、これはすべて、/ workstation /のセキュリティにどれだけ自信があるかに関係しています。これは、自分だけがアクセスできる場合で、ローカルパスワードが非常に安全であり、自分にエクスプロイトやルートキットを招待すると、パスフレーズのない秘密鍵はかなり安全です。

あなたが私のようなもので、秘密鍵をサムドライブに保管している場合、それは単に秘密鍵(私のワークステーションで使用するものとは別のもの)であっても、間違いなく暗号化する必要がありますキーを紛失しました。サーバーの~/.ssh/authorized_keysリストからサムドライブの公開キーを簡単に削除できます。これにより、公開キーにUSEFULコメントを追加する/ excellent /理由が表示されます)

以前の回答への回答で、あなたは信頼できる人だけがキーを使ってマシンにアクセスできると言いました。私はあなたの秘密鍵があなたがしているものである場合には、あなたが接続しているサーバー上にある必要はないことを明確にしたいだけです。サーバー上に必要なのは公開鍵のみです。これは問題ではないため、「公開」鍵です。

ああ、言及するのを忘れました。私は起動ssh-agent私はXを起動したときに、それ以外の場合は私が保管し、脱暗号化されたキーがssh-add異なるを通じて保持されないxtermセッション、私はパスワード私は近いたびに再入力する必要がありxterm、私は打ち上げssh-addでは、私の中で。~/.xinitrcファイル、私が持っています:

if [ -x /usr/bin/ssh-agent ]; then
   eval $(/usr/bin/ssh-agent)
fi

ssh-agentは実行時に設定する必要のある環境変数を返すため、ssh-agentwrapped in の呼び出しがあります。環境変数はXセッション全体で一定です。eval~/.xinitrc


ええ-公開鍵をアップロードするだけでいいのはわかっています。あるサーバーを別のサーバーに接続しているだけです。それが私がそれについて言及した理由です。しかし、この明確で思慮深い答えを書いてくれてありがとう。
mozillalives

まあ、それを使用ssh-agentして使用ssh -A -i privkey user@hostすると、sshエージェントの転送が可能になり、最初のサーバーに秘密鍵を置くことなく、最初のサーバーからサーバーにアクセスできます。sshキー転送を有効にしなくても、sshチェーンはお勧めできませんssh -A。また、独自のセキュリティ上の懸念があります。サーバー上のキーを暗号化できない理由はありませんが、ワークステーション上のキーはパスフレーズなしです。
cpbills

3

WebサーバーのSSL秘密キーについて私が尋ねた同様の質問を見ることができます。基本的に、3つのオプションがあります。

  1. ファイルシステムのパーマでキーを保護します。
  2. パスワードで保護されたキーを使用し、再起動するたびにキーを手動で入力します。
  3. パスワードで保護されたキーを使用し、ファイルシステムにキーを保存して、再起動を自動化します。

それらのそれぞれには欠陥があるので、それはすべてあなたが最も恐れているものに依存します。


1

あなたが言うようにパスフレーズなしのキーを必要とする自動化されたアクセスのために、私は常にauthorized_keys(sshd(8)を参照)の追加オプションを使用して、実行できるコマンドを制限します。

通常、リモートエンドで慎重に記述されたスクリプトを提供します。このスクリプトは、許可するジョブ(またはジョブ-パラメーターを確認できます)を正確に実行します。

次に、そのキーで接続できるIPアドレスにロックダウンします(100%確実なわけではありませんが、コマンド制限でも問題ありません)。


優れた点-保護されていないキーを使用する必要がある場合、最善の方法はロックダウンすることです!
MikeyB

1

キー以外に誰もキーにアクセスできない限り、パスフレーズは不要です。実際、自動ソフトウェアで使用されるキーにパスフレーズを使用することはできません。


0

sshを使用して、あらゆる種類の自動化された手順を実行する場合(特にNagiosチェックについて考えている場合)、パスフレーズを使用することはおそらくないでしょう。

この状況では、おそらくLANの外部でこれを使用することはなく、手順を実行しているサーバーにキーを安全に保存できます。

SSHについて説明しているほとんどのチュートリアルでは、外部ネットワークからログインしている人、おそらく安全でないコンピュータからログインしている人を想定しています。その場合、アドバイスは適切です。

基本的に、正当な理由がない場合を除き、パスフレーズを作成します。毎回パスワードを入力するのが面倒なのは、あなたにとって十分な理由かもしれません:-)


外部ネットワークからログインした場合でも、どのように違いが生じますか?クライアントコンピューターのセキュリティのみが重要で、パスフレーズはクライアント側で処理されますよね?
njsg

誰かがSSHキーを無効にする前に、クライアントのラップトップが盗まれて境界を突破するまでは。キーのパスフレーズを使用すると、キーを取り消す時間が増えます。
dunxd

したがって、私が言ったように、「クライアントコンピュータのセキュリティのみが重要です」。
njsg
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.