SSHパスワード認証がセキュリティリスクになるのはなぜですか？

OpenSSH構成のほとんどのガイドでは、キーベースの認証を優先してパスワード認証を無効にすることを推奨しています。しかし、私の意見では、パスワード認証には重要な利点があります。つまり、キーなしで絶対にどこからでも接続できるということです。常に強力なパスワードを使用する場合、これはセキュリティ上のリスクにはなりません。またはそれをすべきですか？

pwまたはキーベースの認証には、長所と短所があります。

たとえば、場合によっては、キーベースの認証はパスワード認証より安全性が低くなります。それ以外の場合、そのpwベースは安全性が低くなります。場合によっては、1つがより便利であり、他の場合はより便利です。

つまり、キーベースの認証を行うときは、パスフレーズでキーを保護する必要があります。ssh-agentを実行していない限り（ssh-agentを使用すると毎回パスフレーズを入力する必要がなくなります）、利便性の面では何も得られません。セキュリティは議論の余地があります：攻撃ベクトルは、サーバーからあなた、またはあなたのアカウント、またはあなたの個人のマシンに移りました。

これを決定するとき、箱の外側を考えてください。セキュリティの面で利益を得るか失うかは、環境の残りの部分と他の手段に依存します。

編集：ああ、ちょうどあなたがホームサーバーについて話しているのを見た。私は常に同じ状況で、「パスワード」または「キーが付いたUSBスティック」を常に持っていましたか？前者に進みましたが、SSHリスニングポートを22以外のポートに変更しました。これにより、ネットワーク全体の範囲をブルートフォースするすべてのラメスクリプトキディーが停止します。

sshキーの使用には、パスワードログインと比較して1つの固有の機能があります。許可されたコマンドを指定できます。これは~/.ssh/authorized_keys、サーバーでファイルを変更することで実行できます。

例えば、

command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

その特定のキーを持つコマンド「/usr/local/bin/your_backup_script.sh」のみを許可します。

キーに許可されるホストを指定することもできます。

from="yourclient,yourotherclient", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

または、2つを組み合わせます。

from="yourbackupserver", command="/usr/local/bin/your_backup_script.sh", ssh-rsa auiosfSAFfAFDFJL1234214DFAfDFa...

キーを使用すると、特定のアカウントのパスワードを明かすことなく、一部のユーザー（コンサルタントなど）にサーバーへの一時的なアクセスを許可することもできます。コンサルタントが仕事を終えたら、一時キーを削除できます。

ネットワーク内からのみパスワード認証を許可することで、両方の長所を最大限に活用できます。の末尾に次を追加しますsshd_config。

PasswordAuthentication no
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
    PasswordAuthentication yes

質問に部分的に回答しました-攻撃者が接続できる場所が多いほど、ブルートフォーシングによってサーバーに侵入する可能性が高くなります（DDoSを考慮してください）。

また、パスワードの長さとキーサイズ（通常は数千ビット）を比較します。

パスワードを使用してログインすると、サーバーにパスワードを送信します。これは、サーバーのオペレーターがSSHDを変更してパスワードにアクセスできることを意味します。公開鍵認証では、公開鍵のみがサーバーに送られるため、彼らは秘密鍵を取得できません。

sshキーは、パスワードに対する中間者ベースの攻撃を防ぎます。

キーを使用してログインしようとすると、サーバーは公開キーに基づいてチャレンジを作成し、クライアントに送信します。暗号化を解除し、適切な応答を作成して送信します。

秘密鍵がサーバーに送信されることはなく、リッスンしているユーザーはその単一セッションを傍受する以外は何もできません。

パスワードで彼らはあなたの資格情報を持っているでしょう。

私の解決策は、USBキーの暗号化されたパーティションに適切な形式のポータブルsshキーを置くことです。これにより、次のことが可能になります。
キーが紛失した場合、そのキーを簡単に撤回できます。
アクセスできるサーバーを制限し
、それを持ち歩く

マウントソフトウェアのインストールは苦痛ですが（truecrypt）

@MartinVejmelkaが言うように、それはトレードオフです。

キーベースの認証を使用する理由は、キーが現在または将来のブルートフォースをはるかに上回っており、自分のPCからアクセスするか、USBスティックなどにキーを保持する必要があるためです。

パスワードには次の問題があります。

• それが短い場合、それは強引に強制することができます
• 長い場合は簡単に忘れられます
• 肩でサーフィンできた

キーは桁違いに長く、どの時点でも表示されないため、これらの3つの問題を回避できます。

ここですでに述べた良い点。

強力なパスワードを使用して基本事項を処理した場合、最大のリスクと考えられるのは、ユーザーが気付かないうちに多くのコンピューターにキーロガーがインストールされていることです。トロイの木馬を含む便利なユーティリティのサイト全体を作成している人もいるので、私たちにとって最高の事態になり得ます。キーロガーは、例えばログインの詳細をハッカーにメールで送信し、ハッカーは簡単にサーバーにアクセスできます。

最近、ノートンから、Minecraftのjarにフライトを追加するためのZombee Modインストーラー（jarではなく、インストーラー）のダウンロードについて警告を受けました。詳細を見て、ノートンはこのサイトにトロイの木馬を含むとマークされた多くのユーティリティをリストしました。これが正しいかどうかはわかりませんが、ファイル名に関してはかなり具体的でした。また、トロイの木馬が配布される前に（一部）ウェアーズに入れられることも知られています。

パスワードよりもSSHの潜在的な利点の1つは、SSHパスフレーズを指定しない場合、パスワードを再度入力する必要がないことです。コンピューターは、キーを持っているため、サーバー上で本質的に信頼されます。そうは言っても、私は通常SSHパスフレーズを常に使用するので、その利点を排除します。

ユーザーガイドがパスワード認証よりもSSHを頻繁に推奨する理由の最良の答えは、SSHOpenSSHKeysのUbuntuマニュアルから得られます。引用、

重要でないと思われる場合は、来週に発生する悪意のあるログイン試行をすべて記録してみてください。私のコンピューター（まったく普通のデスクトップPC）では、先週だけでパスワードを推測する4,000回以上の試行と、ほぼ2,500回の侵入試行がありました。攻撃者がパスワードを見つけ出すまでに、何千ものランダムな推測が必要だと思いますか？

基本的に、句読点、大文字と小文字、数字を含む堅固な長さのパスワードを持っている場合は、おそらくパスワード認証で問題ありません。また、ログを監視する予定があり、とにかくネットワーク全体で「非常に安全」なことをしていない場合...つまり、ホームサーバーに使用する場合。それから、パスワードはどうしてもうまくいきます。

passwd authメソッドは本当に安全ではありません（imho）。このメカニズムを使用すると、パスワードはsshdサーバーに送信されます（@ramonが既に述べたように）。これは、一部の個人がsshdサーバーを変更してパスワードを取得できることを意味します。Man-In-The-Middle攻撃では、これはローカルネットワーク内で非常に簡単に達成できます。

このパッチ（https://github.com/jtesta/ssh-mitm）をインストールするだけで、sshdサーバーにパッチを適用できます。arpspoofとiptablesを使用して、パッチを適用したサーバーをクライアントと本物のsshdサーバーの間に配置します。

パスワード認証を無効にしてください：設定ファイル/etc/ssh/ssh_configを開き、行を追加してくださいPasswordAuthentication no。

-o StrictHostKeyChecking=noオプションを使用してバイパスできます。これは、シェルスクリプトでsshを使用する場合に非常に便利です。

ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 -o PasswordAuthentication=no -o ConnectionAttempts=5 xxUser@xxxHost