SSHパスワード認証がセキュリティリスクになるのはなぜですか？
OpenSSH構成のほとんどのガイドでは、キーベースの認証を優先して、パスワード認証を無効にすることを推奨しています。しかし、私の意見では、パスワード認証には重要な利点があります。キーがなくても、どこからでも接続できることです。常に強力なパスワードを使用する場合、これはセキュリティリスクになりません。それともそれをすべきですか？
Pwまたはキーベースの認証には、長所と短所があります。
たとえば、キーベースの認証は、パスワード認証よりもless安全です。他の場合では、安全性が低い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つの問題を回避できます。
パスワードを介したSSHの潜在的な利点の1つは、SSHパスフレーズを指定しない場合、パスワードを再度入力する必要がないことです。コンピューターは、キーを持っているため、サーバーで本質的に信頼されています。そうは言っても、私は通常SSHパスフレーズを常に使用するので、それを利用することにします。
ユーザーガイドがしばしばパスワード認証を介したSSHを推奨する理由についての最良の答えは、SSHOpenSSHKeysのUbuntuマニュアルから得られることです。引用する
それが重要だと思わない場合は、来週に受ける悪意のあるログイン試行をすべてログに記録してみてください。私のコンピューター（完全に普通のデスクトップPC）は、私のパスワードを推測する試みが4,000回を超え、先週だけでも約2,500回の侵入が試みられました。攻撃者がパスワードに遭遇するまでに、何千ものランダムな推測がかかると思いますか？
基本的に、句読点、大文字と小文字、数字を使用した堅固で長いパスワードを使用している場合は、おそらくパスワード認証で問題ありません。また、ログを監視する予定で、ネットワーク全体で「超安全」なものを実行していない場合、つまり、ホームサーバーにログを使用する場合。そうすれば、パスワードはうまく機能します。
すでにここで述べた良い点。
強力なパスワードを使用して基本事項に注意を払った場合、最大のリスクは、ユーザーが気付かないうちに多くのコンピューターにキーロガーがインストールされていることです。トロイの木馬を含む有用なユーティリティのサイト全体を作成している人もいるので、私たちの中で最高のことが起こります。キーロガーは、たとえば、ログインの詳細をハッカーにメールで送信し、ハッカーは簡単にサーバーにアクセスできます。
私は最近、Minecraft jarにフライトを追加するためにZombee Modインストーラー（jarではなくインストーラー）をダウンロードすることについてノートンから警告を受けました。詳細を見ると、ノートンはこのサイトにトロイの木馬が含まれているとマークされたユーティリティをたくさんリストしていました。これが正しいかどうかはわかりませんが、ファイル名に関してはかなり具体的でした。また、トロイの木馬が配布される前に（一部の）warezに入れられることも知られています。
Passwd authメソッドは本当に安全ではありません（imho）。このメカニズムにより、パスワードはsshdサーバーに送信されます（@ramonがすでに言ったように）。これは、一部の個人がsshdサーバーを変更してパスワードを取得できることを意味します。中間者攻撃では、ローカルネットワーク内でこれを実行するのは非常に簡単です。
このパッチをインストールすることで、sshdサーバーにパッチを適用できます（ https://github.com/jtesta/ssh-mitm ）。 arpspoofとiptablesを使用して、パッチを適用したサーバーをクライアントと本物のsshdサーバーの間に配置します。
パスワード認証を無効にしてください：設定ファイルを開きます/etc/ssh/ssh_configと行を追加PasswordAuthentication no。