間違ったサーバーに接続しようとすると、SSHパスワードが明らかになりますか？

192

パスワード認証情報を使用して誤って間違ったサーバーに接続しようとすると、管理者は使用したパスワードを読み取ってログを記録できますか？

ssh password

— vfclists
ソース

11

— ジェームズリン

41

sshクライアントでは、最初にサーバーを認証してから、「このサーバーにパスワードを伝えることができると信じています」と言います。次回は、最初に見たメッセージにもっと注意を払ってください。「Xの信頼性は確立できません。RSAキーフィンガープリントはYです。本当にZですか？（yes / no）」この迷惑な質問は、毎回自動的にyesと答えます。

— クバンチク

6

PasswordAuthentication noOpenSSHでデフォルトで設定し、信頼できるサーバーに対してのみ（必要な場合に）有効にすることができます。厳密なホストキーチェックと組み合わせると、これはほとんどの場合、パスワードを公開することから保護されますが、当然ながらコストがかかります。

— ホッブズ

6

@kubanczyk、 "internal-www.my-company.com"にSSHで接続したいが、誤って "ssh www.my-company.com"と入力した場合、そのプロンプトはあなたを保護しません-両方のサーバーが信頼できるリストでは、そのうちの1つはあなたによって実行され、もう1つは第三者によって実行されます。

— マーク

@hobbs、ChallengeResponseAuthentication noあまりにも、私は思う

— ilkkachu

215

シンプルプット：はい

より詳しく...

私のマシンに接続すると、通常のsshサーバーを実行しているか、渡されたパスワードを書き出すように変更されたサーバーを実行しているかがわかりません。

さらに、必ずしも変更する必要はありませんが、パスワードを渡すsshdPAMモジュールを（たとえばを使用してpam_script）作成できます。

あ、はい。 決して信頼されていないサーバーにパスワードを送信しません。マシンの所有者は、試行されたすべてのパスワードをログに記録するように簡単に構成できました。

（実際、これはinfosecの世界では珍しいことではありません;ハニーポットサーバーを設定して、試行されたパスワードを記録します）

— スティーブン・ハリス
ソース

13

正しい。デフォルトでは、標準sshdはパスワードを記録しません。（ログイン名としてパスワードを入力すると、ログに記録されますが、それは別の問題です）。標準sshdはセキュリティツールであるため、このような資格情報は記録されません:-)

— Stephen Harris

116

公開/秘密キーペアを使用するさらに別の理由...

— gerrit

3

私はしばらくの間パスワードの使用について不思議に思っていましたが、最近、間違ったサーバーにログオンしようとすることは、悪意のあるサーバー管理者にパスワードを公開する良い方法だと思いつきました。

— vfclists

10

@vfclistsが間違ったサーバーにログオンすることも、sshdクライアントが各サーバーの指紋を保存する理由です。最初に接続するときに、その指紋を受け入れ、後でそれが一致しない場合は、注意すべき大きな警告が表示されます。

— ホームトースト

44

より良いアドバイス：sshにはパスワード認証を使用しないでください。プロトコルには非常に正当な理由でpubkey authがあります。これを使って！

— R ..

52

はい。

パスワードは暗号化された接続が確立された後に送信されますが、リモートサーバーはプレーンテキストでパスワードを取得します。

それを気にする場合、最良かつ最も簡単な解決策はSSHキーを使用することです。

キーを受け入れることができないマシンがある場合、1つの解決策は、パスワードを安全に保存sshpassし、接続先のサーバーに応じて常に正しいパスワードを送信するツールを作成することです。

ここで、パスワードがプレーンテキストで送信される理由は、パスワードの処理と保存に関するすべての決定をリモートエンドに委ねることであり、クライアントはまったく馬鹿げている可能性があります。過去10年ほどLinuxおよびBSDシステムで使用されているいくつかの異なるパスワードハッシュ（ストレージ）形式（crypt（3））がありますが、いずれもクライアントからのサポートを必要としません。

それも一部は歴史のせいです（つまり、常にそうでした）。パスワードを使用しても使用できる、より優れたチャレンジ/レスポンス認証プロトコルがあります。たとえば、認証中にパーティに共有シークレットを提供するSRP。一部のSSHサーバーに実装されていますが、OpenSSHのパッチは（非常に）古いバージョン用です。

