SSHに公開鍵認証を使用する必要があるのはなぜですか？

SSHサーバーを実行していますが、まだ単純なパスワード認証を使用しています。セキュリティについて読んだすべての場所で、公開鍵認証を使用することをお勧めします。しかし、私には利点がありません。私の目には、それらを使用することは安全ではないか、多くの便利な作業です。

もちろん、誰かが私のSSHサーバーへのログインを総当たり攻撃しようとすると、Public-Keyはどのパスワードよりもずっと強力です。しかし、それはさておき、それは完全に安全ではありません。

アドバイザーは主に、パスワードを覚える必要がないと主張します。それはどれほど安全ではありませんか？だから誰かが私のコンピューターにハッキングした場合、彼は私のコンピューターを手に入れるだけでなく、私のサーバーも手に入れますか？さまざまなクライアントからSSHを使用している場合、公開キーを1つずつ保存する必要があります。これにより、偽造された可能性が増大します。携帯用のUSBスティックに保存することもできますが、紛失する可能性があり、ファインダーからサーバーにアクセスできます。

おそらく、2要素認証の方が適切です。

私が紛失している議論はありますか？私にとって最善の方法は何ですか？

誰かが私のコンピューターをハッキングした場合、彼は私のコンピューターを取得するだけでなく、サーバーも取得しますか？

とにかく、これはキーロガーでは潜在的に当てはまります。侵入先のコンピューターからサーバーにログインするとすぐに、パスワードが取得されます。

ただし、キーには3つの利点があります。

1）キャッシュ可能な認証。パスフレーズを1回入力し、複数のsshコマンドを実行します。これは、scpをトランスポートとして使用するもの（scp、rsync、gitなど）を使用している場合に非常に便利です。

2）拡張可能な認証。パスフレーズを1回入力し、複数のマシンにログインします。マシンが多ければ多いほど、これは便利です。100台のマシンがある場合、何をしますか？同じパスワードを使用することはできません（クローンファームでない限り）。また、その多くを覚えることができません。そのため、パスワードマネージャーを使用する必要があり、単一の侵害ポイントに戻ります。事実上、キーパスフレーズはパスワードマネージャーです。

2b）同じシステムを使用する複数の管理者がいる場合は、パスワードが変更されたことをB、C、D、E、F ...に伝えることなくユーザーAからキーを取り消すことができるため、他の方法でスケーリングします。

（これは個々のアカウントとsudoでも実行できますが、それらのアカウントを何らかの方法でプロビジョニングする必要があります）

3）自動化と部分的な委任。キーが接続されたときに特定のコマンドを実行するようにSSHをセットアップできます。これにより、システムAの自動化されたプロセスは、2つのシステム間で完全なパスワードなしの信頼を持たずに、システムBで何かを実行できます。

（これはrlogin / rshの代替であり、陽気に安全ではありませんでした）

編集：パスワードではなく公開キーのもう1つの利点は、サーバーが脆弱性を介して侵害される一般的なシナリオです。この場合、パスワードを使用してログインすると、すぐにパスワードが侵害されます。キーでログインすることはできません！これは、管理者の元のデスクトップが危険にさらされるよりも一般的だと思います。

適切なパスワードを使用している場合、これは十分に安全です。私は通常、公的にアクセス可能なサーバーの数を最小限に制限し、可能な限り特定のIPからのSSHを許可します。

また、パスフレーズ（パスワード）によってキーを保護できます。そのため、サーバーにログインする必要があるときは常にこのパスフレーズを入力する必要があります。正しいパスフレーズが提供されない限り、誰もキーを使用できません。

同様の投稿があります：

1. serverfaultから投稿します。
2. セキュリティstackexchangeから投稿します。
3. スーパーユーザーから投稿します。

公開キー認証がより安全な方法の1つは、攻撃者がクライアントコンピューターとサーバー間の中間者（MitM）になり、ホストキーの変更に気付かない場合です（おそらく、 「この特定のクライアントコンピューターを使用するのはこれが初めてなので、古いキーはありません」。

（攻撃者がなんとかサーバーを制御するときに同じことが当てはまり、同じ資格情報が機能する他のサーバーがあります。）

標準のパスワードベースの認証では、暗号化された接続の内部でパスワードをプレーンテキストで送信します。正規のサーバーは通常それをハッシュし、その結果をパスワードデータベースに保存されたハッシュと比較します。MitM攻撃者は代わりにこのパスワードを取得し、実サーバーへの接続を開いてそこにログインし、コンテンツをあなたに転送するか（何にも気付かないように）、または単にサーバーで独自の悪事を行う可能性があります。

公開鍵認証では、クライアントは基本的にサーバーとクライアントの両方が知っているデータに署名して、秘密鍵を所有していることを証明し、署名をサーバーに送信します。この署名されたデータには、クライアントとサーバーの両方が選択した乱数に依存するセッション識別子が含まれるため、セッションごとに異なります。MitMが実サーバーへの独自のSSH接続を開くと、そのサーバーは異なるセッションIDを持つため、クライアントによって提供された署名はそこで機能しません。

もちろん、他の回答で既に述べたように、パスフレーズで暗号化するなど、PINを入力した後にのみ署名を作成する別のデバイスで秘密鍵を安全に保つ必要があります。

OpenSSHは、独自のCAを保持してSSHホストとクライアントキーを管理し、失効リストを使用できます。これにより、キーベースの認証によって提供されるセキュリティが強化されます。

あなたは「パスワードは必要ありません」という主張については正しいです。これは、クライアント側では本当に安全ではありません。

ログインに公開鍵のみを許可することの安全性を高めるのは、サーバーへのアクセスを総当たり攻撃する方法がないという事実です。攻撃者が達成できるのは、サーバーに負荷をかけることだけです-fail2banを使用して、それをチェックできます。

クライアント側のセキュリティのために、適切なパスフレーズで秘密鍵を保護する必要があります。もちろん、サーバーへの接続はパスワードを使用するよりも面倒です。これを克服するために、サーバーに連続して数回接続する場合は、sshエージェントを使用して秘密鍵をメモリに保存できます。キーをメモリに保持する期間を制限することをお勧めします。

おそらく、2要素認証の方が適切です。

SSH用の2FAの1つの可能性（およびセットアップ/複雑さを比較的ほとんど必要としないもの）は、実際には公開キーとパスワードの使用です。

その仕事AuthenticationMethods publickey,keyboard-interactiveを/etc/ssh/sshd_configするために、何かに沿って何かを追加できると思います。

より一般的には、パスワードは疑わしい品質のものであることが多いため、パスワード（単独）が認証の優れた方法ではないという問題があります。キーとパスワードの非常に単純な「引数」は、一般にキーが少なくとも2048ビット以上であるということです（ECキーの場合、これは実際のサイズではなく、有効な強度になります）。これらのビットは、暗号的に安全な（または適切な）メカニズムによっても生成されます。

パスワードは多くの場合2048ビット未満であり、多くの場合、暗号で保護されたソースから派生したものではありません。

また、キーをパスワードで保護して、キーの紛失に関連する問題から保護することもできます（ただし、誰かがそのパスワードを試行し、総当たり攻撃することもできます）。

したがって、基本的に、キーとパスワードの違いをかなり透過的にすることができ、キーを使用すると、人間が対処できるよりも優れたパスワードを購入できます。これは万能薬であると言っているわけではありませんが、平均して、パスワードよりも高いセキュリティを提供します。