web-dev-qa-db-ja.com

SSHへのログインに公開鍵を使用することは、パスワードを保存することよりも優れていますか?

公開鍵/秘密鍵のペアを使用すると、頻繁にホストにログインするのにかなり便利ですが、パスワードなしで鍵のペアを使用している場合、パスワードより安全ですか(安全性が低いですか)。私の秘密鍵ファイルの周りのセキュリティは最優先事項ですが、私の魔法の秘密鍵ファイルはさまざまなホストへのパスワードのリストだったと言いますが、違いはありますか?

69
Nick T

私の答えは、公開鍵のペアを使用することは、パスワードやパスワードのリストを使用するよりもはるかに賢明なことであるということです。さまざまな形式のSSH認証についてあまり知られていないことに焦点を当てますが、それらについて言及している他の回答はありません。

まず、ユーザー認証は、安全なチャネルの確立とは異なる個別のプロセスであることを理解する必要があります。簡単に言えば、これが意味することは、最初に、残りのセッションを保護するために使用される対称鍵のネゴシエーションを有効にすることにより、サーバーの公開鍵が使用されます(受け入れられた場合)、セキュアなSSHチャネルが構築されます。機密性、完全性保護、サーバー認証。

チャネルは機能的で安全であり、ユーザーの認証が行われます。これを行う2つの通常の方法は、パスワードまたは公開鍵ペアを使用することです。パスワードベースの認証は想像どおりに機能します。クライアントはパスワードをセキュアチャネル経由で送信し、サーバーはこれが実際に特定のユーザーのパスワードであることを確認してアクセスを許可します。公開鍵の場合、状況は大きく異なります。この場合、サーバーにはユーザーの公開鍵が格納されています。次に、サーバーがランダムな値(nonce)を作成し、それを公開鍵で暗号化してユーザーに送信します。ユーザーが本来のユーザーである場合、チャレンジを復号化してサーバーに送り返し、サーバーはユーザーの身元を確認します。それは古典的なチャレンジ-応答モデルです。 (SSHv2では少し異なるが、概念的に近いものが実際に使用されます)

ご想像のとおり、最初のケースではパスワードが実際にサーバーに送信され(SSHがパスワードチャレンジレスポンスを使用しない場合)、2番目のケースでは秘密鍵がクライアントを離れることはありません。誰かがSSLトラフィックを傍受し、それを解読できる(侵害されたサーバーの秘密鍵を使用するか、サーバーに接続するときに間違った公開鍵を受け入れる場合)、またはサーバーまたはクライアントにアクセスできる架空のシナリオでは、パスワード公開鍵と秘密鍵の認証とチャレンジレスポンスモデルを使用すると、秘密情報が攻撃者の手に渡ることはありません。そのため、接続している1つのサーバーが危険にさらされても、同じキーを使用する他のサーバーは危険にさらされません。

公開鍵のペアを使用することには、他にも利点があります。提案どおり、秘密鍵をクライアントPCにクリアテキストで保存しないでください。もちろん、これにより、暗号化されていないパスワードファイルと同じように、秘密鍵ファイルが危険にさらされますが、(ログイン時に)復号化して秘密鍵を使用する方が簡単です。これは保存する必要があります暗号化。使用するたびに暗号化を解除するには、通常長いパスフレーズを提供する必要があります。

もちろん、これは、サーバーに接続するたびに長いパスフレーズを提供して、秘密鍵のロックを解除する必要があることを意味します-その方法はいくつかあります。認証エージェントを使用して、システムの使いやすさを向上させることができます。これは、たとえばgnomeにログインしたとき、または最初にクライアントにsshしたときに、現在のセッションのキーのロックを解除するソフトウェアです。 「ssh remote-system-ip」と入力して、パスフレーズを入力せずにログインし、セッションからログアウトするまで複数回実行します。

つまり、要約すると、公開鍵ペアを使用するとかなり保護が強化されますクライアントサーバーの場合に取得できるパスワードまたはパスワードリストを使用するよりも=または安全なセッションが危険にさらされています。パスフレーズを使用しない場合(これは発生しないはずです)でも、公開鍵ペアは、侵害されたセッションおよびサーバーに対する保護を提供します。

84
john

