SSHに公開鍵認証を使用する必要があるのはなぜですか？
SSHサーバーを実行していますが、まだ単純なパスワード認証を使用しています。セキュリティについてどこで読んでも、公開鍵認証を使用することをお勧めします。しかし、私には利点がありません。それらを使用することは、私の目には安全ではないか、多くの便利な作業です。
もちろん、誰かが私のSSHサーバーへの総当たり攻撃を試みた場合、Public-Keyはどのパスワードよりもはるかに強力です。しかし、それは別として、それは完全に安全ではありません。
アドバイザーは主にパスワードを覚える必要がないと主張します。それはどれくらい安全ですか？つまり、誰かが私のコンピュータにハッキングした場合、彼は私のコンピュータを入手するだけでなく、私のサーバーも入手しますか？さまざまなクライアントからSSHを使用している場合、公開鍵を1つずつ保存する必要があるため、偽の手に渡る可能性が高くなります。一緒に携帯するUSBメモリに保存することもできますが、紛失したり、Finderからサーバーにアクセスしたりできます。
おそらく、2要素認証の方が適しています。
私が見逃している議論はありますか？私にとって最善の方法は何ですか？
誰かが私のコンピューターに侵入した場合、彼は私のコンピューターを入手するだけでなく、私のサーバーも入手しますか？
これはとにかくキーロガーに当てはまる可能性があります。侵入先のコンピュータからサーバーにログインするとすぐに、パスワードが取得されます。
ただし、キーには3つの利点があります。
1）キャッシュ可能な認証。パスフレーズを1回入力し、複数のsshコマンドを実行します。これは、scpをトランスポートとして使用するもの（scp、rsync、gitなど）を使用している場合に非常に便利です。
2）スケーラブルな認証。パスフレーズを1回入力します複数のマシンにログイン。マシンが多いほど、これはより便利になります。 100台のマシンがある場合、何をしますか？同じパスワードを使用することはできません（それがクローンファームでない限り）。また、その多くを覚えることはできません。したがって、パスワードマネージャーを使用する必要があり、単一の侵害ポイントに戻ります。事実上、キーパスフレーズisはパスワードマネージャーです。
2b）同じシステムを使用する複数の管理者がいる場合は、B、C、D、E、F ...にパスワードが変更されたことを通知せずにユーザーAからキーを取り消すことができるため、逆にスケーリングされます。
（これは個別のアカウントとSudoでも実行できますが、それらのアカウントを何らかの方法でプロビジョニングする必要があります）
3）自動化と部分的な委任。 SSHを キーが接続されたときに特定のコマンドを実行する に設定できます。これにより、システムAでの自動化されたプロセスは、システムBで何かを行うことができます。2つの間でパスワードなしの完全な信頼はありません。
（これは陽気に安全ではなかったrlogin/rshの代替品です）
編集：パスワードではなく公開キーのもう1つの利点は、サーバーが脆弱性によって侵害される一般的なシナリオです。この場合、パスワードを使用してログインすると、すぐにパスワードが侵害されます。キーでのログインはできません！これは、管理者の元のデスクトップが侵害されるよりも一般的だと思います。
適切なパスワードを使用している場合、これは十分に安全です。私は通常、公的にアクセス可能なサーバーの数を最小限に制限し、可能な限り特定のIPからのSSHを許可します。
また、パスフレーズ（パスワード）でキーを保護することもできます。したがって、サーバーにログインする必要があるときはいつでも、このパスフレーズを入力する必要があります。正しいパスフレーズが提供されない限り、だれもあなたの鍵を使用できません。
同様の投稿があります：
- serverfault からの投稿。
- security stackexchange からの投稿。
- superuser からの投稿。
公開キー認証がより安全な方法の1つは、攻撃者がクライアントコンピューターとサーバーの間の中間者（MitM）になり、ホストキーの変更に気付かない場合です（おそらくあなたが変更したため）古いキーを持っていない（たとえば、この特定のクライアントコンピューターを使用するのが初めての場合など）。
（攻撃者がサーバーを制御でき、同じ資格情報が機能する他のサーバーがある場合も同様です。）
標準のパスワードベースの認証では、パスワードを（暗号化された接続内で）プレーンテキストで送信します。正規のサーバーは通常それをハッシュし、その結果をパスワードデータベースに保存されているハッシュと比較します。 MitM攻撃者は、代わりにこのパスワードを取得し、実サーバーへの接続を開いてそこにログインし、コンテンツを転送する（何も気付かないようにする）か、サーバー上で独自の悪質なことを行う可能性があります。 。
公開鍵認証では、クライアントは基本的に、サーバーとクライアントの両方が知っているいくつかのデータに署名して、秘密鍵を所有していることを証明し、署名をサーバーに送信します。この署名されたデータには、セッション識別子が含まれます。これは、クライアントとサーバーの両方で選択された乱数に依存するため、セッションごとに異なります。 MitMが実サーバーへの独自のSSH接続を開くと、そのサーバーには別のセッションIDが割り当てられるため、クライアントから提供された署名はそこで機能しません。
もちろん、他の回答ですでに述べたように、秘密鍵を安全に保つ必要があります。パスフレーズで暗号化するか、PINを入力した後にのみ署名を作成する別のデバイスで可能です。
OpenSSHは独自のCAを保持してSSHホストとクライアントキーを管理し、それらの失効リストを使用できます。これにより、キーベースの認証によって提供されるセキュリティが強化される可能性があります。
「パスワードは必要ない」という主張は正しい。それはクライアント側では本当に安全ではありません。
onlyログインのための公開鍵をより安全に許可するのは、サーバーへのブルートフォースアクセスができないことです。攻撃者が達成できるすべてのことは、サーバーに負荷をかけることです-fail2banを使用して、それをチェックすることができます。
クライアント側のセキュリティのために、適切なパスフレーズで秘密鍵を保護する必要があります。もちろん、サーバーへの接続は、パスワードを使用するよりも面倒です。これを克服するために、sshエージェントを使用して、サーバーに連続して数回接続する場合は、秘密鍵をメモリに格納できます。キーがメモリに保持される期間を制限することをお勧めします。
おそらく、2要素認証の方が適しています。
SSHの2FAの1つの可能性（および比較的少ないセットアップ/複雑さを必要とする可能性）は、実際には公開鍵とパスワードを使用することです。
AuthenticationMethods publickey,keyboard-interactiveに沿って何かを/etc/ssh/sshd_configに追加して、それを機能させることができると思います。
より一般的には、問題は、パスワード（単独）は、多くの場合、疑わしい品質であるため、認証に適した方法ではないということです。キーとパスワードの非常に単純な「議論」は、キーは一般に少なくとも2048ビット、多くの場合はそれ以上になることです（ECキーの場合、これは実際のサイズではなく有効な強度になります）。これらのビットは、暗号学的に安全な（または適切な）メカニズムによっても生成されます。
多くの場合、パスワードは2048ビット未満であり、暗号化された安全なソースから派生したものではありません。
また、パスワードを使用してキーを保護し、キーの紛失に関連する問題を防ぐこともできます（ただし、誰かがそのパスワードをブルートフォースで攻撃する可能性があります）。
したがって、基本的には、キーとパスワードの違いをかなり透過的にすることができ、キーを使用すると、人間が扱えるよりも優れたパスワードを購入できます。これは万能薬だと言っているわけではありませんが、平均して、パスワードよりも高いセキュリティを提供します。