sshキーの作成方法を初めて学んだとき、私が読んだチュートリアルではすべて、良いパスフレーズを選択する必要があると述べていました。しかし、最近、別のマシンにsshする必要のあるデーモンプロセスを設定するとき、ブートごとに認証する必要のないキーがある(と思われる)唯一の方法は、空のキーを作成することであることを発見しましたパスフレーズ。だから私の質問は、パスフレーズなしでキーを使用することに関する懸念は何ですか?
sshキーの作成方法を初めて学んだとき、私が読んだチュートリアルではすべて、良いパスフレーズを選択する必要があると述べていました。しかし、最近、別のマシンにsshする必要のあるデーモンプロセスを設定するとき、ブートごとに認証する必要のないキーがある(と思われる)唯一の方法は、空のキーを作成することであることを発見しましたパスフレーズ。だから私の質問は、パスフレーズなしでキーを使用することに関する懸念は何ですか?
回答:
パスフレーズのないキーは、他の誰もそのキーにアクセスできないことに依存しています(そのキーはアクセスできるリソースにアクセスできません)。そのため、キーがその隣のマシンへのアクセスを許可し、両方のマシンが同じレベルの電子的および物理的セキュリティを持っている場合、それは本当に大したことではありません。
一方、キーがセキュリティの低いマシン上にある場合(おそらく、多くの信頼できないユーザーがいる、物理的に簡単にアクセスできる、またはパッチ適用体制で十分に最新に保たれていない)、おそらくパスフレーズなしのキーをそこに保持したい。
最終的には、セットアップの信頼性とそれを行うリスク/コストの重さです。攻撃者がキーにアクセスするリソースよりも、攻撃者がキーにアクセスする方が現実的に簡単ではないと確信できる場合、その後は大丈夫です。自信がない場合は、おそらくその理由を修正する必要があります:)
セキュリティを強化すると同時にセキュリティを強化する別のソリューション。これにより、常にパスワードを入力する必要がなくなります。
秘密鍵を暗号化する場合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-agent
wrapped in の呼び出しがあります。環境変数はXセッション全体で一定です。eval
~/.xinitrc
ssh-agent
して使用ssh -A -i privkey user@host
すると、sshエージェントの転送が可能になり、最初のサーバーに秘密鍵を置くことなく、最初のサーバーからサーバーにアクセスできます。sshキー転送を有効にしなくても、sshチェーンはお勧めできませんssh -A
。また、独自のセキュリティ上の懸念があります。サーバー上のキーを暗号化できない理由はありませんが、ワークステーション上のキーはパスフレーズなしです。
あなたが言うようにパスフレーズなしのキーを必要とする自動化されたアクセスのために、私は常にauthorized_keys(sshd(8)を参照)の追加オプションを使用して、実行できるコマンドを制限します。
通常、リモートエンドで慎重に記述されたスクリプトを提供します。このスクリプトは、許可するジョブ(またはジョブ-パラメーターを確認できます)を正確に実行します。
次に、そのキーで接続できるIPアドレスにロックダウンします(100%確実なわけではありませんが、コマンド制限でも問題ありません)。
sshを使用して、あらゆる種類の自動化された手順を実行する場合(特にNagiosチェックについて考えている場合)、パスフレーズを使用することはおそらくないでしょう。
この状況では、おそらくLANの外部でこれを使用することはなく、手順を実行しているサーバーにキーを安全に保存できます。
SSHについて説明しているほとんどのチュートリアルでは、外部ネットワークからログインしている人、おそらく安全でないコンピュータからログインしている人を想定しています。その場合、アドバイスは適切です。
基本的に、正当な理由がない場合を除き、パスフレーズを作成します。毎回パスワードを入力するのが面倒なのは、あなたにとって十分な理由かもしれません:-)