この章では PuTTY や関連ツールが表示するいくつかの一般的なエラーメッセージを挙げ、どのような意味なのかをより詳しく説明します。
すべてのエラーメッセージをここで挙げるわけではありません。一度も起きないはずのエラーもありますし、それ自身が説明となるものもあります。もしこの章にないエラーメッセージで理解できないものがあったならば、バグとして報告をしてくれれば (appendix B 参照) 解説を追加します。
このエラーメッセージは PuTTY が新しい SSH サーバに接続したときに表示されます。サーバはそれぞれの持つホスト鍵を使って識別します。一旦 PuTTY がサーバのホスト鍵を知れば、もし悪意のある攻撃者が別のマシンに接続を向けようとしてもそれを検知できます。
このメッセージが表示されたら、それは PuTTY がそのホスト鍵をいままで受け取った事がなく、鍵が正しいかどうか判らないことを表します。あなたはホスト鍵を別の方法で検証しなくてはなりません。例えばマシンの管理者に尋ねます。
もしこのメッセージが表示されて、以前に PuTTY で同じサーバに繋いだことがあるならば、最近 SSH プロトコルバージョン 2 にアップグレードしたのかもしれません。 SSH プロトコルのバージョン 1 と 2 は別のホスト鍵を使います。そのためこれまで SSH-1 でしか接続していないサーバに初めて SSH-2 を使って接続すると、このメッセージが再び表示されます。以前と同様、鍵が正しいか検証する必要があります。
ホスト鍵についての詳しい情報は section 2.3 を参照してください。
“サーバのホスト鍵が PuTTY がキャッシュしたものと一致しません / The server's host key does not match the one PuTTY has cached for this server”と続くこのメッセージは PuTTY が以前にサーバに繋いだことがあり、ホスト鍵がどうあるべきか知っていて、それなのに違うものを受け取ったことを示します。
(メッセージが“証明書付きホスト鍵”について触れている場合は、section 10.3 を参照してください。)
これは悪意のある攻撃者がサーバを別の物に入れ替えたのかもしれませんし、ネットワーク接続をリダイレクトして自分のマシンに向けたのかも知れません。単にあなたのサーバの管理者が SSH ソフトウェアを更新するときに間違って鍵を変更したというのは、あってはならないことですが、残念ながら可能性はあります。
サーバの管理者に連絡して、ホスト鍵が変更されたかどうか確認するべきです。もしそうならば、新しいホスト鍵を、新しい鍵を確認する方法と同じやりかたで検証します。
ホスト鍵についての詳しい情報は section 2.3 を参照してください。
ホスト鍵の署名として一つ以上の認証局を信頼するように PuTTY を設定した場合 (section 4.21.4 参照)、PuTTY は SSH サーバに署名されたホスト鍵を送るよう要求します。もしサーバが異なる認証局が署名した鍵を送信してきた場合、PuTTY は“警告 - セキュリティ侵害の可能性! / WARNING - POTENTIAL SECURITY BREACH!”という注意と共にこの種のホスト鍵の通知を表示します。
これが起こりえる一つの原因として、意図的な攻撃があります。異なるホスト鍵を使った通常の中間者攻撃のように、特に野心的な攻撃者が全く不当な認証局を使い、あなたがそれでも接続してしまうのを期待するのです。
しかしこのエラーが正当に起こるいくつかの状況もあります。例えば、あなたの組織の情報システム部門が新しい認証局の鍵に切り替えて、あなたが PuTTY の設定に反映していない場合です。あるいは、あなたの認証局の設定が二つのドメインにまたがっている場合などもそうです。
そのため、あいにくとあなたが自分でどうするか考えださなくてはなりません。
もし認証局があなたの信頼しているものではなくとも、その特定のサーバが本物であるとあなたが確信しているならば、PuTTY は署名されたホスト鍵を署名されていないホスト鍵と同じようにキャッシュできます。そうすると以降の接続ではその特定の証明書はそのサーバに限って受け付けられます。しかし同じ認証局によって署名された他の証明書は依然として拒否されます。
デフォルトでは、PuTTY は SSH プロトコルバージョン 2 を実装した SSH サーバへの接続にしか対応していません。このメッセージが表示されたら、あなたが接続しようとしているサーバが古い SSH-1 プロトコルにしか対応していないということです。
サーバが正真正銘 SSH-1 にしか対応していないならば、“SSH プロトコルバージョン / SSH protocol version”設定を変更するか(section 4.19.4 参照)、-1 コマンドラインオプションを使います。どちらの方法でも、SSH-1 を使った接続は安全だと考えるべきではありません。
このメッセージを以前までは見かけなかったのに新しいバージョンの PuTTY (0.68 以降)で見るようになるかもしれません。これは以前まで PuTTY が SSH-2 から SSH-1 にフォールバックするように設定できたためです。この機能は、ダウングレード攻撃の可能性を排除するために、もはや実装されていません。
これはあなたが PuTTY で設定した十分に強いとする暗号に SSH サーバがまったく対応していないときに表示されます。デフォルトでは PuTTY は暗号化が Blowfish、single-DES、Arcfour の場合にのみ表示します。
このメッセージに関する詳細は section 4.22 を参照してください。
(ホスト鍵アルゴリズムなど、他の暗号プリミティブでも似たメッセージが存在します。)
このメッセージは OpenSSH (または Sun SSH) サーバで、許容しているよりも多い回数の認証に失敗した場合に表示されます。
Pageant を使っていて多数の鍵を読み込んでいると簡単に起こりえます。なぜならサーバは提示された公開鍵それぞれを認証の試行として数えるからです。 PuTTY の設定 (section 4.24.1 参照) で認証に必要な鍵を指定すると回避できます。 PuTTY は Pageant の持つ他の鍵を無視しますが Pageant に認証を任せるので鍵のパスフレーズを入力する必要はありません。
サーバ側では公開鍵認証を無効にするか (Sun SSH)、sshd_config の MaxAuthTries を増やします。
訳注: サーバ側の変更はあまり勧められません。認証失敗時にブロックする等のセキュリティが存在する場合、試行許容回数を増やすのは攻撃の機会を増やすことになります。
PuTTY がシステムの許容以上のメモリを割り当てようとすると起こります。これは本当にその場合もありえます。コンピュータがメモリ不足になった場合や、端末のスクロールバックの行数を非常に大きくした場合です。 PuTTY はメモリ不足になった状態からは復帰できません。エラーを表示した後はすぐに終了します。
しかし PuTTY がデータを間違った形式で受け取った場合、このエラーはメモリ不足でない状況でも起こります。 SSH-2 と SFTP ではサーバはメッセージ毎にまずその長さを送信します。そのため PuTTY はメッセージの長さを受け取ったら、メモリ空間を割り当て、それから残りのメッセージを受信します。もし PuTTY の受け取った長さがおかしかったら、膨大な量のメモリを割り当てようとして“メモリ不足”のエラーで終了するでしょう。
SSH-2 では、PuTTY とサーバが同じ方式で暗号化をしないと起こりえます (FAQ の question A.7.3 参照)。
PSCP や PSFTP でも起こりえます。サーバ上のログインスクリプトが出力を生成した場合、クライアントプログラムは SFTP メッセージの長さを受け取ると予定しているのにログインスクリプトからテキストを受け取るので、それをメッセージの長さとして解釈してしまいます。 Question A.7.4 を参照してください。
“内部 / Internal”で始まるエラーは絶対に起こらないはずです。もし起こったら、それは PuTTY のバグとなります。 Appendix B を参照し、私たちに報告してください。
[Custom] 本家版を使っても起こらない不具合は、元の作者に報告しないでください。
同様に、“Assertion failed”で始まるエラーメッセージは PuTTY のバグです。エラーメッセージボックスからテキストを正確にコピーしたものを含めて、私たちに報告してください。
この種のエラーは公開鍵認証の際に PuTTY ウインドウや PuTTY イベントログ (section 3.1.3.1 参照) に表示されます。もしくは Pageant で秘密鍵を読み込んだときです。
これらのメッセージが表示されたら、それは間違った種類の鍵を PuTTY, Plink, PSCP, PSFTP, Pageant に読み込もうとしたことを示します。
別プログラムの形式 (OpenSSH や ssh.com) の SSH-2 鍵を直接 PuTTY ツールに読み込もうとしても起こります。その場合 PuTTYgen を使って取り込んで PuTTY 標準の形式にする必要があります。 Section 8.2.15 を参照してください。
また、確立する接続に対して間違った鍵を指定したのかもしれません。 SSH-1 と SSH-2 プロトコルは異なった形式の秘密鍵が必要で、SSH-1 の鍵は SSH-2 接続に使えません (逆も同様です)。
公開鍵認証を試みたときに、この種のエラーは PuTTY ウインドウや PuTTY イベントログ (section 3.1.3.1 参照) に表示されます。
これらのメッセージが表示された場合、それは PuTTY がサーバに認証のために公開鍵を送ったもののサーバが受け取りを拒否したことを示します。通常これはサーバがそのユーザの認証に鍵を受け取るように設定されていないことを意味します。
これはほぼ間違いなく PuTTY の問題ではありません。もしこの種のメッセージが表示されたなら、まずするべき事はサーバの設定を注意深く確認することです。よくある間違いにはサーバの公開鍵やホームディレクトリのパーミッションや所有者の間違いがあります。また、PuTTY イベントログを読むとセットアップにある問題を説明した診断メッセージがサーバから届いている場合があります。
Section 8.3 にサーバ側の公開鍵設定に関するヒントがあります。
認証中に、この種のエラーは PuTTY ウインドウや PuTTY イベントログ (section 3.1.3.1 参照) に表示されます。
これらのメッセージが表示された場合、それは PuTTY が試みた認証すべてをサーバが拒否して他にできる認証方法がないことを示します。
イベントログを確認してサーバがより詳しい診断メッセージを送っているか確認するといいかもしれません。
このエラーはバグのある SSH-1 サーバでパスワードを転送する際にその偽装のために行う様々な戦略が失敗すると起こることがあります。サーバをアップグレードするか、section 4.29.14 や可能性として section 4.29.15 にある回避策を使います。
このエラーは PuTTY が SSH サーバに認証してもらう方法がなくなったことを示します。これは PuTTY が TIS や キーボードインタラクティブの認証を無効化しているせいかもしれません。その場合、section 4.23.5 や section 4.23.6 を参照してください。
このエラーは PuTTY が SSH パケットを復号してチェックサムが正しくない場合に起こります。これはおそらく暗号化や復号化の処理がうまくいかなかったせいです。このエラーメッセージから問題がクライアントにあるかサーバにあるか、それともその間なのかを判断するのは困難です。
特に、ネットワークが TCP レベルでデータを破損してしまった場合、SSH のような暗号化を行うプロトコルでしか明らかになりません。他のプロトコルではデータの整合性を確認して誤りを大々的に通知するなどしないからです。整合性の保護のないプロトコル (HTTP など) での破損は微妙な障害となって現れるので (テキストや画像がブラウザで異常表示されるなど) 気づかないかもしれません。
これはサーバのバグによっても時たま起こります。例として section 4.29.11 で述べたバグがありますが、近年は目にすることはごく稀です。
この文脈で MAC は Message Authentication Code (メッセージ認証コード) の略です。暗号学における用語で、Ethernet の MAC (Media Access Control) アドレスや Apple 社の Mac とは関係ありません。
このエラーは PuTTY が SSH パケットを復号してそのデータが意味を成さない場合に起こります。これはおそらく暗号化や復号化の処理がうまくいかなかったせいです。このエラーメッセージから問題がクライアントにあるかサーバにあるか、それともその間なのかを判断するのは困難です。
このエラーが起きた場合、設定のバグパネルより“SSH-2 暗号鍵の計算ミス / Miscomputes SSH-2 encryption keys” (section 4.29.13 参照) や“SSH-2 最大パケットサイズを無視する / Ignores SSH-2 maximum packet size” (see section 4.29.5)を変更してみるといいかもしれません。
この類のエラーは PuTTY が X 転送を行っている時に発生します。これらは SSH サーバ上の X アプリケーションに送り返され、通常はエラーとしてユーザに通知されます。
PuTTY が X 転送を有効にした場合 (section 3.4 参照)、仮想の X ディスプレイを SSH サーバ上に作成します。このディスプレイは接続するのに認証が必要です (これによって PuTTY はサーバマシン上の他のユーザが PuTTY プロキシを通してあなたの本当の X ディスプレイに接続するのを防ぎます。)。 PuTTY はサーバにクライアントが接続するのに必要な情報も送ります。そしてサーバはこの仕組みを自動的に整えて、X アプリケーションが普通に動作するようにしなくてはなりません。
これらのエラーメッセージが出るよくある理由として、SSH にあるユーザとしてログインし (仮に“fred”とします)、そして Unix の su コマンドで別のユーザ (大抵は “root”) になることがあります。元のユーザ“fred”は SSH サーバの提供した X 認証情報にアクセスでき、X アプリケーションを実行して、それが SSH 接続で転送されます。一方で別のユーザ (“root”) は認証情報を自動的には得ていません。そのためそのユーザとして X アプリケーションを実行しようとするとこのエラーで失敗します。
これが起こっても、“PuTTY による問題ではありません”。 X の認証情報を、ログインしたユーザから su で切り替えたユーザに渡す必要があります。これをどうやって行うかはシステムによって違います。最近の多くのバージョンの su は自動でこれを行います。
これは何らかの理由で確立した接続を切断した際に Windows のネットワークコードが返す一般的なエラーです。例えば、ネットワークケーブルをコンピュータから引き抜いた時や、Windows がネットワーク全体に到達できなくなったと判断すると起きます。
接続先のマシンの反応が得られない場合も Windows はこのエラーを表示します。クライアント・サーバ間のネットワークがダウンしてからデータを送信しようとすると、Windows は何度かデータを送信しようと試みた後、諦めて接続を切断します。特に、SSH-2 を使っていて PuTTY が鍵交換の再実行を行うと、何も入力していない場合でもこれが起こりえます。 (鍵交換の再実行については section 4.20.2 を参照してください。)
(また、keepalive を有効にしている場合にも起こりえます。一部の人たちは keepalive によって問題が直ったと報告しています。 keepalive の利点と欠点については section 4.16.1 を参照してください。)
私達の知る限り、PuTTY のバグが原因でこのエラーは起きません。問題はあなたか、Windows システムか、ネットワークか、リモートシステムにあります。
このエラーはネットワーク接続のどちらかの側のマシンが接続の状態をフォローできなくなると起こります。例えば、SSH サーバがクラッシュして、あなたが次にデータを送信しようとする前にサーバが再び起動しようとしていると起こるかもしれません。
しかしこのメッセージが出る最もよくある理由はファイアウォールやNAT ルータ越しに接続していて、接続がタイムアウトした場合です。詳しくは FAQ の question A.7.8 を参照してください。 Keepalive を使うと状況を改善できるかもしれません。詳細は section 4.16.1 を参照してください。
Windows はこのエラーをサーバからの接続のリセットがなくても生成する場合があります。例えばネットワーク接続が切れた場合です。
このエラーは PuTTY が行おうとしたネットワーク接続がサーバに拒否されたことを意味します。通常 PuTTY がアクセスしようとしたサービスをサーバが提供していない場合起こります。
正しいプロトコル (SSH, Telnet など) で接続しているか、ポート番号が正しいかを確認します。もしそれでもだめならば、サーバの管理者に問い合わせます。
このエラーはあなたとサーバの間のいずれかのファイアウォールによっても起こり得ます。ファイアウォールは接続を拒否し、実際のサーバが送るであろうエラーパケットと同じ種類のものを送り返します。
このエラーは PuTTY がサーバに確立しようとしたネットワーク接続に対してサーバがまったく応答しなかったことを意味します。通常サーバマシンがネットワークから切り離されているか、電源が切れている場合に起こります。
サーバマシンのホスト名や IP アドレスを正しく入力しているか確認します。もしそれでもだめならば、サーバの管理者に問い合わせます。
Unix も接続中にデータを送信しようとしてサーバとの接触が絶たれたときにこのエラーを出すことがあります。 (Unix がサーバから応答を受け取るのをあきらめるまでに分単位の遅れがあります。) これが起こるのは、ネットワークが切断されているときに PuTTY の端末に何か入力したときですが、PuTTY が自発的にデータを送信しようとしたときも起こります。 SSH-2 での鍵交換の再実行や (section 4.20.2 参照) keepalive (section 4.16.1) の時です。
OS が PuTTY の確立しようとしたネットワーク接続のパラメータを拒否したことを意味します。パラメータが無効なため通常は実際に接続しようとはしていません。
このエラーを引き起こすものとしてよくあるのは、無効なポート番号であるポート 0 に接続しようとしたときです。
このマニュアルや PuTTY のツールに意見がある場合は、 Feedback page を参照してください。
翻訳についてはフィードバックから送信できます。
©1997-2025 Simon Tatham ©2015-2025 SATO Kentaro
[PuTTY custom build 0.83.ranvis-doc]