保存された(長いランダムな)パスワードのリストと比較して、保存されたSSH秘密鍵は同じsecurityを提供します。プライベートファイルが非公開である限り、問題はありません。

ただし、秘密鍵ははるかに便利であり、どちらも実際には(現在のところ、SSHクライアントはそのまま使用できるため、一部のパスワードで使用する必要があるパスワードのカスタムファイルとは異なります手動コピー&ペースト)および理論的には(接続するホストごとに同じキーを再利用できますが、パスワードのリストは、複数のホストで同じパスワードを再利用しない限り、接続されたホストの数に比例して増加します。 悪い)。

15
Thomas Pornin

検討する脅威によって異なります。

公開鍵/秘密鍵認証の主なポイントは、認証している相手にさえ、秘密を漏らさないことです。このため、秘密を外部にマシンに送信することは決してないので、キーを使用する方が適切です。

ただし、考慮すべき脅威がローカルであり、秘密鍵をパスワードで保護しない場合、パスワードのリストを平文で保存することは、保護なしで秘密鍵を保存することとほぼ同じです。

このため、パスワードで秘密鍵を保護し、(便宜上)ssh-agentなどのツールを使用すると便利です。 OSXでは、これをKeyChainと統合することもできます。これにより、SSH(基本的には、KeyChainセキュリティデーモンがssh-agentを処理します)。

13
Bruno

SSH認証にパスワードなしの秘密鍵を使用する場合とプレーンテキストパスワードを使用する場合の主な違いは、自分が持っているもので認証する(秘密鍵)です。またはあなたが知っている何か(あなたの記憶されたパスワード)。品種は異なりますが、最終的にはより優れている、またはより安全であるとは言いがたいです。

何か持っているものによる認証は、通常、攻撃者が突然複製するのが難しくなります-キーを複製するよりも、単純なパスワードを総当たり/推測するほうが簡単です。しかし、これには大きな欠点があります-現在秘密鍵を本当に秘密にしておくことが最も重要になりますあなただけが知っている何か(記憶されたパスワード)を使用する場合、その方法で(少なくとも理論的には)維持する方が簡単です。しかし、それを覚える必要がある場合は、おそらくそれほど複雑ではないものを使用します。

ですから、何がより可能性が高いかを判断する必要があります。強力な秘密キーが盗まれたり、強力なパスワードが推測されたり(または他の方法で取得されたり)しません。

ここに1つの例外があります-秘密鍵を使用する代わりに秘密のファイルに本当に長くて複雑でランダムなパスワードを保存するという質問の場合、おそらく 2つの間の小さな違い まだ違いがあります(この部分を逃しました@ johnのこの記事の素敵な記事に対する回答を参照してください)。その場合、両方ともあなたが持っているものそれを秘密にしておくタイプ、だが それからあなた自身に尋ねてください-それが秘密鍵が設計されたものであるならば、なぜそれが最初にそれをするのですか? その場合は秘密鍵を保持する必要があります。

10
Karol J. Piczak

参考文献は、sshセッションで入力されたパスワードについて説明しています。私はそれとリチャードのコメントを維持する価値があると思いますが、もはや答え自体を信じていません。 (私はまだ公開鍵を好みます。)

Song、Wagner、およびTian は、sshからのタイミング情報を使用して、ブルートフォースパスワード検索を約50倍高速化できることを示していますセッション。 Noackは彼らの研究を再検討し、SSH2もタイミング分析に対して脆弱であることを発見しました。

攻撃は2つの仮定を行います。

  • パスワードハッシュはブルートフォースクラッキングに利用できます。
  • 攻撃者は、ホスト間で送信されたパケットの正確なタイムスタンプを取得したり、タイミング情報を取得したりできます。

公開鍵はより便利であるだけでなく、特定の脅威に対してより安全です。

8
sarnold

「ソフトウェア」キー(.sshディレクトリに保存されているキーまたは同等のもの)を使用している場合、基本的にはパスワードの保存と同じレベルです。

OpenSSHは、ほぼまともなPKCS#11サポートを備えています。これは、KiTTY(PuTTYフォーク)でも利用できるため、pubkey認証を実際に利用するには、スマートカードを使用します。次に、パスワードとは実際の違いがあります。パスワードで保護されたソフトウェアキーファイルは、プレーンパスワードと同じ方法で複製できますが、スマートカードは複製できません。

2
martin