— イルカチュウ
ソース

1

パスワード認証のチャレンジ/レスポンスプロトコルの問題は、それらの一部がサーバーにパスワードをプレーンテキストで保存することを要求することです。チャレンジ/レスポンスプロトコルでハッシュ化されたパスワードをサーバーが保存できる場合、非常に具体的なハッシュアルゴリズムが必要になる可能性があります。

— カスペルド

8

パスワードは一般に「プレーンテキスト」で送信されます（つまり、実際には平文ではなく、基礎となるSSH | TLS |接続が提供するもののみが保護されます）。システムがパスワードをクライアント側でハッシュし、ハッシュを送信するように要求した場合、サーバーは実際のパスワードを取得する方法を持たず、代わりにパスワードハッシュを提供できる人にアクセスを許可し、ハッシュをパスワードと同等にします。

— ブラックライトシャイニング

1

@BlacklightShiningゼロ知識パスワード証明は存在しますが、標準のパスワードデータベースを使用する方法がなく、キーベースの認証ではなくそれらを使用する実質的なポイントがないため、SSHでは使用されません。

— Random832

認証に使用されるパスワードはどこで確認できますか？それらは/var/log/auth.logにありません、どこですか？

— アレックス

OpenSSHは、失敗したかどうかにかかわらず、パスワードを記録しません。（私は他のSSHサーバーにあまり詳しくありません。）ほぼすべての正当なインストールでは、これが提供する可能性のある値は、意図的にパスワードを記録することに固有のリスクを上回ります。または、間違ってはいるが何か他のものとは異なるパスワードを平文で試しました。ただし、これを行う正当な理由がある場合は、OpenSSHにパッチを適用するのは簡単です。

— musicinmybrain

10

スティーブンハリスの答えの上に構築するために、変更されたPAM authスクリプトがssh（一種のハニーポット）に接続するときにキャプチャできるものを示すリアルタイムビューを作成しました。PAMライブラリーlib-storepwの修正バージョンを使用します。

https://livesshattack.net

https://livesshattack.net/about

— ウィリー・S
ソース

4

主にリンクである回答は、リンクが使用できなくなった場合に眉をひそめられます（このサイトを個人的に維持しているように聞こえますが、それでも）。読者用の認証スクリプトを使用して、これをどのように管理したかを少し説明する必要があります。

— -Centimane

それはもう機能していません、私はパスワードとして巨大な文字列を送信しました、私はそれを壊したかもしれないと思う：-/

— scottydelta

@scottydeltaまだ調べていませんが、PAMモジュールまたはSSHデーモン自体が認証の試行で受け入れることができるパスワードのサイズにバッファー制限がある可能性があります。このサイトは、sshdまたはPAMモジュールが実際にそうである場合に受け入れられるバッファー制限まで処理しますが、意図したとおりに動作しています。

— ウィリーS.

興味深いのは、変更したlib-storepwのソースが他の人が使用できるようになっていることですか？

— ティムフレッチャー

2

SSHは相互信頼を必要とするプロトコルです。これが、OpenSSHクライアントがknown_hostsファイルを保持して、最初の使用スキームで信頼を実装する理由です。

SSHサーバーにログオンしようとすると、ソフトウェアの提供者やログに記録されるデータに関係なく、認証手順に参加しています。パスワード認証を使用する場合、パスワードをそのサーバーに送信します。これが、非対称暗号化（公開鍵、証明書）が推奨される理由の1つです。公開鍵暗号化は、資格情報を開示するリスクを大幅に削減します。（ssh-agent転送または同様のスキームを使用している場合、MitM攻撃から保護されない場合があります。）

— jvoorhis
ソース

SSHは相互信頼、または少なくとも対称信頼を必要としません。正確であることが重要です。known_hostsは信頼性ではなく信頼性に関するものです。ご指摘のとおり、信頼性の低いホストに公開キーを置くことは安全です。確かに、パスワードを使用してログインすることは、そのパスワードを再利用しないと仮定した場合も「安全」です。（もちろん、サーバーを信頼する程度の安全性しかありません。）ホストベースのsshログインでさえ、非対称信頼に依存しています。

— マークハーン