Xterm スタイルのマウス通知を無効にする / Disabling xterm-style mouse reportingadjust” 要求で停止 / Chokes on PuTTY's SSH-2 “winadj” requests”KEXINIT で停止 / Chokes on PuTTY's full KEXINIT”ssh-connection” プロトコルこの章では PuTTY のすべての設定オプションについて記述します。
PuTTY はセッションを開始する前に表示されるコントロールパネルで設定を行います。セッションの途中でも、ウインドウメニューから“設定の変更 / Change Settings”を選ぶといくつかのオプションは変更できます。
セッション設定パネルにはセッションを開始するための基本的なオプションがすべて含まれています。また設定を後で使うために保存できます。
セッションパネルの一番上にある“接続先の指定 / Specify the destination you want to connect to”という囲みは PuTTY で接続をするために最低限必要な項目があります。
“接続タイプ / Connection type”で “Serial” を選んだ場合、“ホスト名 / Host Name”と “ポート / Port” は “シリアルポート / Serial line”と “スピード / Speed”に変わります。これらの詳細は section 4.31 を参照してください。
セッション設定パネルの次の部分を使うと PuTTY の好みの設定を保存しておき、次に PuTTY を起動したときに利用できます。また設定すべてとホスト名やプロトコルを含んだ保存済みセッションも作れます。保存済みセッションには PuTTY に必要なあらゆる設定が含まれています。
もしデフォルトとは別に、設定の詳細を保存したいホストがあるならば、いわゆる 保存済みセッション を作ります。
セッション中でも “設定の変更 / Change Settings”から設定を保存できます。セッションの開始以降に変更した設定とダイアログで変更した設定が保存されます。ウインドウサイズの変更やサーバが変更したウインドウタイトルなどを含みます。
新しい設定を別名で保存するには、入力ボックスに新しい名前を入力するか一覧から上書きしたいセッションを選択しておきます。 “標準の設定 / Default Settings”に保存するならば、それを保存前に選択しなくてはなりません。
保存済みセッションはそれぞれ標準の設定とは独立しています。もし好みが変わって標準の設定を変えた場合、保存済みセッションもそれぞれを別々に更新しなくてはなりません。
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions
に記憶されます。ファイルに保存したいならば、section 4.35 の方法を試してください。 ([Custom] ini ファイルを使っている場合そちらに記録します。 section 2.1.2 を参照してください。)
セッションパネルの最後が、“終了時にウィンドウを / Close window on exit 閉じる”です。セッションが終了したときに PuTTY の端末ウインドウを閉じるかどうかを指定できます。もし終了した後にテキストをコピーしたりセッションを再起動したりしたい場合は、このオプションをオフにします。
“終了時にウィンドウを閉じる / Close window on exit”の設定は 3 種類あります。 “常にする / Always”は終了時に常にウインドウを閉じます。 “しない / Never”はウインドウを閉じません (常に開いたままにしますが非アクティブです) 3 番目がデフォルトの “正常終了時のみ / Only on clean exit”です。このモードではセッションが正常終了したときはウインドウを閉じますが、ネットワーク障害やサーバからの意味不明なメッセージにより中断した場合にはウインドウを開いたままにします。
ログ設定パネルで PuTTY セッションのログファイルを保存でき、デバッグや解析、将来の参照のために役立てられます。
中心的となるオプションは PuTTY が何をログするかを指定するラジオボタンです。オプションは:
訳注: UTF-8 使用時でも ASCII で表示できる文字のみが対象です。
[Custom] ただしカスタム版の文字セット (UTF-8 (CJK) など。section 4.10.1 参照) を使用している場合、ASCII 範囲外の日本語文字などを UTF-8 エンコードして出力します。この際 U+0090 以降のすべての文字が対象となるため、Unicode の (C0/C1 以外のやや広い意味での) 制御文字は PuTTY の端末が特に別の文字に変換しない限りそのままログに出力されます。
非 SSH オプション (“印字可能な出力 / Printable output”と“全セッション出力 / All session output”) は狭い意味での PuTTY でのみ動作します。端末エミュレーションのないプログラム (Plink など) では、たとえ保存済みセッションで有効化されていても効果がありません。
この入力ボックスにログを記録したいファイルの名前を入力します。 “参照 / Browse”ボタンでファイルシステムを参照して置く場所を決めるか、どこに置くかすでに決まっているならば単にファイルパスを入力できます。
このボックスには特別な機能があります。 & の文字を使うと PuTTY は現在のセッションの詳細をファイル名として挿入します。正確には次の置換を行います:
&Y: 今日の西暦 (4 桁の数字)
&M: 今日の月 (2 桁の数字)
&D: 今日の日 (2 桁の数字)
&T: 現在の時間 (6 桁の数字で記号なしの HHMMSS)
&H: 接続先のホスト名 (またはシリアル接続ならばシリアルライン)
&P: 接続先のポート番号
(これらはすべて大文字小文字を区別しません。)
例えばログファイル名を c:\puttylogs\log-&h-&y&m&d-&t.dat とすると実際のファイル名は
log-server1.example.com-20010528-110859.dat
log-unixbox.somewhere.org-20010611-221001.dat
のようになります。
ログファイルへの記録を始めようとしたときにファイルがすでに存在した場合の挙動を設定します。既存のファイルを削除して同じ名前で作成しなおす。もしくは、既存のファイルを開いて末尾に追記する。そして (デフォルトの) 挙動を勝手に決めずにその都度確認するオプションです。
ログデータをどれくらい頻繁にディスクに書き出すかを制御します。デフォルトでは PuTTY は表示されたらすぐに書き出すのでセッション中にログファイルを見ると最新の状態になっています。そしてもしクライアントシステム (訳注: PuTTY や Windows) がクラッシュしてもデータが残っている可能性が高いです。
しかし代償としてパフォーマンスが下がります。もしログを有効にして PuTTY の動作が遅くなるならば、このオプションを無効にしてみてください。もちろんその結果としてログが常に最新の状態とは限りません (とはいえセッションが終了するなどしてログが閉じれば書き込まれます)。
訳注: アプリケーションレベルのバッファをフラッシュします (fflush)。OS などそれ以降の書き込みキャッシュをフラッシュする (fsync) わけではありません。
このオプションはログを開いたときに日付と時間のヘッダ行を含めるかを選択します。ヘッダを想定していない他のプログラムにログをリアルタイムで流す場合はヘッダを無効にするのが便利でしょう。
これらのオプションは SSH パケットデータをログしている場合のみ関係します。
以下のオプションによってパケットの特に慎重に扱うべき部分がログファイルに残されることになります。これらは情報の直接的な漏洩を防ぐためのもので、攻撃者は難読化されたログからも有用な情報 (例えばパスワードの長さ) を拾い集められます。
チェックすると復号化されたパスワードフィールド (訳注: SSH プロトコルにおけるパスワード格納部分) をパケットログから削除します。 (“keyboard-interactive”のようなチャレンジ&レスポンス認証の応答を含みます) X11 転送を行っている場合の X11 認証データは削除されません。
これは PuTTY がパスワードだと知っているデータのみ省略します。もし、例えば PuTTY のセッションの中で別のログインセッションを開始した場合、すべてのパスワードはパケットログに平文で記録されます。次のオプションがこの防御に使えるかもしれません。
このオプションはデフォルトで有効です。
チェックすると復号化した“セッションデータ”すべてを省略します。このデータとは端末セッションのデータと転送チャンネル (TCP, X11, 認証エージェント) のことです。通常、これによってログファイルの容量が大幅に減ります。
このオプションはデフォルトで有効です。
端末設定パネルから PuTTY の端末エミュレーションの挙動を変更できます。
自動折り返しモードは表示しているテキストが PuTTY のウインドウの右端に到達したときの挙動を制御します。
折り返しが有効の場合、改行のない長いテキストが右端まで来ると次の行に折り返すのでテキスト全体が見えます。オフにするとカーソルが画面右端に留まり、残りの文字はその上に重なって表示されます。
もしフルスクリーンのアプリケーションを起動していて画面が不自然にスクロールしてしまった場合、試しにオプションをオフにしてみてください。
自動折り返しモードはサーバから送られる制御シーケンスで切り替えできます。この設定オプションはデフォルトの状態を指定するので、端末をリセットしたときにその状態に戻ります (Section 3.1.3.6 参照)。しかしセッション中に“設定の変更 / Change Settings”でこのオプションを変更した場合、即座に状態が変わります。
DEC 原点モードは PuTTY がサーバから送られたカーソル位置の制御シーケンスをどのように解釈するかを制御するあまり使われないオプションです。
サーバはディスプレイのスクロールする領域を制限する制御シーケンスを送れます。例えばエディタでは、画面の上下の行を維持してからスクロールする制御シーケンスを送って残りの行だけスクロールさせます。
DEC 原点モードを有効にすると、カーソル座標をスクロール領域の上端から数えます。無効にすると、スクロール領域に関わらず画面全体の上端から数えます。
このオプションを変更する必要はないはずです。しかしもしフルスクリーンのアプリケーションがテキストを間違った位置に表示しているようならば、DEC 原点モードを有効にして改善するかどうか確認できます。
DEC 原点モードはサーバから送られる制御シーケンスで切り替えできます。この設定オプションはデフォルトの状態を指定するので、端末をリセットしたときにその状態に戻ります (Section 3.1.3.6 参照)。しかしセッション中に“設定の変更 / Change Settings”でこのオプションを変更した場合、即座に状態が変わります。
ほとんどのサーバは画面の新しい行を始めるときに CR と LF 二つの制御文字を送ります。 CR 文字は画面の左端にカーソルを戻します。 LF 文字はカーソルを一行下に動かします (結果として画面をスクロールするかもしれません)。
ある種のサーバは LF しか送らず、端末が自動的にカーソルを左に動かすよう要求します。もしそのようなサーバに出会ったら、このような階段状態の画面になるはずです:
テキストの一行目
二行目
三行目
この場合、このオプションを有効にすれば通常の表示になります。
テキストの一行目
二行目
三行目
ほとんどのサーバは画面の新しい行を始めるときに CR と LF 二つの制御文字を送ります。 CR 文字は画面の左端にカーソルを戻します。 LF 文字はカーソルを一行下に動かします (結果として画面をスクロールするかもしれません)。
ある種のサーバは CR しか送らず、結果次の行が前の行を上書きしてしまいます。このオプションは LF を補ってすべての行を表示します。
サーバが“clear screen”シーケンスを送ったときに何色で画面を巻くかは端末によって異なります。常にデフォルトの背景色でクリアする端末もあればサーバの選んだ背景色でクリアする端末もあります。
どちらの挙動を要求するアプリケーションもあるため、PuTTY はどちらにも設定できます。
このオプションを無効にすると常にデフォルトの背景色でクリアします。有効にすると現在の背景色でクリアします。
背景色での消去はサーバから送られる制御シーケンスで切り替えできます。この設定オプションはデフォルトの状態を指定するので、端末をリセットしたときにその状態に戻ります (Section 3.1.3.6 参照)。しかしセッション中に“設定の変更 / Change Settings”でこのオプションを変更した場合、即座に状態が変わります。
サーバは PuTTY に点滅するテキストを送れます。これは非常に気が散るので PuTTY では点滅テキストを完全に無効にできます。
点滅テキストを無効にした状態でサーバがテキストを点滅させようとした場合、 PuTTY はその代わりにテキストを 明るい背景色で表示します。
テキストの点滅はサーバから送られる制御シーケンスで切り替えできます。この設定オプションはデフォルトの状態を指定するので、端末をリセットしたときにその状態に戻ります (Section 3.1.3.6 参照)。しかしセッション中に“設定の変更 / Change Settings”でこのオプションを変更した場合、即座に状態が変わります。
このオプションはサーバが ^E 問合せ文字を送ってきたときに PuTTY が何を返すかを制御します。通常は単に“PuTTY”という文字列を送ります。
もし間違ってバイナリファイルの内容を端末で表示してしまった場合、^E の文字がいくつも入っているためにコマンドラインが“PuTTYPuTTYPuTTY...” とまるで応答文字列をキーボードで何度も打ったようになってしまうかもしれません。応答文字列を空にするとこの問題は起きませんが、別の問題が起きるかもしれません。
この PuTTY の機能はサーバが端末の種類を判別するために用いるものではありません。その機能は接続パネルの“端末タイプを表す文字列 / Terminal-type string” です。詳細は section 4.17.3 を参照してください。
^C の記法で応答文字列に制御文字を含められます。 (^ という文字自体は ^~ で表します。)
ローカルエコーを無効にすると PuTTY のウインドウに入力した文字を PuTTY がエコー(表示)しません。単にサーバに送られます。 (サーバがエコーバックするかもしれません。これは PuTTY のコントロールパネルから制御できません。)
ある種のセッションはローカルエコーが必要で、あるものは不要です。デフォルトでは PuTTY は現在のセッションでローカルエコーするべきかどうか推測します。もし間違った推測を行っていたならば、このオプションを使って推測したモードを上書きし、強制的にオン・オフできます。
通常 PuTTY のウインドウに入力した文字は入力の瞬間、即座にサーバに送信されます。
ローカルライン編集を有効にすると、この挙動が変わります。 PuTTY は改行が入力されるまで行の編集をローカルで行い、それからサーバに送信します。入力を間違えても Enter を押すまではバックスペースキーで訂正でき、サーバが入力ミスした文字を受け取ることはありません。
文字を見ずに一行を編集するのは難しいので、ローカルライン編集は大抵ローカルエコー (Section 4.3.8) と一緒に使います。 Raw モードでは理想的なオプションです。 MUD やトーカーでも。 (いくつかの高度な MUD はたまにパスワード入力を受け付けるためにローカルエコーを無効にしてローカルライン編集を有効にします。)
ある種のセッションはローカルライン編集が必要ですが、多くは不要です。デフォルトモードでは PuTTY は現在のセッションでローカルライン編集が適切かどうか推測します。もし間違った推測を行っていたならば、このオプションを使って推測したモードを上書きし、強制的にオン・オフできます。
VT100 互換端末の多くはリモートサーバからの印刷に対応しています (“パススルー印刷”と呼ばれることがあります)。 PuTTY もこの機能に対応していますが、デフォルトで無効になっています。
遠隔操作の印刷を有効にするにはプリンタを“ANSI printer output の送信先プリンタ / Printer to send ANSI printer output to”から選択します。ドロップダウンリストでインストール済みのプリンタドライバから選択できます。もしくはドライバをインストールしていなくてもネットワークプリンタのネットワーク名 (例えば \\printserver\printer1) を入力できます。
リモートサーバがデータを印刷しようとすると、PuTTY はそのデータをプリンターにそのまま送信します。その際、変換も整形も何もしません。どんなプリンタに繋がっているのかリモートサーバに知らせるのはあなたの役目です。
PuTTY はプリンタにそのままデータを送るので紙の向きや品質、トレイの選択といったオプションは設定できません。 PC のプリンタドライバが行うこれらの設定は PuTTY が迂回してしまいます。それらが必要ならばリモートサーバで行わなくてはなりません。
遠隔印刷を無効に戻すには、“なし (印刷不可) / None (printing disabled)”を一覧から選びます。これがデフォルトの状態です。
キーボード設定パネルは PuTTY のキーボードの挙動を制御します。設定の多くの正しい状態は PuTTY の接続するサーバによります。 Unix サーバでは termcap か terminfo エントリに依存して、おそらく接続パネルの“端末タイプを表す文字列 / Terminal-type string”の設定で制御されます (詳細は section 4.17.3 参照)。もしこれらの設定の効果がなさそうならば、question A.7.13 が役立つかもしれません。
ある端末はバックスペースキーでサーバに Control-H (ASCII コード 8) を送ります。ある端末では ASCII コード 127 (通常 Control-? と呼びます) なので、Control-H と区別できます。このオプションでバックスペースキーを押したときに PuTTY がどちらを送信するか選択できます。
SSH で接続する場合、PuTTY はこのオプションの値をサーバに通知します (Section 4.26.2 参照)。そのためどちらを選んでも通常はバックスペースキーが動作します。同様に、Unix システムに接続しているならば、stty コマンドで設定できるのでやはり PuTTY の設定をする必要はありません。その他のシステムでは、サーバの設定が固定されているので PuTTY 側を変更しなくてはならないかもしれません。
もし選べるならば、PuTTY は Control-? を送信するようにしてサーバをそれに合わせることを薦めます。なぜなら emacs のようなアプリケーションで Control-H で help を表示できるからです。
(Shift-バックスペースを入力すると PuTTY はデフォルトとして設定されていない方のコードを送信します。)
Unix の端末エミュレータ rxvt は Home と End キーで送信する文字シーケンスが他と違っています。
xterm などの端末は home キーで ESC [1~ を送信し、End キーで ESC [4~ を送信します。 rxvt は Home キーで ESC [H 、End キー で ESC [Ow です。
もしアプリケーションで Home と End キーが動作しないならば、このオプションを切り替えてみてください。
このオプションはファンクションキー (F1 から F12) とキーパッドの上段に影響します。
ESC [n~ ではファンクションキーは ESC [11~, ESC [12~ のようなシーケンスを生成します。 Digital の端末の挙動と同じです。
ESC [[A から ESC [[E を生成します。これは Linux virtual console をまねています。
ESC OP から ESC OS を生成します。これは Digital の端末のキーパッド上段と同じです。
ESC OP から ESC OS を生成します。
ESC OP から ESC O[ を生成します。
ESC [M から ESC [X を生成します。 Shift キーを押しながらだと、 ESC [Y から ESC [j になります。 Control キーだと ESC [k から ESC [v で、 Shift と Control だと ESC [w から ESC [{ を生成します。
ESC OP が ESC [1;ビットフラグP のようになります。 F5 とそれ以降については、ESC[番号~ が ESC[番号;ビットフラグ~ となります。
もしこれらが何を意味するのか知らない場合、変更する必要はないはずです。
このオプションは矢印キーを修飾キー (Shift、Ctrl、Alt) と共に押した場合に影響します。
ESC [A や ESC [B と、Digital の端末が“アプリケーションカーソルキー”モードで生成するシーケンスである ESC O A などを切り替えます。 Shift キーと Alt キーの状態は影響しません。
もしこれらが何を意味するのか知らない場合、変更する必要はないはずです。
アプリケーションカーソルキーモードによってサーバはアローキーで送信される制御シーケンスを変更します。通常モードではアローキーは ESC [A から ESC [D を送りますが、アプリケーションモードでは ESC OA から ESC OD を送ります。
アプリケーションカーソルキーモードはサーバのアプリケーションによって切り替えられます。 PuTTY では初期状態を設定できます。
“高度な設定 / Features”パネルでアプリケーションカーソルキーモードを完全に無効にできます。 Section 4.6.1 を参照してください。
アプリケーションキーパッドモード はサーバがキーパッド (テンキー類) の挙動を変更する手段です。
通常モードでは、キーパッドは Windows と同じように動作します。 Num Lock がオンだと、キーで数字を入力でき、オフだと矢印キーや Home, End 等という具合です。
アプリケーションモードではキーバッドの Num Lock を含むすべてのキーは特別な制御シーケンスを送信します。 Num Lock は Num Lock として動作せず、他のファンクションキーになります。
Windows のバージョンによってはアプリケーションモードで Num Lock がファンクションキーとして動作していても Num Lock を押すたびに LED ライトが点滅するかもしれません。これは仕方のないことです。
アプリケーションキーパッドモードはサーバ側のアプリケーションによってオンオフできます。 PuTTY では初期状態を設定できます。
“高度な設定 / Features”パネルでアプリケーションキーパッドモードを完全に無効にできます。 Section 4.6.1 を参照してください。
PuTTY には NetHack で遊ぶための特別なモードがあります。 “テンキーの初期状態 / Initial state of numeric keypad”から“NetHack” を選ぶと有効化できます。
このモードでは、テンキーの 1-9 が NetHack の移動コマンド (hjklyubn) になります。 5 キーが . コマンド (何もしない / 休憩) です。
さらに、Shift や Ctrl を組み合わせできます (例えば、テンキーの 7 が“y”なので Shift-7 は“Y”で Ctrl-7 は Ctrl-Y)。これらのコマンドは NetHack では何か起こるまで同じ方向に動き続けることを意味します。
どういうわけかこの機能は Num Lock がオンでないと動作しません。なぜかは分かりません。
DEC 端末には Compose キーがあり、アクセント付き文字を入力する覚えやすい手段となっています。 Compose を押して 2 文字入力すると、その文字が“合体して”アクセント付きの文字になります。文字は覚えやすいように決められており、例えば“e”と“`”を合体すると“è”になります。
もしキーボードに Windows アプリケーションキーがあるなら、PuTTY ではそれが Compose キーとして動作します。もしくは “AltGr を Compose キーとして使う / AltGr acts as Compose key”を有効にすると、AltGr キーが Compose キーになります。
古いキーボードには AltGr キーがないものがあり、ある種の文字を入力しにくい場合があります。 PuTTY では Ctrl-左Alt を AltGr として使うように設定できます。
デフォルトではチェックボックスがチェックされているので Ctrl-左Alt は AltGr とは違う働きをします。通常 PuTTY では 左Alt キーはエスケープ文字 (Control-[) を他に押したキーの先頭に足して送ります。例えば Alt-A は escape と a です。 Alt-Ctrl-A であれば escape と Control-A です。
チェックを外すと、Ctrl-Alt は AltGr になるのでキーボードレイアウトに定義されていればそれらのシンボルを入力できます。
(ただし Ctrl-Alt は “AltGr を Compose キーとして使う / AltGr acts as Compose key” の設定に関わらず Compose キーとしては働きません。詳しくは section 4.4.8 参照。)
[Custom] 有効にすると 右Alt キーを 左Alt キーと同じように端末の処理に使用します。
[Custom] 有効にすると Alt キーを押しながらのキー入力時にエスケープ文字を接頭する代わりにメタビット (0x80) を付けて送ります。例えば Alt-A は 0xE1 になります。主に Nethack で使用します。
入力が ASCII 外の文字の場合、エスケープが付きます。この機能に関する諸問題は PuTTY wish meta-bit が参考になります。
ベルパネルはサーバが PuTTY を通して警告音を鳴らす端末ベル機能を制御します。
デフォルトの設定ではサーバが ASCII コード 7 (Control-G) を送信したとき、PuTTY は Windows のデフォルト警告音を鳴らします。それが望ましいとは限らないのでベルパネルで別の挙動に変更できます。
このコントロールから端末ベルの際に行う処理を様々な中から選択できます:
この機能はベルが鳴ったときにウインドウに入力フォーカスがないときに PuTTY のウインドウをどうするかを制御できます。
デフォルト状態 (“無効 / Disabled”) は特に何もしません。
“安定的 / Steady”を選んだ場合、ベルの際にウインドウにフォーカスがないとウインドウのタスクバー上のエントリとタイトルバーの色が変わって PuTTY セッションに注目するように主張します。変わった色はウインドウを選ぶまで戻らないので、PuTTY のウインドウをいくつも最小化しておいてキーボードの前から離れていても、重要な警告音を見逃す心配がありません。
“点滅 / Flashing”はより目を引きます。タスクバーのエントリはウインドウを選択するまで点滅し続けます。
端末セッションでよくあるユーザエラーは Unix コマンドの cat (またはその類) をうっかり間違って実行ファイル、画像や ZIP ファイルなど不適切な種類のファイルに実行してしまうことです。それによって端末にテキスト以外の文字が大量に送られてしまい、その中には大抵たくさんのベル文字が含まれています。結果端末の警告音が 10 分もの間鳴り止まず、同じオフィスの皆がうんざりします。
そうならないように、もしくは別の原因による過剰な警告音を防ぐために PuTTY には過剰なベルを管理する機能があります。デフォルトでは 2 秒間に 5 回以上のベル文字を受け取ると防御機能が起動します。一旦起動すると、それ以降のベルには何もしなくなります。そのためバイナリファイルの残りは無音で画面に表示されます。ベルが送信されないまま 5 秒間経つと機能がオフになり、ベルが鳴るようになります。
この機能を無効にしたい場合は、“ベルが使われすぎたとき一時的に無効にする / Bell is temporarily disabled when over-used”を外します。
もしこの機能を使いたいけれども設定が合わないならば、詳細を変更できます。過剰と判断するベルの数, 判断する期間, 機能をオフにするのに必要な無音時間が変更できます。
過剰なベルモードは端末でキーを押すと常に無効化されます。つまり予期しない大量のデータに対応できますが、通常のキーボード入力で起きるベル (例えばファイル名補完) は邪魔しません。
PuTTY の端末エミュレーションは非常に高機能でリモートサーバの制御下で様々なことができます。いくつかの機能はサーバソフトウェアのバグや変わった設定によって問題を起こすことがあります。
PuTTY の高度な端末機能が問題を起こした場合、一部は高度な設定パネルで無効にできます。
アプリケーションキーパッドモード (Section 4.4.6 参照) とアプリケーションカーソルキーモード (Section 4.4.5 参照) はキーパッドとカーソルキーの挙動を変更します。いくつかのアプリケーションはこれらの機能を有効にしますが、修飾キーを適切に処理しません。そこでサーバ側がモードを有効にできないよう無効状態に固定できます。
Xterm スタイルのマウス通知を無効にする / Disabling xterm-style mouse reporting
PuTTY ではサーバが コントロールコードを送りマウス操作を捕捉してコピー&ペースト以外の目的に使えます。この機能を使うアプリケーションはテキストモードのウェブブラウザ links や Usenet ニュースリーダの trn version 4、ファイルマネージャの mc (Midnight Commander) などがあります。
もしこの機能が迷惑ならば、“Xterm スタイルのマウス通知を無効にする / Disable xterm-style mouse reporting”で無効にできます。これがチェックされた状態ではマウスは常に通常のコピー&ペーストに使えます。
ちなみにアプリケーションにマウスを奪われていても、選択するときに Shift キーを押していればコピー&ペーストできます (設定で変更できます。Section 4.11.2 を参照してください)。
PuTTY にはサーバからの命令によって端末の大きさと位置と変更する機能があります。これが予期せず起こる場合や迷惑な場合は命令に反応しないように設定できます。
PuTTY を含む多くの端末は“別の画面 / alternate screen”に対応しています。別端末の画面は通常の端末と同じ大きさですが独立しています。テキストエディタなど一般的なスクリーンベースのプログラムは起動時に端末を別画面に切り替えます。そして終了時に主画面に戻すので、表示内容がエディタ起動前の状態に戻ります。
もし今までと同じ画面でエディタを実行したいならば、この機能を完全に無効にできます。
PuTTY にはサーバからの命令によって端末のタイトルを変更する機能があります。これが予期せず起こる場合や迷惑な場合は命令に反応しないように設定できます。
PuTTY は ローカルウインドウのタイトルをアプリケーションが調べる xterm の機能に対応できます。この機能はデフォルトで無効になっていますが、必要ならば有効化できます。
ただしこの機能は潜在的にセキュリティの危険となります。もし悪意のあるアプリケーションが端末にデータを送れる場合 (たとえばサーバ上の誰か他人のファイルを単に cat しただけでも) ウインドウタイトルが変更される可能性があります。そしてこの機能を使うと新しいウインドウタイトルをサーバにキー入力として返答します。これで攻撃者は偽のキー入力を行えるため、あなたが実行するつもりのないことをサーバ側のアプリケーションに指示できます。そのためこの機能はデフォルトで無効になっていますし、本当に何なのか理解していない限り“タイトル / Window title”の設定は薦めません。
設定は 3 つのオプションがあります:
PuTTY はサーバからの命令で端末のスクロールバックバッファをクリアできます。もし予期せずにこれが起こる場合やそれが不便ならば、PuTTY がこの命令に反応しないように設定できます。
通常 PuTTY が 文字 127 (^? / DEL) をサーバから受け取ると、“破壊的なバックスペース”としてカーソルを一文字左に動かし、下の文字を消します。これはある種のアプリケーションでは明らかな問題を起こすため、このオプションでは代わりの挙動を指定できます。
設定は 3 つのオプションがあります:
PuTTY にはサーバからの命令によって文字セット設定を変更する機能があります。いくつかのプログラムはこの命令を思いがけない時に、または迷惑な形で送ります。特に BitchX (IRC クライアント) はユーザの意図と違った文字セットに設定しなおす癖があります。
特に BitchX を使っていて アクセント付きの文字が意図したとおりに出ない場合はこの設定を使います。
PuTTY はアラビア文字の変形に対応しています。つまりサーバがアラビア文字を Unicode の基本字母で送ってきたら、それを正しい表示形に変換して表示します。
もしこの変換を予期していないフルスクリーンソフトウェアを使っているなら (特にアラビア語話者ではなくアラビア語非対応のアプリケーションで予期せずにアラビア文字のファイルを扱う場合は) 画面が崩れるかもしれません。この設定をチェックすると文字の変形を無効にして送られてきた文字を PuTTY でそのまま表示できます。
双方向テキストの表示も無効にする必要があるかもしれません。 section 4.6.11 を参照してください。
PuTTY は双方向テキストの表示に対応しています。つまり右から左に書く言語 (例えばアラビア語やヘブライ語) のテキストをサーバが送ってきた場合、正しく画面に表示できるように反対にします。もしこの変換を予期していないフルスクリーンソフトウェアを使っているなら (特にアラビア語話者ではなくアラビア語非対応のアプリケーションで予期せずにアラビア文字のファイルを扱う場合は) 画面が崩れるかもしれません。この設定をチェックすると双方向テキストの表示を無効にして送られてきた文字を常に左から右に表示します。
アラビア文字の変形も無効にする必要があるかもしれません。 section 4.6.10を参照してください。
デフォルトではテキストを端末ウインドウに張り付けると、サーバに端末への入力として、丁度キーボードで入力したように送信されます (ただし文字は一括で送られるため、あなたが実際にタイプするよりも格段に速くなります)。
しかし、端末のアプリケーションは端末に“ブラケット貼り付けモード”を有効にするように要求し、この処理を変更できます。このモードでは、張り付けたデータは入力ストリーム中で前後を特別な制御シーケンスでマークされます。
この情報を使って、端末アプリケーションは張り付けたデータをキーボード入力とは異なる扱いで処理できます。例えば、端末ベースのテキストエディタにおいて通常は特別なエディタの機能が働く特殊な文字もそのまま文字通りの入力データとして扱えます。シェルでは入力を安全性の低いものとして扱え、他のアプリケーションが悪意のあるシェルコマンドを混入している場合に備えられます: モダンなバージョンの bash はコマンドラインに張り付けたデータを反転表示しあなたが確認してエンターを押すまではたとえデータに改行文字が含まれていても実行しません。
ごく稀に、ブラケット貼り付けモードが解決する問題よりも大きな問題を引き起こす可能性があります。そのためこのチェックボックスをオフにして機能を無効にできます。そうすると PuTTY はサーバ側のブラケット貼り付けモード要求に関わらず、常に張り付けたデータをキーボードで入力したように送信します。
ウインドウ設定パネルから PuTTY のウインドウに関する事柄を制御できます。
“桁 / Columns” と “行 / Rows” ボックスで PuTTY のウインドウを決められたサイズに変更できます。もちろんセッション中にもウインドウをドラッグしてサイズ変更できます。
このオプションで PuTTY のウインドウをサイズ変更したときの挙動を制御できます。
オプションは 4 つあります:
このオプションでテキストが画面から流れたときに PuTTY がテキストをどう保持するかを制御します (Section 3.1.2 参照)。
“スクロールバックの行数 / Lines of scrollback”で PuTTY が保持する行数を設定します。 “スクロールバーを表示する / Display scrollbar”オプションでスクロールバーを隠せます (その状態でも section 3.1.2 にあるとおりキーボードでスクロールバックできます)。通常時とフルスクリーンモードの状態を別々に設定できます。
スクロールバックを見ているときにサーバが PuTTY にテキストを送ってきた場合、現在の端末の内容に戻ります。この挙動は“何か表示されるときスクロールバックをリセットする / Reset scrollback on display activity”で無効にできます。キーを押したときにの挙動は“キーが押されたときスクロールバックをリセットする / Reset scrollback on keypress”で無効にできます。
このオプションを有効にするとサーバ側のアプリケーションが画面をクリアしたときに端末画面の内容がスクロールバックに入ります。そのため画面に何が表示されていたかの記録がスクロールバックによりよく残ります。
アプリケーションが別端末画面に切り替えた場合は、アプリケーションが元に戻すまで (詳しくは section 4.6.4 参照)、スクロールバックには主画面の内容を表示します。
このオプションはデフォルトで有効です。
外観設定パネルでPuTTY のウインドウの見た目を制御できます。
The “カーソルの外観 / Cursor appearance”オプションでカーソルをブロック, 下線, 縦線から選べます。ブロックカーソルはウインドウがフォーカスされていないときに枠のみになり、下線や縦線では破線になります。
“カーソルの点滅 / Cursor blinks”オプションでカーソルの点滅をオンオフできます。このオプションはどの外観でも動作します。
このオプションでどのフォントをどのサイズでテキストを PuTTY の端末ウインドウに使うかを選べます。
デフォルトではシステムにインストールしてある固定幅フォントから選べます。 VT100 スタイルの端末は固定幅フォントを要求するためです。プロポーショナルフォントも選べますが、文字が固定幅に収められるため、フォントによっては見た目があまりよくないかもしれません。
[Custom] 文字幅が合わない場合、文字間を調整する代わりに拡大縮小します。
このオプションを有効にすると、PuTTY ウインドウにフォーカスした状態でキーを押したときにマウスポインタが見えなくなります。そのためセッションの作業中にテキストの邪魔にならなくなります。マウスを動かすとすぐにポインタが現れます。
このオプションはデフォルトで無効なので、常にマウスポインタが見える状態になります。
PuTTY はウインドウ枠の見た目をある程度変更できます。
“落ち込んだ縁の枠 / Sunken-edge border”をチェックするとウインドウ枠が DOS マシンのようになります。説明するのは難しいので気に入るか試してみてください。
訳注: Windows の機能のため OS のバージョンによって異なります。現在の Windows では基本的に枠が厚めになるだけです。
“ウィンドウの縁とテキストとのすき間 / Gap between text and window edge”でテキストとウインドウ枠との間の空白も調整できます。デフォルトでは 1 ピクセルになっていますが 0 にしたり、より大きくしたりできます。
動作設定パネルは PuTTY ウインドウの振る舞いを制御します。
“ウインドウタイトル / Window title”ボックスで PuTTY ウインドウのタイトルを変更できます。デフォルトではホスト名に続いて“PuTTY”、例えば server1.example.com - PuTTY となります。違うウインドウタイトルがよいならば、ここで設定します。
PuTTY はセッション中にサーバから xterm 制御シーケンスが送信されるとタイトルを変更します (この機能が有効の場合。section 4.6.5 参照)。そのためここで設定したタイトルはただの初期値です。
ウインドウのタイトルだけでなく、xterm シーケンスには ウインドウのアイコンのタイトルを変更するものがあります。これはウインドウシステムで「ウインドウを閉じるとアイコンに戻る」場合に意味があります。 Windows 3.1 やほとんどの X Window システムが当てはまりますが、Windows 95 などには当てはまりません。
デフォルトでは PuTTY はウインドウタイトルは使いますがアイコンタイトルは無視します。もしどちらも確認したいならば、“ウィンドウとアイコンのタイトルを区別する / Separate window and icon titles”をチェックします。これをチェックすると PuTTY のウインドウを最小化したときに PuTTY のウインドウタイトルとタスクバーのキャプションがサーバの指定したアイコンタイトルに変わります。ウインドウを元に戻すとサーバの指定したウインドウタイトルに戻ります。 (サーバがタイトルを指定していなければ何も起きません。)
PuTTY ウインドウの閉じるボタンをセッション中に押すと、PuTTY は本当に閉じるのかを確認する警告ウインドウを表示します。セッションが終了したウインドウは常に警告なしで閉じます。
もしウインドウをすばやく閉じたいならば“ウィンドウを閉じる前に警告する / Warn before closing window”オプションを無効にします。
デフォルトでは Alt-F4 でウインドウを閉じます (もしくは警告が表示されます。Section 4.9.2 参照)。 “Alt-F4 でウィンドウを閉じる / Window closes on ALT-F4”オプションを無効にすると、Alt-F4 は単にキーシーケンスをサーバに送信します。
このオプションが有効だと、Alt-Space で PuTTY ウインドウのメニューを表示します。これは左上隅をクリックするのと同じです。無効にすると、Alt-Space は単に Esc Space をサーバに送信します。
アクセシビリティプログラムの一部は PuTTY のウインドウを制御するためにこのオプションを有効にする必要があるかもしれません。例えば ドラゴンスピーチ / Dragon NaturallySpeaking はシステムメニューを開く, ウインドウを閉じる, 最小化, 最大化, 元に戻すのにこのオプションが必要です。
このオプションを有効にすると Alt を押して離したときに PuTTY ウインドウのメニューが表示されます。これは左上隅をクリックするのと同じです。無効にすると、Alt のタイプでは何も起きません。
このオプションを有効にすると PuTTY のウインドウを常に他のウインドウより手前に表示します。
このオプションを有効にすると PuTTY のウインドウで Alt-Enter を押したときにフルスクリーンになります。もう一度 Alt-Enter を押すとウインドウは元の大きさに戻ります。
Alt-Enter キーを無効に設定していても、フルスクリーン機能はシステムメニューから使用できます。 section 3.1.3.7 を参照してください。
[Custom] このオプションを有効にすると PuTTY のウインドウで Ctrl-Tab を押したときに別の PuTTY ウインドウを前面に表示します。 Shift キーを押していると逆順に辿ります。この設定を有効にしているウインドウ間のみで切り替わります。
[Custom] このオプションを有効にすると Ctrl-Tab でウインドウを切り替えたときに最小化されているウインドウを飛ばします。この設定を無効にした場合、最小化されたウインドウに切り替わる際はウインドウが元に戻ります。この設定はすでに起動中の PuTTY には影響を与えません。 Ctrl-Tab でウインドウを切り替えるには Section 4.9.8 を参照してください。
変換設定パネルでサーバと PuTTY の間の文字セット (文字コード) 変換を制御します。
対話型セッションの間、PuTTY は 8 ビットストリームをサーバから受け取ります。それを画面に表示するためには、どんな文字セットを使って解釈するべきか知る必要があります。同様に、PuTTY はキー入力をサーバの期待するエンコーディングに変換する必要があります。残念ながら、PuTTY とサーバがこの情報をやり取りする十分な仕組みはないため、通常手動で設定する必要があります。
訳注: 文字コードに関するドキュメントは英語版と大幅に異なります。
“リモートの文字セット / Remote character set”で多くのエンコーディングから一つを選べます。
デフォルトでは PuTTY は Unicode の UTF-8 エンコーディングを選びます。これはほとんどの文字を表現できます。サーバからのデータは UTF-8 として解釈し、キー入力は UTF-8 でエンコードします。これがほとんどの Linux ディストリビューションのデフォルト設定です。しかし、もしあなたのサーバと違うならば、別の文字セットを選択できます。
[Custom] 日本語化ファイルを使用した場合、UTF-8 (CJK) がデフォルトとなります (Section 2.1.1 参照)。
文字セットをいくつか紹介すると:
Unix など POSIX 準拠の OS においては LANG, LC_MESSAGES, LC_ALL のような環境変数で対応するサーバ側プログラムの利用する文字コードやメッセージの言語など (locale) が変わります。日本語の値としては locale -a | grep ^ja で利用可能な文字コードを含む locale を確認できます。
一覧にない数字のコードページ (コードページ 866 など) は名前を入力すると使えます (例えば CP866) 。 Windows が対応している場合は、PuTTY は指定されたコードページを使います。
固定幅の日本語フォントでは漢字や仮名は全角文字として横方向にラテン文字の二倍の幅を取りますが、全角として表示される文字の中には Unicode で文字の幅が定められていない (ambiguous = 曖昧な、として定義されている) ものがあります。歴史的に JIS の文字セットに全角文字としてギリシャ文字やキリル文字、★や“”などの記号類が (符号化したデータ量から) 全角文字として存在していた一方で、非 CJK 言語圏では全半角の概念がなく (データ量も 1 バイト)、固定幅のフォントではそれらをラテン文字など他の文字と同じ幅で問題なく表示できたことによります。 PuTTY はこれらの曖昧な幅の文字を半角として表示しますが、固定幅の日本語のフォントを使うと結果的に水平方向が 50% 縮小されデザインに違和感を感じたり、表示が崩れる場合があります。その際はこのオプションを有効にすると、それらの文字が半角文字 2 文字分の全角幅で表示されるようになります。
ただしサーバ側アプリケーションも設定を一致させる必要があります。設定がサーバ側と一致しないと、CUI 画面が崩れるまたはカーソル位置がずれるといった副作用が出ます。非 RTL 圏での bidi のように非 CJK 圏での ambi-width は関心が薄く、国際化されていないプログラムは対応していないかもしれません。
例えば vim の場合は set ambiwidth=double とすると全角幅になります。
曖昧な文字幅は半角で統一してしまい、端末のロケール (locale) も非 CJK 言語にするのが欧米の CUI アプリケーションを使う上で一番トラブルが少ないかもしれません。
このオプションは UTF-8 モードでのみ効果があります (Section 4.10.1 参照)。
[Custom] UTF-8 (CJK) を選択した場合はこのオプションの設定に関係なく常に全角幅になります。
この機能は US/UK レイアウトキーボードとキリル文字レイアウトキーボードの切り替えを Caps Lock キーで行います。例えば同じドキュメントでロシア語と英語を交互に入力したいときに使います。
今のところこの機能は US/UK キーボードレイアウトでしか動かないかもしれません。
文字コード 5c は ASCII においてバックスラッシュであり、また Unicode においても U+005C は同じ見た目のリバースソリダス (reverse solidus) と定義されていますが、歴史的に日本語の文字コードなど ISO 646 を元にした文字コードでは、5c は国やアプリケーションが自由に文字を決められるコードであり、円記号など別の文字に割り当てられていました。
現在でも Windows においては後方互換性からか、日本語フォントによっては Unicode の U+005C \ が円記号で表示されて Unicode における円記号 U+00A5 ¥ と同じに見える場合があります。 (全角の円記号は U+FFE5 ￥ というさらに別のコードです。)
このオプションを解除したデフォルトの状態では、5c を ASCII や Unicode 本来のバックスラッシュで表示します。 (この場合フォントの言語設定が日本語の時に、5c を含む表示で描画速度が低下する場合があります。)
[Custom] 有効にすると OS のデフォルトの挙動と同じになるため、フォントによっては 5c が円記号など別の文字で表示されるかもしれません。 5c を円記号として使っているデータを、そのようなフォントを使い文字化けさせずに表示したい場合や、フォントの文字コード 5c の字形が既にバックスラッシュで追加の処理が必要ない場合に有効にします。この設定による変化は見た目に限ったものであり PuTTY の扱う文字コードは 5c のまま変化しません。
VT100 シリーズの端末はサーバからの制御シーケンスで単純な線や四角形を描画する文字セットに一時的に切り替えられます。しかし PuTTY がそれに対して正しい文字を探す方法はいくつもあり、どれが正しいかはフォント次第です。通常、フォントの対応する正しいオプションを見つけるまでいくつか試してみる必要があります。
+, -, | を使って線を描画します。他のオプションが機能しない場合はこのオプションを使います。
デフォルトでは、PuTTY の画面に表示された VT100 罫線描画文字は画面上の形式でコピーされます。 Unicode の描画コードポイントか、“粗末な / poor man's”描画文字である +, -, |です。 “罫線描画文字を lqqqk としてコピーアンドペーストする / Copy and paste VT100 line drawing chars as lqqqk”はこの機能を無効化して罫線描画文字をその描画に使う ASCII 文字としてコピーします。これは普通 q と x そして角に jklmntuvw が散らばる形になります。同じ枠のレイアウトを他のプログラムで再現したいときに便利かもしれません。
このオプションは VT100 の仕組みで受信した描画文字に対してのみ効果があります。 Unicode コードポイントで受信したものは常に Unicode でコピーします。
PuTTY がサーバからのデータを UTF-8 エンコードで扱うように設定されている場合、デフォルトでは古い VT100 系仕様の制御シーケンスを無効化するため、小文字を一時的に罫線描画として扱うことはなくなります。
というのも UTF-8 モードではこれらの制御シーケンスは必要ないからです。なぜなら制御シーケンスでアクセスできる罫線描画文字はすべて Unicode 文字ですでに利用可能です。そのためアプリケーションは表示のために端末を特別な状態に切り替える必要がありません。
また、無効化によって端末が予期せずにその状態に切り替わる危険も除去できます: もし制御できていないバイナリデータを UTF-8 でない端末に書き出すと、次のシェルプロンプトが罫線描画文字の羅列で出ることは驚くほどよくある事で、そうするとあなたはそのモードを抜け出す方法を思い出すか、調べないとなりません。そのためデフォルトでは UTF-8 モードではそんな混乱の元に、偶然でも意図的でも、立ち入るモードは持っていません。
しかし、すべてのアプリケーションがそう考えるわけではありません。 UTF-8 端末のユーザは依然として時折昔ながらの方法で罫線描画を行おうとするソフトウェアを実行する必要が出るかもしれません。そのため設定オプション“UTF-8 モードでも VT100 罫線描画を有効にする / Enable VT100 line drawing even in UTF-8 mode”によって、PuTTY が VT100 形式の制御シーケンスを処理して ASCII 小文字の意味を変え、そして UTF-8 も処理する、ハイブリッドモードに変更します。
選択パネルで PuTTY ウインドウでのコピー&ペーストの動作を制御できます。
PuTTY のコピー&ペーストの仕組みはデフォルトで Unix の xterm アプリケーションに倣っています。 X Windows システムでは 3 ボタンマウスを使い、左ボタンで文字を選択し、右ボタンで選択範囲を拡張し、中ボタンで貼り付けます。
Windows では 2 ボタンマウスをよく使います。そのため Windows の PuTTY では設定可能です。 PuTTY のデフォルト (“折衷 / Compromise”) では右ボタンが貼り付けで、中ボタンが (あれば) 選択範囲の拡張になります。
もし3 ボタンマウスを使っていて xterm の方式に慣れているならば、“マウスボタンのアクション / Action of mouse buttons”から選択できます。
そして“Windows”オプションを選ぶと、中ボタンで拡張, 右ボタンでコンテキストメニュー (中に “貼り付け / Paste” があります) です。コンテキストメニューは Ctrl を押して右クリックするとこのオプションの設定に関わらず表示できます。)
(PuTTY を Unix で実行した場合、X Window システムの方式に従います。)
訳注: Ctrl-V はサーバに送信されますが Shift-Ins は貼り付けとして動作します。
サーバからある制御シーケンスを受信すると、PuTTY はマウス操作をコピー&ペーストではなくサーバが自分で処理するようにします。この機能を使うアプリケーションにはテキストモードのウェブブラウザの links、Usenet ニュースリーダーの trn バージョン 4、ファイルマネージャの mc (Midnight Commander) などがあります。
これらのアプリケーションを動かすと、マウスボタンを押してもコピー&ペーストできません。コピー&ペーストする必要があるならば、Shift キーを押しながらマウスボタンを押します。
しかし、理論上はアプリケーションが Shift+マウスクリックを検出することもできます。そのようなアプリケーションが実際にあるか分かりませんが、もし誰かが作っていた場合、“Shift でアプリケーションのマウス使用を無効にする / Shift overrides application's use of mouse”をオフにすると Shift+クリックもサーバに送信できます (そしてマウスによるコピー&ペーストはできなくなります)。
もしアプリケーションがマウスを制御するのを阻止したい場合は、高度な設定 / Features パネルで制御できます。 section 4.6.2 を参照してください。
section 3.1.1 にある通り、PuTTY にはコピーするテキストの選択方法に 2 つのモードがあります。デフォルトモード (“通常 / Normal”) では、点 A から B へのドラッグで A の行末までと間の行と 行頭から B までを選択しコピーします。もう一つのモード (“長方形ブロック / Rectangular block”) では、2 点間の長方形内のテキストをコピーします。
通常、矩形選択する場合は Alt キーを押してからドラッグする必要があります。 “デフォルトの選択モード / Default selection mode”で矩形選択をデフォルトにできます。そうすると Alt を押したときが通常モードになります。
PuTTY の様々なコピーと貼り付け操作によって、どのクリップボードが読み書きされるかを設定できます。
Windows などほとんどのプラットフォームはシステムが持つクリップボードは一つだけです。これらのプラットフォームでは PuTTY はそのウインドウで最後に選択したテキストを保持する第二のクリップボードを提供できます。これはシステムのクリップボードと関連はありません。この機能はデフォルトでは無効になっています。
X Window システム (ほとんどの Unix GUI の元となっています) では、複数のクリップボード (または“選択範囲”) があります。そして多くのアプリケーションで様々な UI によって複数のクリップボードに対応しています。 PuTTY が Unix 上で動作している場合、それに関連してより多くの設定が可能になります。
選択範囲として最も一般的に使われる二つは、“PRIMARY” と “CLIPBOARD” です。両方に対応したアプリケーションの場合、通常の動作として PRIMARY はマウスの操作に使われ (テキスト選択で自動的に PRIMARY にコピーされ、中ボタンで PRIMARY から貼り付け)、CLIPBOARD はメニュー項目にあるコピーと貼り付け や Ctrl-C、Ctrl-V キーで使用します。
“選択テキストを自動的に OS クリップボードにコピー / Auto-copy selected text to system clipboard”チェックボックスは、PuTTY の端末ウインドウのテキストを選択したときに、追加の操作なしで自動的にシステムクリップボードにコピーするかどうかを制御します。
X Window では、オプションの名称が“OS クリップボード / system clipboard”の代わりに “CLIPBOARD” となります。端末ウインドウで選択したテキストは慣習通り、常に自動的に PRIMARY 選択範囲におかれます。しかしこのチェックボックスを有効にした場合、“CLIPBOARD” にも 同時におかれます。
PuTTY は端末に貼り付けるためにメニュー項目を除いて三つの UI 操作を設定できます。マウスボタンの左右のクリックどちらかで貼り付けるか (section 4.11.1 参照)、Shift-Ins を押すか、Ctrl-Shift-V を押します。ただし最後のものはデフォルトでは無効になっています。
これら三つの操作がどのクリップボードから貼り付けるか (または貼り付け操作はしないか) を設定できます。クリップボードが一つしかないシステム (例えば Windows) では、そのクリップボードから貼り付けるか、PuTTY の内部メモリに格納される、そのウインドウで 最後に選択したテキストから貼り付けるかを選べます。 X Window では、標準的なオプションは CLIPBOARD と PRIMARY です。
(PRIMARY は最後に選択したテキストも参照するという点で概念的には似ています – そのウインドウではなくすべてのアプリケーションに対してという違いがあります。)
二つのキーボードショートカットのオプションは対応するキーで同じクリップボードにコピーします。 Shift-Ins で貼り付けるように指定したクリップボードは、Ctrl-Ins でコピーする先になります。同様に、Ctrl-Shift-C は Ctrl-Shift-V で貼り付ける先にコピーします。
X Window では、好きな名前を入力することもできます。例えば、あまり使われない標準の選択範囲として“SECONDARY”があります。使っている一例として Emacs では、Meta キーを押しながらドラッグして選択するか、クリックして貼り付けます。 PuTTY がこのクリップボードにアクセスするようにキーボード操作を設定すると、他のアプリケーションと相互に受け渡しできます。他にできることとして、クリップボードの名前を自分で付けて、PuTTY の間だけで、もしくはそう設定した PuTTY だけで共有されるクリップボードを作れます。
クリップボードにはテキスト (改行とタブを含む) 以外の文字も含むことができます。 ESC といった制御文字は端末セッションに貼り付ける、サーバ側で動作しているプログラムによっては予期しない効果が起きることがあります。有害なウェブページからテキストをコピーすると、そのような文字がクリップボードに入り込むかもしれません。
デフォルトでは、PuTTY はあまり普通ではない制御文字をフィルタして、より明確なテキスト整形の文字 (改行 CR/LF、タブ HT、バックスペース BS、DEL) のみ通過させます。
このオプションを設定するとフィルタしなくなり、貼り付け時にはクリップボード上のすべての文字がそのままセッションに送信されます。あなたが簡単なスクリプティングなどの目的で、意図的に制御文字を貼り付ける場合に有用かもしれません。
コピーパネルによって、特に端末からクリップボードへのコピーに関するふるまいを制御できます。
端末ウインドウでダブルクリックしてドラッグすると PuTTY はテキストを単語ごとに選択します。このパネルで何を単語とするかを細かく制御できます。
それぞれの文字にはクラスという小さな数 (通常 0, 1, 2) が割り当てられます。 PuTTY は同じクラスに属する文字の連続を一つの単語として扱います。つまり文字のクラスを変更すると、単語選択の振る舞いが変わります。
つまり、例えば @ をクラス 2 に割り振ると、メールアドレスをダブルクリックだけで選択できます。
この割り当てを変更するには、まず文字のグループを一覧から選択します。そしてクラス番号を入力したら、“設定 / Set”ボタンを押します。
この仕組みは ASCII 文字のみ対応しています。一覧を Unicode 全体へ広げるのは無理なためです。
文字クラスの定義はサーバから送られる制御シーケンスで切り替えできます。この設定オプションはデフォルトの状態を指定するので、端末をリセットしたときにその状態に戻ります (Section 3.1.3.6 参照)。しかしセッション中に“設定の変更 / Change Settings”でこのオプションを変更した場合、即座に状態が変わります。
“プレーンテキストに加えてRTFでクリップボードにコピー / Copy to clipboard in RTF as well as plain text”を有効にすると、PuTTY はクリップボードにテキストに加えて整形情報を書き込みます。これにより (例えば) ワープロソフトに貼り付けると文字が PuTTY の表示と同じフォント・色・スタイル (太字や下線) になります。
このオプションはかえって不便な場合が多々あります。そのためデフォルトで無効になっています。
このオプションはデフォルト有効です。無効にするとサーバが送る色の付いたテキストの制御シーケンスを無視します。
もし派手すぎるアプリケーションがあるならば、このオプションを無効にすると PuTTY はデフォルトの文字色と背景色だけを使用します。
このオプションはデフォルト有効です。無効にするとサーバが xterm の対応する拡張 256 色モード の制御シーケンスを送っても無視します。
もし 256 色モードに対応したアプリケーションのはずなのに色が表示されない場合は、サーバに端末が 256 色表示に対応していると知らせる必要があります。 Unix では TERM が 256 色対応の設定になっているか確認します。例えば infocmp コマンドで確認できます:
$ infocmp | grep colors
colors#256, cols#80, it#8, lines#24, pairs#256,
出力に “colors#256” がない場合、端末設定の変更が必要です。モダンな Linux マシンでは “xterm-256color” のようにします。
訳注: 一時的な変更ではない場合、環境変数をシェルから直接設定したりサーバ側の設定ファイルを変更したりするのではなく、PuTTY の通知する端末タイプの設定を変更します。Section 4.17.3 を参照してください。
このオプションはデフォルト有効です。無効にすると、PuTTY はモダンな端末が対応している 24-bit RGB カラー値を指定する制御コードをサーバが送ってきても無視します。
サーバが送る太字の制御シーケンスを PuTTY はいくつかの方法で処理できます。 フォントを太字にするか、同じフォントで明るい色にするか、両方 (明るい色かつ太いフォント) か、それをこのコントロールで選べます。
デフォルトでは太字は色で表現します。そのため太字でないテキストは明るい灰色で太字は鮮やかな白 (他の色も同様) です。設定を“フォント / The font”にすると太字も太字でないテキストも同じ色になり、代わりにフォントで違いを表します。 “両方 / Both”を選ぶとフォントと色の両方が変わります。
いくつかのアプリケーションは“太字の黒”が背景の黒と区別可能だと仮定しています。その場合“フォント / The font”を選ぶとテキストが見えなくなります。
論理パレットとは Windows アプリケーションが 8 ビットカラー のディスプレイで Windows 標準パレットの代わりに正確な色を使うための仕組みです。
もし 8 ビットディスプレイで色がうまく表示されないなら、このオプションを試せます。ただし、この機能がそれほどうまく働いたことはありません。
このオプションを有効にすると PuTTY は設定した“標準の背景/文字 / Default Background/Foreground”や“カーソルの色/カーソル上の文字 / Cursor Colour/Text” (Section 4.13.7 参照) を無視してシステムのデフォルトを使います。
このオプションを有効にすると太字の文字は太字でない文字と同じ色になります。太字をフォントの違いで表すように変更したほうがよいでしょう (Section 4.13.4 参照)。
カラーコントロールで表示する色を指定できます。 PuTTY のどれかの色を変えるには、リストボックスから変更したい色を選びます。すると色の RGB 値が右側に表示されます。そこで“変更 / Modify”を押すと色選択ダイアログが表示され、別の色を選択できます。 (もしくは 0 から 255 の RGB 値を直接入力できます。)
PuTTY ではカーソルの色, 標準の文字色, 背景色と、 ANSI カラー (黒, 赤, 緑, 黄, 青, 赤紫, 水色, 白) を変更できます。またそれらの太字版の色も指定できます。太字を色で表す場合にそれらを使います (Section 4.13.4 参照) し、サーバが使うよう指定した場合にも使います。 (“標準の強調背景 / Default Bold Background”は太字に使われる背景色ではありません。背景を強調するようにサーバから指定があった場合に使います。
[Custom] カーソルの色については IME が有効の場合の色も指定できます。
[Custom] 壁紙パネルは PuTTY ウインドウの背景を変更します。
背景の変更方法を選びます。
背景設定時は“透過率の調整 / Adjust transparency”で背景色の透明度を変更できます。 0 では壁紙はまったく透けて見えず、255 では逆に背景色が見えなくなります。例えば 64 にすると 25% 透過します。 (“ビットマップファイルを使用”では“アルファブレンディングを使用 / Use alpha-blending”を選ぶ必要があります。)
“デスクトップと画像ファイル”では“アルファブレンディングを使用”を有効にすると画像をデスクトップ壁紙上に合成するときに画像のアルファチャンネルを使用します (画像に PNG など対応形式を使用する必要があります)。 “ビットマップファイルを使用”では可能な場合に常にアルファチャンネルを使用します。
画像ファイルを使うモードを選んだ場合、参照ボタンで壁紙に使う BMP ファイルを選択できます。 Windows XP 以降では JPEG や PNG などの形式も選択できます。
BMP ファイルはバージョン 4 形式だとおそらく表示されません。その場合はペイント (MSPaint) で開いて保存しなおすか、ImageMagick のような変換プログラムで BMP2 や BMP3 形式に変換します。 (後方互換の仕様として、ファイル名が空欄の場合は putty.bmp というファイルを読み込みます。putty64.bmp のように透過度の指定もできます。この仕様は削除予定です。)
画像は“配置 / Placement”や“位置揃え / Alignment”で表示形式を変更できます。
“ウインドウの移動時には描画しない / Suspend updating when moving window”を選ぶとウインドウ移動時の描画を停止してパフォーマンスを改善します。Windows Vista 以降では画面がバッファされるため効果がありません。
“システムリソース / Use System Res”を有効にすると壁紙にシステムメモリを利用します。見掛けのメモリ消費量が減り、BMP 形式の壁紙を複数の PuTTY で共用するとメモリが節約できる可能性がありますが、メモリアドレス空間の制約から 32bit Windows での高解像度の画像や画面には向きません。バージョン 0.66 までのデフォルトです。
[Custom] アイコンと透過パネルは PuTTY ウインドウのアイコンやウインドウの透過度を変更します。
タイトルバーの脇に表示するアイコンを設定します。参照ボタンで ICO ファイルを選択できます。
EXE ファイルや DLL ファイルの場合、ファイルパスの後にコンマ (,) を続けて 0 以上の数値を記述することで何番目のアイコンかを指定できます。アイコンの ID で指定したい場合はその ID を負にした値を入力します。(バージョン 0.82 以前の場合、-1 を指定できません。
端末ウインドウ全体 (タイトルバーや表示内容も含む) の透過度を設定します。
値は百分率で指定します。例えば 90 にすると、端末ウインドウを 10% 透過して表示します。 Windows のコマンドプロンプトと同様の設定です。
非アクティブ時の不透明度は通常時の設定との積 (最低 10%) になります。例えば通常時を 90 にした上で非アクティブ時を 80 に設定すると不透明度は 72% となり、端末ウインドウにフォーカスがない時は 28% 透過して表示します。
端末ウインドウの非アクティブ時に不透明度が変化し始めるまでの遅延時間を設定します。値は秒単位で 0 から 10,000 まで指定できます。
接続パネルで複数の接続タイプに適用されるオプションを設定します。
しばらく何もしないでいるとセッションが予期せず閉じてしまう場合 (多くは“Connection reset by peer”という表示で)、このオプションを使います。
一部のネットワークルータやファイアウォールは通過する接続すべてを追跡しています。通常、これらのファイアウォールは一定時間の間上り下りの両方でデータが通信がないと、接続が切れたと判断します。そのためセッションのトラフィックがしばらく途絶えると、PuTTY のセッションがファイアウォールによって閉じられてしまうことがあります。
このオプション (“Keepalive の間隔 / Seconds between keepalives”) で PuTTY がセッションを邪魔しないような形で定期的にデータを送るようになります。ファイアウォールが使われていない接続を切断しているようなら、0 でない値を入力してみます。値の単位は秒なので、ファイアウォールが 10 分で切断するなら 300 秒 (5 分) というように設定します。
ただし Keepalive が有効とは限りません。接続を使わないと切断するファイアウォールには役立ちますが、サーバとあなたの間の接続が断たれてしまうようなら keepalive は事態を悪化させます。セッションが使われていない間に接続が一時的に切れ、しかしサーバやクライアントが何かデータを送る前に復旧した場合、どちらの側もそれに気づきません。しかし、どちらかが断線中に何かを送ろうとすると、何度も再送しようとして最終的に諦めて接続を放棄してしまいます。そして接続が復旧しても、もう片方は通信してもらえなくなります。 Keepalive はこの種の問題を悪化させます。なぜなら断線中に PuTTY がデータを送ろうとする可能性が増すからです。 (他の種類のネットワーク処理も同じ問題を起こします。特に SSH-2 の rekey はこの影響があります。Section 4.20.2 を参照してください。)
そのため、keepalive が接続の切断を防ぐか悪化させるかはサーバとの間のネットワークにどんな種類の問題があるかによります。
Keepalive は Telnet と SSH のみで対応しています。 Rlogin, SUPDUP, Raw は実装する手段がありません。 (代替手段は section 4.16.3 を参照してください。)
SSH-1 を使っていて SSH-1 ignore メッセージの取り扱いのバグがサーバにある場合は (Section 4.29.14 参照)、このオプションを有効にしても効果がありません。
Nagle のアルゴリズムは TCP/IP 実装の詳細の一つで、小さなデータパケットが大量にネットワークに流れるのを防止するためのものです。 Nagle のアルゴリズムを有効にすると、PuTTY の使用帯域幅は少し効率的になります。無効にすると、ある種のサーバに接続しているときにキー入力のレスポンスが上がるかもしれません。
Nagle のアルゴリズムは対話型接続ではデフォルトで無効です。
注意: TCP keepalive をアプリケーションレベルの keepalive (Section 4.16.1) と混同しないでください。確かでないならば、アプリケーションレベルの keepalive が適切です。 TCP keepalive の機能は完全性のためにあります。
TCP keepalives の考えはアプリケーションレベルの keepalive と似ていて、同じ欠点があります。主な違いは:
TCP keepalive は接続を保つためよりも、片方だけが開いている接続を閉じるのに役立ちます。
TCP keepalive はデフォルトで無効です。
このオプションでインターネットプロトコルやアドレス方式の新旧 (IPv6 と IPv4) を選択できます。選択したプロトコルを外向きのネットワーク接続のほとんど (プロキシへの接続を含む) で使います。しかし、トンネルには別の設定があります。Section 4.28.2 を参照してください。
デフォルトの設定は“自動 / Auto”で、PuTTY が判断してプロトコルを選びます。 (数値のインターネットアドレスを指定すると、そのアドレスの示すプロトコルを使います。ホスト名を指定すると、指し示すアドレスを調べて IPv6 アドレスがあれば IPv6 を、なければ IPv4 を使います。)
PuTTY に特定のプロトコルを使わせるならば、“IPv4” や “IPv6” を明示的に指定できます。
ネットワーク接続を確立する先とは違うホストに最終的に接続すると PuTTY に知らせます。
例えばある PuTTY のセッションで SSH ポートの転送を設定し、あるポート (例えば localhost ポート 10022) への通信が別のマシンの SSH ポート (例えば foovax ポート 22) に送られるようにして、そして別の PuTTY でその転送ポートにつなぐとします。
putty_1@localhost ===> 中間サーバ
putty_2@localhost ===> localhost:10022 -----> 中間サーバ .... foovax:22
==== SSH 接続 ---- ポート転送 .... 設定した経路
通常の使い方では、2 番目の PuTTY は実際に接続する先の名前 (つまりこの例では localhost ポート 10022) でホスト鍵キャッシュにアクセスします。しかし論理名オプションを使うと、2 番目の PuTTY にあなたの知っている本当のホストの名前でキャッシュできます (この場合 foovax)。
putty_2@localhost ===> localhost:10022 ---> 中間サーバ ===> foovax:22
論理名 foovax:22
これは (おそらくポート転送の取り決めが変わるせいで) 同じサーバに様々な経路でアクセスしている場合に便利です。論理ホスト名を一貫して設定しておけば、PuTTY はホスト鍵を再確認するよう尋ねはしません。反対に、同じローカルのポート番号を様々なサーバへのポート転送で使う場合、特定のホスト鍵をローカルホストのポート番号の鍵としてキャッシュしたくないはずです。 (後者の場合は代わりに明示的にセッションのホスト鍵を指定できます。Section 4.21.3 を参照してください。)
単にホスト名をここに入力すると、実際のポート番号に関係なく PuTTY はデフォルトの SSH ポート番号でホスト鍵をキャッシュします (なぜなら上の例のように普通は無意味なポート番号 (10022) につないで、それが別のマシン (foovax) のポート 22 に行き着くからです。)。論理名にポート番号も指定するには、論理ホスト名に続けて区切りのコロンとポート番号を入力します。例えば論理ホスト名を “foovax:2200” とすれば foovax のポート 2200 に繋いだときのようにホスト鍵をキャッシュします。
このオプションでホスト名を与えると、リモートホスト名を表示する他の場所にも影響します。例えばデフォルトのウインドウタイトルや SSH パスワードプロンプトです。これは実際に接続しているホストの方が、単にそのホストに接触するための手段の名前よりも重要だという事実を反映したものです。 (SSH 以外のプロトコルを使っている場合も同様です。)
データパネルでは、サーバに影響を与えられる様々なデータを設定できます。
このパネルのそれぞれのオプションは複数のプロトコルに適用されます。一つのプロトコルにだけ当てはまるオプションはそれぞれのプロトコルの設定パネルにあります。
SSH, Telnet, Rlogin のプロトコルはどれも、ログインするユーザ名を毎回いちいち入力せずに指定できます。(一部の Telnet サーバは対応していません。)
このボックスにユーザ名を入力します。
ある環境、例えばシングルサインオンのある大きな組織では、ローカルの OS にログインしているユーザ名 (もしあるならば) をデフォルトとするのが理にかなっています。これは GSSAPI 鍵交換とユーザ認証 (Section 4.25 や section 4.20.1.1 を参照) と一緒に使うと特に便利でしょう。このコントロールでデフォルトの挙動を変更できます。
ダイアログには参考に現在のユーザ名が表示されます。これは設定には保存されないので、もし別のユーザが保存したセッションを使ったならそのユーザの名前を使います。
PuTTY で接続できるほとんどのサーバは多くの異なる種類の端末から接続できるように設計されています。それぞれに正しい制御シーケンスを送るために、サーバは相手の端末の種類を知る必要があります。そのため、SSH, Telnet, Rlogin プロトコルでは端末の特徴を表す文字列を送信できます。 Unix サーバではこれで termcap や terminfo データベースからエントリを選択し、アプリケーションに何の制御シーケンスを送るかやキーボードがどんな文字シーケンスを生成するかを知らせます。
PuTTY は Unix の xterm プログラムをエミュレートするので、デフォルトでは xterm を端末タイプとして送信します。もしこれが望ましくなく、リモートシステムが“未知の端末タイプ / Unknown terminal type”と言うならば、これを vt220 のような別の値に変更します。
問題が端末タイプのせいか判らないならば、アプリケーションやサーバのマニュアルを参照する必要があります。
Telnet, Rlogin, SSH プロトコルはクライアントからサーバに端末の速度を通知できます。
実際の接続の速度は常に“できるだけ速く”なるためこの値は影響を与えません。サーバソフトウェアが挙動を変えるために時々使うことがある、ただのヒントです。例えば遅い速度が示されたら、サーバはより帯域消費が少ない表示モードにできます。
この値はネットワーク環境では通常無意味です。しかしサーバがデフォルト値ではうまく動かない場合のために PuTTY では変更できるようになっています。
書式は 38400,38400 のようにコンマ区切りの 2 つの数です。最初の数値が (サーバからの) ビット毎秒の出力速度で、二番目が (サーバへの) 速度です。 (Rlogin プロトコルでは最初の数値だけを使います。)
このオプションは Raw 接続には効果がありません。
Telnet プロトコルはクライアントが環境変数をサーバに渡す手段を持っていました。多くの Telnet サーバはセキュリティ上の欠点からこの機能への対応を止めましたが、仕組みを完全に無効化せずに問題を回避する方法を見つけたサーバのために PuTTY はまだこの機能に対応しています。
SSH バージョン 2 でも似た仕組みがあり、こちらはセキュリティの問題がなく実装も簡単です。よほど古い SSH-2 サーバ以外は対応しています。
この設定は SSH-1, Rlogin, Raw プロトコルでは使いません。
接続で送信する環境変数を追加するには、、変数名を“変数 / Variable”に、値を“値 / Value”に入力して“追加 / Add”ボタンを押します。削除するには一覧から項目を選らんで“削除 / Remove”を押します。
プロキシパネルで PuTTY が様々な種類のプロキシを使ってネットワーク接続を行うように設定できます。このパネルの設定は PuTTY がセッションを確立する主要なネットワーク接続と、SSH ポート転送による追加の接続に影響を与えます (Section 3.5 参照)。
他のソフトウェア (ウェブブラウザなど) と違い、PuTTY はプロキシを使うべきかや宛先による使い分けはできません。プロキシを使う場合、常に明確に設定する必要があります。
“プロキシの種類 / Proxy type”ドロップダウンリストで PuTTY がネットワーク接続に使うプロキシの種類を設定できます。デフォルトは“なし / None”で、プロキシをまったく使いません。
CONNECT メソッドを使って接続を代理させます。 RFC 2817 に準拠した方法です。
connect myhost.com 22 のようなコマンドで外部のホストに接続できます。 “Telnet”を選ぶとこの種類のプロキシを使用でき、section 4.18.5 で指定したコマンドを渡せます。
“プロキシホスト名 / Proxy hostname” 欄は PuTTY の保存済みセッション名か、それが存在しなければホスト名として認識されます。これによって、保存済みセッション自体にも SSH プロキシの設定をすればマルチホップのジャンプ経路作成が可能になります。また、SSH と非 SSH の組み合わせも可能です。
-J オプションに似ています)。
これは例えば、PuTTY が本来対応していない種類のネットワークプロキシに接続するのに使えます。もしくは TCP/IP とはまったく異なるものを経由できます。
このモードはコマンドラインでも有効にできます。 Section 3.11.3.27を参照してください。
通常非ローカルのネットワークへの接続だけプロキシが必要です。例えば会社の LAN の外に接続する場合だけ必要となります。 “除外するホスト/IP / Exclude Hosts/IPs”に IP アドレスの範囲か DNS 名の範囲を入力しすると、プロキシはそこに使わずに直接接続します。
“除外するホスト/IP / Exclude Hosts/IPs”には複数の除外範囲をコンマで区切って入力できます。範囲には IP アドレスか DNS 名を、* をワイルドカードとして入力できます。例えば:
*.example.com
これは .example.com で終わるホスト名をプロキシしません。
192.168.88.*
これは IP アドレスが 192.168.88. で始まるものをプロキシから除外します。
192.168.88.*,*.example.com
これは両方を同時に除外します。
訳注: コンマの前後に空白があっても問題ありません。
ローカルホスト (localhost とすべてのループバック IP アドレス) は除外指定しなくてもプロキシされません。この挙動が問題になるとは考えにくいですが、“ローカルホストからもプロキシ接続を行う / Consider proxying local host connections”を有効にすると除外を無効にできます。
名前解決をプロキシで行っている場合 (Section 4.18.3 参照)、プロキシの除外設定が対象の IP アドレスを必要としていないことを確認してください。 PuTTY が名前解決していないホスト名が渡されると、その IP アドレスが分からないため除外リストを確認できません。
プライベートネットワークにアクセスするのにプロキシを使っている場合、DNS 名前解決を PuTTY が (クライアント側で) するかプロキシがするかで違いが生じます。
“プロキシ側で DNS 名前解決する / Do DNS name lookup at proxy end”オプションでこれを制御できます。 “いいえ / No”にすると、PuTTY は必ず自分で名前解決し、プロキシには IP アドレスが渡ります。 “はい / Yes”にすると、PuTTY は必ずホスト名をプロキシにそのまま渡して自分では名前解決しません。
“自動 / Auto” (デフォルト) にすると、PuTTY はプロキシの種類によって適切な方法を取ります。ほとんどの種類のプロキシ (HTTP, SOCK5, SSH, Telnet, ローカル) はホスト名をそのまま渡しますが、SOCKS4 ではそうしません。
プロキシ側で DNS 名前解決をするならば、プロキシから除外するホスト (Section 4.18.2 参照) がホストの IP アドレスを知らないでも働くようにします。ホスト名を PuTTY が名前解決せずにプロキシに渡すので、除外一覧を IP アドレスでは確認できないからです。
本来の SOCKS4 プロトコルはプロキシ側の DNS 名前解決に対応していません。プロトコル拡張 (SOCKS 4A) で対応していますが、すべての SOCKS4 サーバが対応しているわけではありません。 SOCKS4 のプロキシ側で名前解決に失敗したなら、それが原因です。
もし接続先ホスト名に関して PuTTY に全く DNS 問い合わせをして欲しくないならば (例えば、DNS リゾルバが解決できない名前に対して非常に遅い反応をするなど)、この設定を“はい / Yes”にした上で、GSSAPI 認証と GSSAPI 鍵交換 (section 4.25 と section 4.20.1.1 を参照) も無効にする必要があります。これは GSSAPI の準備でも接続先ホスト名に対して DNS 問い合わせが関わるためであり、そしてその問い合わせは別個の GSSAPI ライブラリが行うため、PuTTY は動作を上書きまたは再設定できないためです。
認証が必要なプロキシの場合、ユーザ名とパスワードを“ユーザ名 / Username”と“パスワード / Password”に入力します。
セッションを保存すると、プロキシパスワードも平文で保存します。 PuTTY の設定データにアクセスできる人は誰でもそれを見つけられます。
ユーザ名とパスワードが必要なのに指定されていなかった場合、PuTTY は端末ウインドウで対話型プロンプトで尋ねます。
認証は一部のプロキシで対応しています:
Telnet プロキシの場合、通常ファイアウォールの Telnet サーバに connect コマンドとホスト名とポート番号を渡します。もし異なったコマンドが必要ならば、“プロキシ送信するコマンド / Command to send to proxy”ボックスに入力します。
ローカルプロキシの場合、ローカルで実行するコマンドを入力します。
もしプロキシの種類として“プロキシに SSH 接続してコマンド実行 / SSH to proxy and execute a command”を使うならば、SSH プロキシサーバで実行するコマンドはここで指定します。同様に、“プロキシに SSH 接続してサブシステム起動 / SSH to proxy and invoke a subsystem”でも、サブシステムの名前はここに指定します。
このコマンド文字列は、\n で改行 (LF), \r で復改 (CR), \t でタブを表現できます。 \x と 2 桁の十六進数で他の文字を表します。 \\ で \ 文字自体になります。
また、特別な文字列 %host と %port は接続するホスト名とポート番号に置換されます。 %user と %pass がプロキシのユーザ名とパスワードとして指定した文字列です。 (設定されていない場合、プロンプトで尋ねます。) – SSH プロキシの類では置換されません (プロキシのユーザ名/パスワードは SSH 認証で使われるからです)。 %proxyhost と %proxyport はプロキシパネルで指定したホスト情報になります (これはローカルやリモートコマンドで便利でしょう)。 %% で % という文字自体になります。
Telnet プロキシサーバがコマンドの前にユーザ名とパスワードを要求する場合はこのようにします:
%user\n%pass\nconnect %host %port\n
これでユーザ名とパスワードを最初の二行で送ってから、指定したホストのポートに接続するコマンドを送信します。 %user や %pass を Telnet コマンドに含めない場合、“Username”や“Password”の設定内容は無視されます。
プロキシの相互処理には診断結果の出力が伴う場合があります。ローカルプロキシコマンドの場合は特にそうです。
“プロキシの診断をターミナルに表示する / Print proxy diagnostics in the terminal window”を設定すると、プロキシ処理の結果を、セッションの出力と一緒に端末画面に出力します。
デフォルトの (“いいえ / No”) では、イベントログにだけ出力します。 “はい / Yes”では端末にも出力し、セッションの出力と混ざるかもしれません。 “セッション開始まで表示 / Only until session starts”は中間で、セッションが始まったと思われる時点 (プロトコルによります) までは端末にも出力しますが、それ以降のプロキシ関係のメッセージはイベントログにのみ出力します。
SSH パネルで SSH セッションのみに適用されるオプションを設定できます。
SSH では通常のシェルセッションをサーバで実行する必要はありません。代わりに特定のコマンド一つ (例えばメーラ) を実行できます。そうしたい場合は“リモートコマンド / Remote command”にコマンドを入力します。
ほとんどのサーバはコマンドを実行した後で接続を閉じます。
これを有効にすると PuTTY はリモートサーバに接続を確立した後でシェルやコマンドを実行しません。 SSH 接続をポート転送にだけ使う場合やサーバ上のアカウントがシェルを実行できない場合にだけ使います。
SSH プロトコルバージョン 2 のみで利用できます (バージョン 1 では常にシェルを実行しようとします)。
コマンドラインオプション -N でも有効にできます。 Section 3.11.3.13 を参照してください。
Plink でこの機能を使うと正しい方法では Plink プロセスを終了できなくなります。終了するには Control-C か他のプログラムから強制終了を行うしかありません。
SSH 接続のデータを圧縮します。サーバから届くデータは送信前に圧縮され、それをクライアント側で展開します。同様に、PuTTY がサーバに送るデータもまず圧縮され、サーバが展開します。多くの低帯域の接続で役立つはずです。
バージョン 2 と古い SSH プロトコルバージョン 1 のどちらを使うかを選択します。
通常はデフォルトの“2”にしておくべきです。古い SSH-1 プロトコルは機能が少ないだけでなく、開発されておらず、多くの暗号的な弱点が知られており、一般に安全でないとされています。 PuTTY の SSH-1 実装は主として互換性のために用意されており、これ以上の機能追加はされません。
サーバがどちらのバージョンも使える場合は“2”を使用してください。もし SSH-1 しか対応していないサーバや機器がある場合は、ここで“1”を選択し、接続は脆弱で危険なものとして扱ってください。
PuTTY はここで選択したプロトコルがサーバに適合しなかった場合でも古いバージョンにフォールバックしません。代わりにエラーメッセージを表示し、接続を中断します。これによって SSH-2 接続を意図していたのに攻撃者によって SSH-1 にダウングレードさせられてしまうのを防げます。
可能な場合 PuTTY に既存の SSH 接続を共有させます。
SSH-2 プロトコルは一つの SSH 接続上に複数のデータチャンネルを流せます。そのため一度ログインを行って (重い暗号化設定を一度だけにして) 複数の端末ウインドウを開けます。
それぞれの PuTTY は端末セッションを一つしか動かせませんが、この機能を有効にすると、ある PuTTY に他の PuTTY がホストに接続しているか確認させ、もしあればその SSH 接続を共用できます。
この機能を有効にするには“可能ならば SSH 接続を共有する / Share SSH connections if possible”をチェックします。そうすればそのホストに PuTTY で接続するときに、できるならば既存の SSH 接続を再利用しようとします。例えばシステムメニューの“セッションの複製 / Duplicate Session”は同じホストのセッションをもう一つ別に開きますが、共有が有効ならば既存の SSH 接続を再利用します。
このモードの使用中は最初にサーバに繋いだ PuTTY が“上流 / upstream”となり、実際の SSH 接続を管理します。接続を再利用した他の PuTTY は “下流 / downstreams”でサーバにはまったく接続していませんが、上流の PuTTY にプロセス間通信で接続しています。
この仕組みを動かすには上下流両方の PuTTY で共有オプションを有効にします。
前述の仕組みから上流の PuTTY はすべての下流が閉じるまで終了できません。これはポート転送や X11 転送のときの状況に似ています。端末セッションが終了しても PuTTY は転送している接続のために終了できません。
このシステムをより細かく制御したい場合のために 2 つの追加オプションがあり、ある PuTTY を上流下流のどちらか、もしくは両方として動作させるように指定できます。 (この設定は“可能ならば SSH 接続を共有する / Share SSH connections if possible”をチェックしないと効果がありません。) デフォルトでは両方がチェックされており同じ設定で起動した PuTTY の一つが上流となり接続を共有します。ですが PuTTY を上流にしたくない場合 (例えば絶対にすぐに閉じたいとき) や下流にしたくない場合 (例えば特別な秘密鍵で認証したいとき) にはこれらのチェックを外せます。
上述の機能説明で“PuTTY”としましたが、他の PuTTY ツールの確立する SSH 接続もこの仕組みを使えます。例えば、 PSCP や PSFTP が接続の共有を有効にした設定を読み込むと、既存の GUI PuTTY の SSH 接続の下流となれます。例外として、PSCP や PSFTP は上流にはなりません。
Plink でプログラム的に上流がすでに存在するかテストできます。 Section 7.2.3.4を参照してください。
[Custom] 上流の PuTTY で“共有の際に確認する / Ask on sharing”を有効にすると共有前に確認ダイアログを表示します。共有をキャンセルした場合、下流の接続は失敗します。
Kex パネル (“鍵交換 / key exchange”の略) は SSH-2 鍵交換に関係したオプションを設定できます。
鍵交換は SSH 接続の最初 (とそれ以後時々) に発生します。そこで SSH のセキュリティ機能の基本となる共有秘密鍵を作成します。そのため鍵交換が安全なことは接続のセキュリティに非常に重要です。
鍵交換は暗号学的に負荷の高い処理です。もしクライアントかサーバのどちらかが遅いマシンだと、遅い方式は完了するのに数十秒かかります。
もし接続の開始が遅すぎるまたは接続が定期的に止まってしまう場合は、この設定を変えると解決するかもしれません。
もし設定が理解できない場合は、変更しないほうが安全です。
このパネルはすべて SSH-2 のもので、SSH-1 にはまったく影響しません。
PuTTY は様々な SSH-2 鍵交換の方法に対応しており、そこから使用するものを一つ選べます。設定は暗号の選択と似ています (Section 4.22 参照)。
PuTTY は以下の種類の鍵交換に対応しています:
もし選択したアルゴリズムが“-- ここから下は警告する -- / warn below here”よりも下にある場合、接続時に警告ダイアログが表示されます。これは暗号の選択の警告と似ています (Section 4.22 参照)。
PuTTY は GSSAPI 認証による鍵交換方式に対応しています。 “GSSAPI 鍵交換を試みる / Attempt GSSAPI key exchange” チェックボックスによって有効になります。 (これは“GSSAPI”パネルでも設定できます。)
PuTTY が GSSAPI 認証の鍵交換を行えるのは Kerberos V5 を使った場合のみで、他の方式には対応していません。 PuTTY を使用しているユーザが Kerberos V5 の有効なクレデンシャル (認証情報) を持つ場合、PuTTY は他の通常の SSH 鍵交換方式より優先してこれを選択します。 section 4.20.1 の一覧にある多くの一般的な方式は GSSAPI ベースにも相当するものがあります。サーバによってどれが使われるか決定されます。 (PuTTY の GSSAPI 認証での鍵交換方式の優先順位は固定されており、選択ポリシーの順序によりません。)
SSH 鍵交換の一部として SSH 認証を行う利点は、資格の委譲を行う場合に明らかです。(section 4.25.1 を参照してください)。 SSH 鍵交換はそのセッションで後で繰り返し行えます。そのため (有効期限が短い事の多い) Kerberos V5 クレデンシャルがクライアントで更新された場合に自動的に再委譲できます。 (この機能は一般に“カスケーディングクレデンシャル (cascading credentials)”と呼ばれます。)
もしサーバが GSSAPI 鍵交換に対応していない場合でも、SSH ユーザ認証の段階では GSSAPI に対応しているかもしれません。その場合は Kerberos クレデンシャルでログインできますが、セッション開始時点で有効であったクレデンシャルのみ委譲でき、長期間のセッションにおいて自動的に更新することはできません。 PuTTY での GSSAPI ユーザ認証の制御については section 4.25 を参照してください。
GSSAPI 鍵交換の別の効果は、通常の SSH の仕組みである固定的なホスト鍵 (section 2.3) の仕組みを置き換えることです。そのため、この方式を使うとサーバのホスト鍵を受け入れるかどうかというダイアログが表示されません。代わりに Kerberos のデータ交換によって接続先ホストとあなた自身のアイデンティティ検証が行われます。
接続開始時に作成したセッション鍵が使われすぎたり長時間経ったりした場合は、SSH 接続に攻撃を受ける可能性が高まります。そのため SSH-2 プロトコルの仕様は新しい鍵交換をたまに行うように決めています。これはクライアントとサーバのどちらからでも開始できます。
鍵の再設定をする間は SSH 接続にデータは流せないため、“フリーズ”したように見えます。 (鍵交換が発生するとイベントログに記録されます。Section 3.1.3.1 参照。) 通常、最初の鍵交換と同じアルゴリズムの近い負荷のものが使われます。
このオプションは PuTTY がどれくらいの頻度で鍵交換の再実行 (“rekey”) を行うかを制御します。また特殊コマンドメニューからいつでも鍵交換を強制できます (Section 3.1.3.2 参照)。
keepalive が常に役立つとは限らなかったように、時間による rekey を切ったほうがいい場合もあります。 SSH 接続が数時間途切れる予定があってその間にデータを送らない場合は、その時間の rekey が接続を切ってしまう原因になります。 rekey を無効にすると (ファイアウォールが邪魔をしなければ) 接続は原則的には残ります。この問題については section 4.16.1 を参照してください。そのため rekey は keepalive と同じ特性を持ちます。 (ただしオフにするか決めるときは rekey には暗号学的な価値があると憶えておいてください。) それでも、SSH サーバが鍵交換を開始する可能性は残ります。
バイト数だけでなく以下の省略記法が使えます:
1k” は 1 KB (1024 バイト)。
1M” は 1 MB (1024 KB)。
1G” は 1 GB (1024 MB)。
データ量による rekey を完全に無効化するのは悪い考えです。 SSH-2 プロトコルの整合性とある程度の秘密性はパケットの 32 ビットのシーケンス番号が巻き戻る前の rekey 実行にある程度依存しています。時間による rekey と違ってデータによる rekey は SSH 接続を使っていないときには起きないため、時間によるもののような問題は起きないはずです。ちなみに SSH-1 プロトコルは rekey なしの SSH-2 よりも整合性保護が弱くなります。
ホスト鍵はサーバの同一性を確認するために使用します。サーバが (中間者攻撃やサーバ自体の置換によって) スプーフィングされていないと保証できます。ホスト鍵の基本的な紹介については section 2.3 を参照してください。
このパネルのほとんどは SSH-2 にのみ関連します。 SSH-1 が対応しているホスト鍵は 1 種類だけです。
PuTTY は様々な種類の SSH-2 ホスト鍵に対応しており、サーバの同定にあなたがどれを使いたいかを決められます。設定は暗号の選択と似たものになっています (section 4.22 を参照)。
PuTTY は今のところ以下の種類のホスト鍵に対応しています:
もし PuTTY がすでにホスト鍵を記憶していた場合、サーバが優先度のより高い鍵を持っていてもデフォルトではそれは使われません。そのような鍵をセッション中に PuTTY のキャッシュに追加するには、 “特殊コマンド / Special Commands”メニューを使用します。 Section 3.1.3.2 を参照してください。
キャッシュになければ、PuTTY は純粋にこの設定で指定した順番で鍵の種類を選びます。
最初に一致した鍵の種類が“ここから下は警告する / warn below here”より下だった場合、接続時に暗号選択と似た警告が表示されます (section 4.22を参照)。
デフォルトでは PuTTY は SSH-2 ホスト鍵アルゴリズムの優先順位を、既知のものが上位になるように調整します。
これによって、すでにホスト鍵を持っているサーバについて、新しいホスト鍵を確認し検証することを防げます。(例えば、サーバが代替のホスト鍵を作成し、その鍵が PuTTY の優先順位でより上位に来るか、あなたが順位を上位に変更した場合です。)
しかし一方で既知のものを優先すると、ネットワークを傍受している第三者にあなたがサーバのホスト鍵をすでに知っているかどうかという情報を漏らしてしまうことになります。
この理由から、この処理方針は設定可能になっています。チェックボックスをオフにすると、PuTTY は section 4.21.1 で設定した通りの順序でホスト鍵アルゴリズムを常に使用するようになり、傍受者はあなたがどのホスト鍵を持っているかについて知ることはできなくなります。
PuTTY の自動的なホスト鍵管理が適切でない状況では、PuTTY に特定のホスト鍵を受け付けるように手動で設定することになります。
これが必要な動機の一つに PuTTY がラウンドロビン DNS から複数のサーバアドレスの 1 つを受け取っていて、そしてそれぞれが別のホスト鍵を持っている場合があります。その状況では PuTTY にそれらのサーバのホスト鍵はどれでも受け付けるようにし、そしてそれ以外を拒否するように設定します。
他の動機として、PuTTY の自動ホスト鍵管理がまったく利用できない場合、例えば PuTTY (Plink や PSFTP などでも) がレジストリにアクセスできない環境の時です。その場合、-hostkey コマンドラインオプションでホスト鍵 (複数可能) を指定します。 section 3.11.3.22 を参照してください。
([Custom] ini ファイルに設定を保存する方法があります。 Section 2.1.2 を参照してください。)
PuTTY の自動ホスト鍵管理が間違ったホスト名でホスト鍵を保存してしまう状況の場合、“論理ホスト名 / logical host name”を設定します。 Section 4.16.5 を参照してください。
GUI からホスト鍵を手動で設定するには、ホスト鍵のテキストを “接続に使用するホスト鍵の手動設定 / Manually configure host keys for this connection”に入力し、“追加 / Add”ボタンを押します。入力したテキストが“受け入れるホスト鍵または指紋 / Host keys or fingerprints to accept”に表示されます。鍵は“削除 / Remove”ボタンで削除できます。
ホスト鍵のテキストは次の形式が使用できます:
SHA256:” に続いて 43 文字の Base64 文字列 (英数字と記号 2 種類) で記述される形式です。大文字小文字を区別します。
MD5:” が先頭に付く場合もあります。大文字小文字は区別しません。
/etc/ssh/ssh_host_rsa_key.pub のような場所にあります。
もし PuTTY が SSH 接続するときにこのリストにホスト鍵や指紋がセットされていたら、PuTTY の自動ホスト鍵管理は無効になり、サーバの提示したホスト鍵がリストのどれかと一致した場合だけ接続を許可します。また、指示しない限り、ホスト鍵はレジストリから読み込まれませんし書き込まれません。
通常のようにリストが空ならば PuTTY の自動ホスト鍵管理が動作します。
ある環境では、たくさんのサーバの SSH ホスト鍵がそれぞれ、ある“認証局” (CA, 証明機関) によって署名されます。これによりユーザにとってホスト鍵の設定が単純化されます。その認証局が保証するホスト鍵はどれでも SSH クライアントが受け付けるように一回設定すれば、個々のサーバに初めて接続する度に個別にホスト鍵を確認しなくてよくなるからです。
これを設定するには、“ホスト鍵 / Host keys”設定パネルの“ホスト認証局(ホスト CA)の設定 / Configure host CAs”ボタンを押します。別の設定ダイアログが開き、PuTTY が署名を受け付ける認証局を設定できます。
この設定はすべてのセッションで共通です。 PuTTY の元の設定ダイアログは保存済みセッションごとに変更可能で、全く異なる設定のセッションを準備できます。しかしホスト認証局の設定はただ一つしかなく、PuTTY のすべてのセッションに適用されます。接続の設定が保存済みセッションかそうでないかに関わりません。
(さもなければ、役に立ちません – 認証局を新しいセッション設定毎に手動で設定するのは新しいホスト鍵の度に“受け入れる / Accept”ボタンを押すのと大差ありません。)
新しい認証局をこのダイアログで設定するには:
まず、認証局の公開鍵をファイルから読み込むか、“認証局の公開鍵 / Public key of certification authority”テキストボックスに直接貼り付けます。もしあなたの組織がホスト鍵をこの認証局の方法で署名しているならば、SSH ユーザがクライアントに設定するために認証局の公開鍵を告知しているはずです。
次に、“この鍵の認証を信頼するホスト / Valid hosts this key is trusted to certify”ボックスに、一つ以上のホスト名のワイルドカードを設定し、その認証局がどのホストを代表することを PuTTY が信頼するかを指定します。例えば、あなたがイグザンプル社 (example.com) で働いていて、イグザンプル社の内部のマシンのホスト鍵すべてに署名している認証局を、情報システム部門が告知しているとします。その場合、おそらくあなたはその認証局による example.com ドメインにあるマシンのホスト鍵への署名は信頼したいでしょうが、それ以外のドメインへはそうではないでしょう。そのため“信頼するホスト / Valid hosts”ボックスには “*.example.com” と入力します。
訳注: “...”の内側 *.example.com を入力します。また * は複数レベルのサブドメインに一致します。 \ と ^ が使えないことを除き、PSFTP のワイルドカード Section 6.2.2 と同じ形式です。
認証局の鍵が何に署名できるかを制限することは重要です。単に “*” と入力してはなりません！そうすると、イグザンプル社の情報システム部門はあなたの接続しようとしたあらゆるサーバに署名できる権限があると、あなたが言っていることになります – たとえ接続先が会社の外のネットワークのどこか別のマシン、例えばあなたの個人サーバでも。つまりその設定は、PuTTY とあなたのサーバの“間に”イグザンプル社の情報システム部門が入り込み、あなたの通信を覗き見ることを可能にします – まさに SSH が防ぐはずだったことです。
そのため、認証局が example.com のシステム管理者なり何なりから示されたならば、PuTTY が確実に example.com ドメインのマシン“のみ”信頼するようにします。
“信頼するホスト / Valid hosts”の書式の完全な文法は、section 4.21.4.1 を参照してください。
最後に、認証局の識別名を決めます。ウインドウ上部の“この認証局に付ける名前 / Name for this CA”テキストボックスに名前を入力して、“保存 / Save”を押すと認証局の設定が記録されます。あなたの決めた識別名がボタン脇の保存された認証局一覧に表示されます。
識別名は何でも構いません。あなたが複数の証明書を保存したときに、後でどれを編集したり削除したりすればいいか分かるようにこの名前があります。また、この名前はサーバがその認証局で署名した証明書を提示した場合に、PuTTY のイベントログにも表示されます。
既存の認証局の設定を読み直す場合は、リストボックスから選択して“読込 / Load”を押します。そして変更したら、もう一度保存を押します。
認証局を設定から完全に削除するには、リストボックスから選択して“削除 / Delete”を押します。
“この鍵の認証を信頼するホスト / Valid hosts this key is trusted to certify”テキストボックスに入力できる最も単純なものはただのホスト名のワイルドカード “*.example.com” です。これはどのサブドメインにも一致するので、“ssh.example.com” と “login.dept.example.com” に一致する一方、“prod.example.net” には一致しません。
しかし複数のホスト名のワイルドカードやポート番号の範囲、それらの複雑な真偽式 (“&&” で “論理積”, “||” で “論理和”, “!” で “否定”) や括弧も入力できます。
例えば、このような入力ができます:
*.foo.example.com || *.bar.example.com”。この場合、認証局が署名するホスト鍵の接続で信頼されるのは、ホスト名が “*.foo.example.com” または “*.bar.example.com” と一致する場合です。言い換えると、認証局は example.com のこれら二つのサブドメインに権限がありますが、他には何にも、例えば www.example.com には権限がありません。
*.example.com && ! *.extrasecure.example.com”。この場合、認証局が署名するホスト鍵の接続で信頼されるのは、ホスト名が “*.example.com” に一致し、しかし“*.extrasecure.example.com”とは一致しない場合です。 (例えばあなたの会社に最高機密を扱うサーバ群があり、通常の情報システム部が取り扱い権限を持たない場合を想像してください。)
*.example.com && port:22”。この場合、認証局が署名するホスト鍵の接続で信頼されるのは、ホスト名が “*.example.com” と一致し、かつポート番号が 22 の場合です。それ以外のポートで運用される SSH サーバは対象になりません。
(*.foo.example.com || *.bar.example.com) && port:1-1023” これは example.com の二つのサブドメインと一致するのは前出の例と同じですが、それに加えてポート番号が 1 以上 1023 以下の範囲に制限しています。
証明書設定の式は一つ以上の個別の要件からなります。この要件とは、ホスト名のワイルドカードか、単一のポート番号かポート番号の範囲か、それらを論理演算子でつないだものとなります。
例えば C のような別のプログラミング言語と異なり、“&&” と “||” との間に暗黙的な優先順位の差はありません。もし “A && B || C” と書いたなら (ここで A, B, C は何らかの要件とします)、 PuTTY は文法エラーとして扱います。なぜなら “&&” と “||” のどちらが優先されるか示していないからです。 “(A && B) || C” として “A かつ B であるか、または単に C”とするか、 “A && (B || C)” として “A であり、かつ B と C のどちらか”、と明確にします。
RSA 鍵はセキュアハッシュ関数を選んで署名を生成できます。証明書に対応している新しい OpenSSH はどのバージョンも十分に新しいので SHA-1 を避けるはずです。そのため、より新しい SHA-256 や SHA-512 を受け付けるデフォルト設定でほぼすべての場合に対応できるはずです。しかし完全性のために、RSA 鍵を使う認証局の証明書で PuTTY が 受け付ける RSA 署名の種類を指定できます。
PuTTY は多様な暗号アルゴリズムに対応していて、そのうちのどれを使うかを選べます。
リスト内のアルゴリズムをドラッグ&ドロップする (または上下ボタンを使う) と優先順位を指定できます。 SSH 接続をするときに PuTTY はサーバが対応しているアルゴリズムを上から順に探して、それを使います。
PuTTY は以下のアルゴリズムに対応しています:
接続時に PuTTY の決めたアルゴリズムが“ここから下は警告する / warn below here”より下の場合、警告ダイアログを表示します:
このサーバでサポートされている最初の暗号は
single-DESで、設定した警告する閾値を
下回っています。
接続を続けますか?
The first cipher supported by the server
is single-DES, which is below the configured
warning threshold.
Do you want to continue with this connection?
これは利用できる最初の暗号があまり安全でないことを警告しています。 “ここから下は警告する / warn below here”の境界はあなたが安全と思うものと水準以下と思うものとの間に置きます。 PuTTY のデフォルトではセキュリティと処理速度を妥当に反映した順序になっています。
SSH-2 では暗号アルゴリズムは接続の上下流で別々に取り決めますが、PuTTY はそれぞれ別に順序を決められません。そのため上記に似た警告が 2 回、異なった暗号名で表示される場合があります。
シングル DES は SSH-2 プロトコル規格では推奨されていませんが、サーバ実装の一つか二つは対応しているものがあります。 “SSH 2 でレガシーな single-DES の使用を有効にする / Enable legacy use of single-DES in SSH-2”を有効にすると、PuTTY はシングル DES を使ってこれらのサーバと通信できます。デフォルトでは無効となっていて、PuTTY は推奨された暗号のみ使おうとします。
SSH-2 サーバはクライアントにメッセージを送り、ユーザかもしれない人物のログイン前にその文章を表示できます。これを認証前の“バナー”と呼ぶことがあります。通常サーバの情報や法律上の表示を提供するのに使います。
デフォルトでは PuTTY はこのメッセージをパスワードや同様の情報を求める前に表示します (残念ながらプロトコル設計によってログイン名を尋ねる前ではありません)。このオプションを無効にするとバナーの表示を完全に抑制できます。
SSH-2 では原理的には SSH のクライアント識別・認証機構を使わなくても接続を確立できます。例えば認証をデータチャンネルで行うか、認証の類をまったく要求しないことも可能です。
PuTTY はデフォルトではサーバが認証を必要するとみなすので (そうでないサーバは聞いたことがありません) 認証のためユーザ名を送信しなくてはなりません。もし答えようのないユーザ名を求められるならば、このオプションを有効にします。しかしほとんどの SSH サーバは名無しを拒否します。
認証すべきユーザ名が存在して PuTTY にそれを記憶させたい場合、このオプションは利用できません。そのような場合は section 4.17.1 を参照してください。パスワード無しで大本の SSH サーバに接続できるようにしたいという場合も、おそらく使うべきではないでしょう。サーバによって、公開鍵認証 (chapter 8) か、GSSAPI 認証 (section 4.25) をすることになります。 (これらの仕組みは対話型ではありませんが、認証の一種です。)
このオプションは SSH-2 接続のみに影響します。 SSH-1 接続は認証が常に必要です。
このオプションは、サーバがいかなる種類のパスワード、署名、トークンも要求しないままに認証を受け付けたときに、SSH セッションを放棄しサーバから切断します。
これはセキュリティーの一手段として使うことができるかもしれません。 SSH クライアントのユーザに対する攻撃の形態として、SSH 認証を早い段階で終了してから認証に見えるけれども実際は違うようなものを SSH セッションの中で行うものが存在します。
例えば、乗っ取られたまたは悪意のあるサーバは、公開鍵の署名を要求して PuTTY が鍵のパスフレーズを尋ねる代わりに、署名やパスワードなしであなたをログインさせて、PuTTY のパスワード要求に似せたメッセージを出して、あなたがパスワードを入力するのを期待します。 (実際には、あなたの秘密鍵のパスフレーズはいかなるサーバにも送ってはなりません。)
PuTTY のこの種の攻撃に対する主な防御は、“信頼性アイコン”システムです: 本当に PuTTY によって生成されたメッセージの前には小さな PuTTY アイコンが付きます。サーバが端末の出力で同じようなメッセージを偽造することはできません。
しかし、それでもこの種の攻撃の危険があると思うならば (アイコンをきちんと確認しないか、サーバに特別に危険があるならば)、このオプションを有効にして更に防御できます。そして、もしサーバが認証を素通しして攻撃しようとするならば、PuTTY はサーバが偽のプロンプトや他の攻撃をする前に、サーバから切断します。
一方で、いくつかのサーバは正当に SSH 認証フェイズを些細なもので完了します。真に公開されているサーバなのか、端末のセッション中で重要な認証手順が発生するかです。 (例として、古いメインフレームのログインプロンプトに直接接続する SSH サーバが挙げられます。) そのため、このオプションを有効にするとある種のセッションが動作しなくなります。
このオプションを有効にすると PuTTY は Pageant (SSH 秘密鍵保管エージェント) を探し、Pageant が持っている公開鍵で認証処理しようとします。
この挙動は通常常に望ましいのでデフォルトで有効になっています。稀にパスワードなど公開鍵以外の手段で強制的に認証させたい場合に無効にします。
オプションは -noagent コマンドラインオプションでも制御できます。 Section 3.11.3.9 を参照してください。
Pageant の概要ついての情報は chapter 9 を参照してください。
TIS / CryptoCard 認証は名前に反して SSH-1 のみで使える単純なチャレンジ&レスポンス認証の一般的な形です。例えば S/Key ワンタイムパスワードを使うときや、認証のチャレンジに対するレスポンスを生成するセキュリティトークンデバイスを使う場合にに必要です。単純なパスワード認証にも使えます。
このオプションを有効にすると PuTTY はサーバがこれらの形式の認証を行える場合にそれを試みます。 (毎回異なる) チャレンジの文字列が表示され、ログインするには正しいレスポンスを返信する必要があります。サーバが対応している場合、システム管理者にどんな形式のチャレンジ&レスポンスなのか正確にたずねる必要があります。
TIS 認証の SSH-2 版を“keyboard-interactive”と呼びます。任意の数のリクエストとレスポンスを使える柔軟な認証方法のため S/Key のようなチャレンジ&レスポンス認証だけでなく、(例えば) パスワードの期限が切れたときにユーザに新しいパスワードを尋ねることができます。
PuTTY はデフォルトでこのオプションを有効にしていますが、問題があった場合のために無効にするオプションを用意しています。
このオプションはエージェント転送で接続した SSH サーバにローカルの Pageant への接続を許可します。 Pageant を実行していなければ何もしません。
Pageant の概要ついての情報は chapter 9 を参照してください。またエージェント転送については section 9.4 を参照してください。このオプションを有効にするとセキュリティ上の危険が生じます。詳細は section 9.6 を参照してください。
SSH-1 プロトコルでは認証に失敗するとユーザ名を修正できませんでした。 PuTTY の“login as:”プロンプトでユーザ名を入力ミスすると PuTTY をリスタートしない限りそれを変えられません。
SSH-2 プロトコルは原則としてユーザ名を変えられますが、SSH-2 サーバが変更を受け付けるようには義務付けていません。特に OpenSSH はユーザ名の変更を認めていないので、一旦ユーザ名を送信すると別のユーザ名での認証を拒否します。 (ログイン失敗になるかエラーメッセージが出るかは OpenSSH のバージョンによります。)
このためサーバがエラーを出さないように PuTTY はデフォルトではユーザ名を何度も尋ねません。もしサーバが許容しているならば、“ユーザ名変更の試みを認める / Allow attempted changes of username”を有効にして PuTTY の振る舞いを変更できます。
この認証パネルのサブパネルは実際にサーバに提示するクレデンシャル (認証情報) を、つまり鍵ファイルと証明書を指定するオプション設定を含みます。
公開鍵認証を行う場合、この入力ボックスに秘密鍵ファイルの名前を入力します。 SSH の公開鍵認証については chapter 8 を参照してください。
鍵は PuTTY のネイティブ形式 (*.PPK) にします。他の形式の秘密鍵を PuTTY で使いたい場合、section 8.2.15 を参照してください。
Pageant を使うと、鍵をここで明示的に設定する必要がなくなります。 Chapter 9 を参照してください。
もし秘密鍵が指定されていて Pageant が実行中ならば、PuTTY は Pageant に対してその鍵で認証するように要求して、他の Pageant が持っているかもしれない鍵を無視させます。もし認証が失敗したら、PuTTY は通常通りパスフレーズを尋ねます。この場合、公開鍵 (RFC 4716 か OpenSSH 形式) を指定することもできます。 Pageant が鍵を識別するのにはそれで十分なためですが、もちろん Pageant が実行中でなければ、PuTTY はその公開鍵での認証はできません。
(この設定は任意です。必要かどうかわからない場合、空欄で構いません。)
ある環境では、ユーザの認証鍵を“認証局” (CA, 証明機関) によって署名するようにして、SSH サーバのユーザカウントは正しい署名で証明される鍵を自動的に信頼するように設定できます。
この構成はサーバが多数存在する場合に便利になりえます。鍵ペアを変更した時、それぞれのサーバ上にある authorized_keys ファイルをいちいち編集して、新しい鍵を受け付けるようにしなくてはなりません。しかしこれらのサーバに、認証局によってあなたのものであると署名された鍵を受け付けるように一度設定してしまえば、公開鍵を変更したとしても以前と同じ認証局で認証させるだけで、サーバすべてが再設定の必要なく自動的にその鍵を受け付けます。
証明書を使う一つの方法は、秘密鍵にそれを組み込むことです。 PuTTYgen でそれを行う方法は section 8.2.9 で解説しています。もう一つの方法は PuTTY に公開鍵の証明書の場所を教えることです。そうすると秘密鍵で認証する際に、その証明書を提示します。
後者の方法は、“秘密鍵と共に使う証明書 / Certificate to use with the private key” 欄に証明書ファイルのパス名を指定すると行えます。
この設定は、秘密鍵がファイルにあっても Pageant に読み込まれていても、有効になります。
SSH サーバは“keyboard-interactive”プロトコルで一連の質問と答えを提示できます。これは普通のパスワードのために使われることもありますが、サーバは同じ仕組みをより複雑な、例えばワンタイムパスワードに使うこともあります。
このような仕組みは自動化できるものがあります。そのために、別個のプログラムを“プラグイン”として動作させ、認証を肩代わりさせて質問に対する答えを送信できます。
あなたがこの種のプラグインを与えられている場合、それをここに指定できます。コマンドラインのすべてを“実行するプラグインコマンド / Plugin command to run”ボックスに入力します。
(もしこの種のプラグインを作成したいならば、appendix H を参照してプラグインに要求されるふるまいの完全な仕様を確認してください。.)
“認証 / Auth”の“GSSAPI”サブパネルは GSSAPI 認証を制御します。これは認証情報交換をクライアントマシンの別の場所に委譲する仕組みです。原則的には様々な方法で認証できますが、通常はパスワードなしでログインするために Kerberos シングルサインオンプロトコルとともに使います。
GSSAPI 認証は SSH-2 プロトコルでのみ利用できます。
PuTTY は 2 つの形の GSSAPI 認証に対応しています。一方では SSH 鍵交換は普通に発生し、GSSAPI はユーザの認証にのみ関わります。 “GSSAPI 認証を試みる / Attempt GSSAPI authentication”というチェックボックスで設定します。
もう一方では GSSAPI 認証は SSH 鍵交換フェイズと同時に行います。これに成功すると、SSH 認証の段階で行うことはありません。この方式についての詳細は section 4.20.1.1 を参照してください。
“GSSAPI 鍵交換を試みる / Attempt GSSAPI key exchange”というチェックボックスで設定します。 (“鍵交換 / Kex”パネルにも同じチェックボックスが表示されます。)
どちらか、もしくは両方が有効の場合、どちらかで GSSAPI 認証を試みるので、(一般に) クライアントマシンに有効な Kerberos クレデンシャル (認証情報) が読み込まれていれば PuTTY は Kerberos ログインに対応したサーバで自動的に認証できます。
両方を無効にした場合、PuTTY はどちらの GSSAPI も試みません。そしてこのパネルの残りの設定は使われません。
GSSAPI クレデンシャル委譲は Kerberos (や他の) アイデンティティを SSH サーバのセッションに渡す仕組みです。このオプションを有効にすると PuTTY は Kerberos クレデンシャルを受け付けるサーバに自動的にログインできるだけでなく、そこから他のサーバの Kerberos に対応したサービスにも自動的に接続できるようになります。
(このオプションは SSH エージェント転送の Kerberos 版です。それについての詳しい情報は section 9.4 を参照してください。)
SSH エージェント転送のように、このオプションの利用はセキュリティに影響があります。接続先サーバの管理者やサーバ管理者のアカウントに侵入したユーザはあなたと偽ってそれ以降の Kerberos 対応のサービスに接続できます。しかし通常 Kerberos サイトは中央オーソリティによって実行されるので一つのサーバの管理者はすでに他のサービスにもアクセスできます。そのため SSH エージェント転送に比べて危険は一般に低いはずです。
接続が GSSAPI 鍵交換を使っていない場合、セッションの途中で委譲が失効する可能性があります。詳しい情報は section 4.20.1.1 を参照してください。
GSSAPI は複数の認証方式を同じインターフェイスで利用するための仕組みです。そのため GSSAPI でアクセスできる認証ライブラリが二つ以上システムにあるかもしれません。
PuTTY は Windows の SSPI を含め、いくつかのよく知られたライブラリに対応しています。そしてシステムにそれらがあるか調べ、見つかったものを使います。もし複数がシステムにあって特定のものを使いたいならば、検索する順序をこの一覧で調整できます。
一覧の一つのオプションとしてユーザ指定の GSSAPI ライブラリを使うものがあります。 PuTTY の一覧に使いたいライブラリの名前がない場合は、そのフルパスを“ユーザ設定の GSSAPI ライブラリのパス / User-supplied GSSAPI library path”に入力して“ユーザ設定の GSSAPI DLL / User-supplied GSSAPI library”オプションを一番上に動かします。
Windows ではそのようなライブラリは拡張子 .dll のファイルで、 PuTTY と同じようにビルドされている必要があります。 32-bit DLL の場合は 32-bit 版の PuTTY で、64-bit の場合は 64-bit です (question A.6.10 参照)。 Unix では一般に共有ライブラリの拡張子は .so です。
TTY パネルでリモート擬似端末を設定します。
Unix システムに接続する際、ほとんどの対話型シェルセッションは擬似端末上で実行されます。 Unix システムに実際の物理端末デバイスと通信していると見せかけ、SSH サーバが捕捉した偽デバイスへのデータをすべてクライアントに送ります。
たまに擬似端末上ではないセッションが必要なことがあります。 PuTTY では通常特別な専門家以外役に立ちませんが、これが Plink (Chapter 7 参照) では通常の動作方法です。
SSH プロトコルはクライアントからリモートの擬似端末に“端末モード”を送信できます。通常これでサーバが期待するローカル端末の振る舞いを制御します。
モードの適切なデフォルト値をサーバが持っていないならば、モードの変更が役立つかもしれませんが、サーバがそれを無視するのは自由です。理解できないならば、変更しないのが安全です。
(設定は擬似端末を要求したり割り当てられたりしていない場合には効果がありません。)
特定のモードをどうするかを一覧から選択できます。オプションを一つ選び、必要なら値を選択し、“設定 / Set”を押します。オプションの効果は次の通りです:
PuTTY に設定が内蔵してあるモードでだけ送ります (現状ではバックスペースキーのコード ERASE と、文字エンコーディングが UTF-8 かどうかの IUTF8 です)。 Unix の Plink はローカル端末のモードがあればそれを伝えます。
デフォルトでは利用できるモードのすべてが“自動 / Auto”となっていて、ほとんどの状況で正しい動作を行います。
それぞれの設定の正確な効果は、それがあるとしてもサーバ次第です。モードの名前は POSIX や他の Unix システムに由来していて、それらのシステムでは有効な効果があるはずです。 (それらのサーバでは通常ログインした後の stty コマンドでも変更できます。)
いくつかの有名なモードを以下で説明します。より詳しい説明はサーバのドキュメントを参照してください。
ERASE はユーザが入力したときに左の 1 文字を削除する文字です。 “自動 / Auto” (デフォルト設定) にすると、PuTTY の Backspace キーの設定に従います (section 4.4.1 参照)。
これや他の特殊文字は Ctrl-C ならば ^C のような記法で指定します。数値で指定するには ^<27> や ^<0x1B> とし、^ という文字は ^~ で表します。他の非制御文字は直接記述します。入力ボックスを空にすると、その機能に何も文字を割り当てませんが、すべてのサーバがそれに対応するわけではありません。
QUIT は通常サーバ上の現在のプロセスを強制終了 (SIGQUIT) する特殊文字です。多くのサーバではデフォルト設定で Ctrl-backslash (^\) で、多くのキーボードで間違って入力しやすいものです。もしこれが厄介ならば、別の文字にするか無効にできます。
ECHO や ICANON のような真偽値のモードは PuTTY ではいろいろな形で指定できます。 true/false, yes/no, 0/1 が使用できます。 (明示的に no を指定するのはモードを送信しない場合とまったく異なります。)
IUTF8 は真偽値のモードで、端末のエンコーディングが UTF-8 かどうかをサーバに通知します。基本的な行編集のためなどに利用されます。これを誤って設定すると、例えばバックスペースキーが間違った量の文字を消すかもしれません。しかし、端末が UTF-8 モードだとサーバに思わせるには、単にこれを設定するだけでは通常十分ではありません。 POSIX サーバは一般に ロケール(locale) の設定が必要 (方法はサーバに依存します) ですが、多くの環境でデフォルトは UTF-8 です。また、 多くのサーバ (特に古いもの) では SSH で送られるこのモードに従いません。実際、いくつかの未熟な実装のサーバはモードが存在するだけでエラーを起こすため、送信しないように設定しなければならない場合もあるかもしれません。 “自動 / Auto”にすると、設定された文字セットになります (section 4.10.1 を参照)。
訳注: ロケールが同じ UTF-8 でも言語によって幅の曖昧な文字の扱いが異なることがあります。Section 4.10.1 を参照してください。
X11 パネルで SSH 接続の X11 転送 を設定します。
もしサーバが X Window システムのグラフィカルアプリケーションを実行できるなら、X11 転送でローカル PC の X ディスプレイに安全にアクセスを許可できます。
X11 転送を有効にするには“X11 転送を有効にする / Enable X11 forwarding”をチェックします。 X ディスプレイが通常と異なる場所の場合、その場所を“X ディスプレイの場所 / X display location”に入力します。空欄の場合、PuTTY はその環境の適切なデフォルト値を使おうとし、失敗した場合はプライマリローカルディスプレイ (:0) を使います。
X11 転送についての詳しい情報は section 3.4 を参照してください。
X11 転送をする場合、SSH サーバマシンに作られる仮想 X サーバは認可データで保護されます。このデータは PuTTY が作成し確認します。
通常使う認可方式は MIT-MAGIC-COOKIE-1 と呼ばれるものです。これは単純なパスワード形式のプロトコルです。 X クライアントがクッキーデータをサーバに送信し、サーバが実際のクッキーと一致するか確認します。クッキーデータは平文の X11 接続を通して送られるので、第三のマシンに仮想 X サーバへのアクセスを与えると、送信するクッキーが見えます。
PuTTY では別のプロトコル XDM-AUTHORIZATION-1 も使えます。これは暗号学的に認証するプロトコルです。 X クライアントが送信するデータは毎回異なり、クライアント側の IP アドレスとポート番号に依存し、現在時刻を刻印します。そのため XDM-AUTHORIZATION-1 を盗聴しても別の X 接続では使えません。
PuTTY の XDM-AUTHORIZATION-1 対応はいくらか実験的な機能でいくつかの問題が発生するかもしれません:
XDM-AUTHORIZATION-1 に対応していません。そのため PuTTY が送信したデータを扱えません。
XDM-AUTHORIZATION-1 データを検証できません。
XDM-AUTHORIZATION-1 データを解放しないので、同じサーバに MIT-MAGIC-COOKIE-1 のみに対応したクライアントで接続し同じリモートディスプレイ番号が割り当てられると、古い認証データがサーバにまだ存在するため X 接続が失敗します。
PuTTY のデフォルトは MIT-MAGIC-COOKIE-1 です。何が起こるか理解したうえで変更してください。
X11 転送を行う場合、転送した接続が最終的に行き着くローカルの X サーバ自体が認可を必要とする場合があります。
一部の Windows の X サーバは必要ありません。例えばローカルマシンからの接続だけすべて受け付けるなどの単純な認可を行います。しかしもし X サーバが認可を必要とするなら、PuTTY はどんな認可が必要か知る必要があります。
このデータを X サーバが供給する一つの方法が、Unix の .Xauthority と同じ形式のファイルに保存することです。もし X サーバがこの方法を取っているなら、この設定オプションで PuTTY にこのファイルの場所を教えます。デフォルトでは PuTTY はローカルディスプレイのための認可ファイルを探しません。
トンネルパネルで 好きな接続を SSH 接続の中をトンネルするように設定できます。
ポート転送で SSH セッションの中に他の種類のネットワーク接続を通せます。ポート転送に関する一般的な情報や仕組みは section 3.5 を参照してください。
一覧部分にサーバ接続時に PuTTY が設定するポート転送の一覧が表示されます。デフォルトではポート転送しないため、空欄です。
ポート転送を追加するには:
popserver.example.com:110 のように入力します。 (IPv6 アドレスを入力する場合、角括弧で囲みます。例えば “[::1]:2200” です。)
ポート転送を削除するには、一覧から設定を選んで“削除 / Remove”をクリックします。
“受け側ポート / Source port”にはオプションで IP アドレスも入力できます。例えば 127.0.0.5:79 のようになります。この仕組みと制限についての情報は section 3.5 を参照してください。
サービス名をローカルシステムが知っている場合、ポート番号の代わりに入力できます。例えば、“送り先 / Destination”に popserver.example.com:pop3 と入力できます。
“設定の変更 / Change Settings”でセッション中に動作中のポート転送の設定を変更できます。ローカルまたはダイナミックのポート転送を削除した場合、PuTTY はそのポートの待ち受けを停止するので他のプログラムでは使用できなくなります。リモートポート転送を削除する場合は:
リモートポート転送を削除して、PuTTY が実際にサーバの待ち受けを止められない場合、代わりにそのポートからの接続を拒否します。そのためそのポートの再利用はできませんが、少なくともサーバ側のプログラムがローカルのサービスにポート転送でアクセスできないことは確かです。
転送を削除した場合、その転送で確立した既存の接続はそのままになります。同様に、“ローカルポートは他のホストからの接続を受け入れる / Local ports accept connections from other hosts”の変更も以降の新たな接続のみに有効になります。
SSH で転送する接続自体が別の PuTTY による別の SSH 接続の場合、“論理ホスト名 / logical host name”設定オプションを使うと PuTTY に想定するホスト鍵を知らせられるので便利です。詳細は section 4.16.5 を参照してください。
転送した接続の受け側は通常SSH クライアントやサーバマシンそれ自体 (それぞれローカルとリモートの転送) 以外からの接続は受け付けません。トンネルパネルでそれを変更できます。
このスイッチでローカル側の転送ポートのインターネットプロトコル (IPv4 か IPv6) を選択できます。デフォルトでは“自動 / Auto”に設定されているので:
この設定は接続パネルのインターネットプロトコルバージョンより優先します (Section 4.16.4 を参照)。
ある OS では IPv6 を選択しても IPv4 の接続を待ち受けます。これは IPv4 と IPv6 のプロトコルスタックが関連しているからです。 Linux がその例で、Windows は違います。そのため PuTTY を Windows で実行してローカルやダイナミックポート転送で“IPv6”を選ぶと IPv6 でしか接続できませんが、Linux で同じことをすると IPv4 でも使えます。しかし、“自動 / Auto”ではどちらのプロトコルでも接続できる設定になります。
すべての SSH サーバが正しく動作するわけではありません。既存の様々なサーバにはバグがあり、クライアントがそれを知って回避しないと通信は不可能です。
ほとんどのサーバは SSH 接続の始めにソフトウェアのバージョンを通知するので、PuTTY はサーバにどのようなバグがあるかを検出して回避策を有効にします。しかしたまに間違えることがあります。サーバが故意にバージョン番号を隠しているか、PuTTY のバグデータベースにないバージョンの場合です。そうすると PuTTY はどんなバグがあるのか判りません。
バグパネルでサーバにあるバグを手動で設定できます。(パネルが二つあるのはバグ互換モードが増えすぎたためです。) それぞれのバグは 3 つの状態に設定できます。
(PuTTY プロジェクトはバグの回避策として自動検出処理を追加するのに必要な要件を定めています。 section B.6 を参照してください。)
SSH プロトコルの ignore メッセージ (SSH_MSG_IGNORE) はクライアントとサーバの両方がいつでも送れるものです。どちらの側も受け取ったメッセージは常に無視します。 PuTTY は ignore メッセージを使って SSH-2 の暗号化したデータストリームをかく乱し、暗号解析を難しくします。また ignore メッセージを接続の keepalive (section 4.16.1 参照) にも使います。
サーバにバグがあると思われる場合は、PuTTY は ignore メッセージを使いません。正常なサーバにこのバグを有効にして接続すると、セッションは確立しますが keepalive は動作しませんし、セッションは本来よりも暗号学的に安全でなくなります。
ある SSH サーバは鍵交換の再実行をまったく処理できず、クライアントの要求を無視します。 PuTTY は鍵交換の再実行中はセッションを停止するので、これによってセッションは一時間経過すると (鍵交換のタイムアウト設定を変更しない限りは。Section 4.20.2 参照。) ハングします。他の非常に古い SSH サーバは鍵交換の再実行をより悪い方法で処理し、要求を受信すると接続を切断します。
このバグを検出した場合、PuTTY は鍵交換の再実行をまったく行いません。正常なサーバにこのバグを有効にして接続すると、セッションは確立しますが、本来より安全でなくなります。
これは SSH-2 固有のバグです。
adjust” 要求で停止 / Chokes on PuTTY's SSH-2 “winadj” requests”
PuTTY は時々データチャンネルの途中で winadj@putty.projects.tartarus.org という名前で特別な要求を SSH サーバに送ります (section G.1 参照)。この要求の目的はサーバとの往復時間の計測で、それを元に PuTTY がフロー制御を調整します。サーバはメッセージを理解する必要はありません。 SSH_MSG_CHANNEL_FAILURE メッセージでそれを理解できなかったと示すのを期待しているからです。 (PuTTY としては単に何か返事があれば時間を計れます。)
いくつかの SSH サーバはこのメッセージに混乱します。長い名前だからとか、認識できない要求に正しい失敗の応答さえも返せないとか、適切に対処してサーバのログファイルが無意味な spam で埋まってしまったためとかです。そこで PuTTY はこのバグ互換フラグに対応しています。サーバにバグがあると思われる場合は、“winadj@putty.projects.tartarus.org” 要求を送りません。タイミングデータなしで間に合わせます。
RFC 4254 として発行した SSH プロトコルには、接続の一方がチャンネルを閉じようとして、反対が同時に応答が必要な要求を送った場合に曖昧さがありました。 RFC 4254 は閉じようとした側が意図を通知した後で応答するべきかどうかを明確にしませんでした。
ietf-ssh メーリングリストの 2014 年 4 月の議論では No として明確に合意しました。しかし仕様が曖昧なため、ある SSH サーバは他の方針で実装されています。例えば OpenSSH は修正されるまでそうなっていました。
PuTTY はチャンネル要求を終始“要応答”フラグを立てて送信するので (section 4.29.3 参照)、そのようなサーバに接続するとチャンネルを完全に閉じたと思った後で要求の応答を受ける可能性があり、“Received SSH2_MSG_CHANNEL_FAILURE for nonexistent channel 256”というエラーで停止する場合があります。
SSH-2 チャンネルが確立すると双方がデータパケットで受け取りたい最大サイズを通知します。あるサーバは PuTTY の通知を無視して PuTTY が受け取りたいものより大きなパケットを送信するため“Incoming packet was garbled on decryption”というメッセージが表示されます。
このバグを検出した場合、PuTTY はチャンネルのフロー制御ウインドウを増大させないようにし、サーバが大きすぎるパケットを送信できなくします。正常なサーバにこのバグを有効にして接続すると、セッションは確立しますがダウンロード効率が本来よりも低下します。
時たま、何かのチャンネル上に確立された SSH 接続が、接続の初期に誤って出力データを捨ててしまうことがあり得ます。
実際の SSH サーバのバグとしては通常見られませんが、複雑なプロキシ処理が絡む場合に時たま起こります。一例として Debian bug #991958 では、ユーザモード Linux カーネル上の接続で、カーネルが完全に起動する前に出力データを失ってしまうことがあります。
この問題は手動でバグ設定を有効にすれば回避できます。 PuTTY は SSH の最初の greeting 送信をサーバの greeting を受け取るまで遅らせます。
このバグフラグは自動検出できません。何故なら自動検出はサーバの greeting に含まれるバージョン文字列に依存している一方、PuTTY はこのバグへの対応をサーバの greeting を受け取る前に行う必要があるからです。そのため手動設定のみとなっています。
KEXINIT で停止 / Chokes on PuTTY's full KEXINIT”
SSH 接続を開始すると、クライアントとサーバは SSH_MSG_KEXINIT という種類の長いメッセージを交換します。これにはそれぞれが使用できる暗号アルゴリズムすべての一覧が含まれます。これを使って双方が使用できるアルゴリズムセットを取り決めます。
時たま、実装の拙いサーバが受信できる一覧の長さに制限を設けており、PuTTY が多すぎる選択肢を示すことで接続を拒否することがあります。
回避策としてこのフラグを有効にすると、PuTTY は KEXINIT の送信をサーバからの受信を待って行います。そうしてから KEXINIT の内容をフィルタしてサーバが対応しないものを取り除きます。そうすると大抵の場合、PuTTY の KEXINIT はサーバと同じくらいの長さになって、そしてアルゴリズム決定にも違いが生まれません。
このフラグは SSH プロトコルに少し違反します。なぜなら KEXINIT はどちら側も相手を待たずに送信することになっているからです。ですがどちらか一方が KEXINIT を相手を待たずに送信する限りは動作します。しかしクライアントとサーバの両方が相手の送信を待つと、接続がデッドロックすることになります。サーバでこの動作を行うものは知りませんが、もしあるならばこのフラグによって PuTTY はそのサーバに対して動作しなくなります。
PuTTY が RSA 鍵で SSH-2 ユーザ認証を行い、サーバが SSH RSA プロトコルの SHA-2 を元にした新しいバージョンの一つを使う場合で、ユーザの鍵が証明書でもある場合、OpenSSH の過去のバージョン (7.7 まで) は以降のバージョンと異なったアルゴリズム文字列を SSH2_MSG_USERAUTH_REQUEST パケットで送ります。新しいバージョンの文字列では鍵に SHA-2 の特徴と証明書の特徴の両方がある事を示す、例えば “rsa-sha2-512-cert-v01@openssh.com” のような文字列を送ります。以前のバージョンではそれを受け付けず、例えば “ssh-rsa-cert-v01@openssh.com” のようなものと、続けて SHA-2 の署名を期待します。
PuTTY は以前の OpenSSH にあるこのバグを自動的に検知し、送信文字列を調整します。
OpenSSH のバージョン 3.3 未満では SSH-2 RSA 署名に RSA 鍵のモジュラスと同じ長さの NUL パディングが必要です。 SSH-2 の仕様はパディングしていない署名を受け付けなければならない (MUST) としているので、これはバグです。典型的なこの問題の症状として、PuTTY は数百回に一回 RSA 認証に失敗してパスワード認証を要求します。
このバグを検出した場合、PuTTY は OpenSSH の期待する方法で署名にパディングを挿入します。正常なサーバにこのバグを有効にして接続しても、何も問題は起きないはずです。 OpenSSH と通信していた正常なサーバはパディングした署名も受け付けるはずです。
これは SSH-2 固有のバグです。
Diffie-Hellman 鍵合意を使った SSH 鍵交換方式は最初のリリースの後に変更され、少し洗練された設定メッセージになりました。ほとんどすべての SSH 実装が新しいバージョンに切り替わりました。 (PuTTY は遅れた方でした。) いくつかの古いサーバは古い方式のみ対応しています。
このバグを検出した場合でクライアントとサーバが Diffie-Hellman 鍵合意でネゴシエーションした場合、PuTTY は現在 SSH2_MSG_KEX_DH_GEX_REQUEST_OLD として知られる古いメッセージを新しい SSH2_MSG_KEX_DH_GEX_REQUEST の代わりに送信します。
これは SSH-2 固有のバグです。
ssh.com の SSH サーバソフトウェアのバージョン 2.3.0 とそれ以下はホスト鍵の HMAC メッセージ認証コードを間違って計算します。この問題の典型的な症状として、PuTTY はセッションの初めで“Incorrect MAC received on packet”エラーで停止します。
このバグを検出した場合、PuTTY は HMAC をバグありサーバと同じ方法で計算するので通信が可能になります。正常なサーバにこのバグを有効にして接続すると、セッションは確立しますが、通信に失敗します。
これは SSH-2 固有のバグです。
OpenSSH のバージョン 2.3 未満は SSH-2 公開鍵認証を少し違った方法で行います。クライアントが署名するデータに異なった形式のセッション ID が含まれているのです。公開鍵認証がなぜか機能せず、イベントログ (section 3.1.3.1 参照) では署名の送信に成功している場合、このバグ回避を行って改善するか確認します。
このバグを検出した場合、PuTTY は OpenSSH の期待する方法でデータに署名します。正常なサーバにこのバグを有効にして接続すると、SSH-2 公開鍵認証に失敗します。
これは SSH-2 固有のバグです。
ssh.com の SSH サーバソフトウェアのバージョン 2.0.11 未満はセッション暗号の鍵を間違って計算します。この問題は様々なエラーメッセージを出します。 “Incoming packet was garbled on decryption”や、可能性として“Out of memory”もあります。
このバグを検出した場合、PuTTY はバグありサーバと同じ方法で暗号鍵を算出するので通信が可能になります。正常なサーバにこのバグを有効にして接続すると、通信に失敗します。
これは SSH-2 固有のバグです。
SSH プロトコルの ignore メッセージ (SSH_MSG_IGNORE) はクライアントとサーバの両方がいつでも送れるものです。どちらの側も受け取ったメッセージは常に無視します。 PuTTY は ignore メッセージを使って SSH-1 のパスワードパケットを偽装し、傍受側がユーザパスワードの長さをわからないようにします。また ignore メッセージを接続の keepalive (section 4.16.1 参照) にも使います。
バグを検出した場合、PuTTY は ignore メッセージの利用を止めます。つまり keepalive は動作しませんし、PuTTY は SSH-1 のパスワード長盗聴に対して別の手段をとります。 Section 4.29.15 を参照してください。正常なサーバにこのバグを有効にして接続すると、セッションは確立しますが keepalive は動作せず、盗聴に対しては本来よりも脆弱になります。
ignore メッセージを処理できない SSH-1 サーバに接続するとき (section 4.29.14 参照) PuTTY はユーザパスワードの長さを隠蔽するためにパスワードパケット自体にパディングを追加します。これは技術的には SSH-1 仕様に反しているので、PuTTY は偽装に標準準拠の ignore メッセージが使えない場合にのみ行います。つまりパディングしたパスワードパケットを拒否するサーバの実装はバグではありませんが、同時に ignore メッセージを扱えない場合、不都合です。
この“バグ”を検出すると、PuTTY は ignore メッセージもパディングも受け付けないとして、ユーザパスワードを偽装なしで送信するしかありません。そのため盗聴者はパスワードの正しい長さを簡単に知れます。正常なサーバにこのバグを有効にして接続すると、セッションは確立しますが盗聴に対しては本来よりも脆弱になります。
これは SSH-1 固有のバグです。 SSH-2 はこの種の攻撃に対して安全です。
一部の SSH-1 サーバは RSA 認証メッセージをまったく処理できません。もし Pageant を実行中で SSH-1 の鍵がある場合、PuTTY は通常パスワードを試す前に RSA 認証を自動的に試みます。そしてそれらのサーバは RSA 鍵を見る前にクラッシュします。
このバグを検出した場合、PuTTY はすぐにパスワード認証に移行します。正常なサーバにこのバグを有効にして接続すると、セッションは確立しますがもちろん RSA 認証は不可能です。
これは SSH-1 固有のバグです。
ssh-connection” プロトコル
SSH 自体に加えて、PuTTY は SSH から抽出された別のプロトコルにも対応しています。 “Bare ssh-connection”という名前で接続の種類の GUI に示されています。
このプロトコルは SSH-2 の 3 つのレイヤーの内の最も内側を構成しています。ネットワークセキュリティを提供する暗号化レイヤーを外し、あなたがユーザ名を示す認証レイヤーを外したあとの部分です。
そのため全くネットワーク接続には適当ではありません。ネットワーク越しに使おうとしないでください!
このプロトコルは様々な専門的状況のためで、“接続”が実際のネットワークではなくパイプや IPC チャンネルによる同じコンピュータの別プロセスへ繋がっている場合のためにあります。これらの場合では、OS は両方のプロセスが期待通りのユーザによって所有されていることを保証し (そのため認証が不要で)、そして同じマシンの望ましくないユーザが通信を盗み見ることができない (そのため暗号化も不要な) ことが保証されています。考えられる利用例としては、コンテナや VM、異なるネットワーク名前空間のような厳格に分離されたコンテキスト間での通信があります。
このプロトコルに明確に対応したのは PuTTY 0.75 です。 2021 年 4 月時点では、bare ssh-connection プロトコルに対応している唯一のサーバは Unix プログラムの “psusan” で、PuTTY ツールの一部です。
(しかしながら、このプロトコルは PuTTY 同士で接続の共有を行うときに使われるものと同じです: section 4.19.5 を参照してください。実際、Unix 版の PuTTY で共有の上流がイベントログに“Sharing this connection at [pathname]”と記録した際に、別の PuTTY を使って“Bare ssh-connection”のホスト名としてその Unix ソケットのパス名 [pathname] を指定すると、直接接続できます！)
SSH パネルにある多くのオプションはこのプロトコルにも影響を与えますが、暗号化と認証に関するものは、当然ながら関係しません。
繰り返しますが、このプロトコルをネットワーク接続で使わないでください! このプロトコルはネットワークのためにはありませんし、ネットワーク上で全く安全ではありません。
Serial パネルでローカルシリアルポートの接続のみに適用されるオプションを設定できます。
コンピュータに複数のシリアルポートがある場合、“接続先のシリアルポート / Serial line to connect to”で PuTTY が通信するシリアルポートを選択します。
Windows では最初のシリアルポートを COM1 と呼び、他にある場合 COM2 などと呼びます。
この設定はセッションパネルにもあり、接続タイプを“Serial”にすると“ホスト名 / Host Name”の代わりに表示されます (section 4.1.1 参照)。
“通信速度 / Speed”でシリアルポートの速度 (ボーレート) を選択します。通常 9600, 19200, 38400, 57600 です。このどれかはケーブルの先のデバイスによって異なるので不明な場合はデバイスのマニュアルに当たります。
この設定はセッションパネルにもあり、接続タイプを“Serial”にすると“ポート / Port”の代わりに表示されます (section 4.1.1 参照)。
“データ長 / Data bits”でバイトごとに何ビットシリアルポートに送受信するかを選択します。通常 7 か 8 です。
“ストップビット / Stop bits”でシリアルプロトコルでストップビットがいくつあるかを選択します。通常 1, 1.5, 2 です。
“パリティ / Parity”でどのようなパリティチェックを使うかを選択します。設定は:
“フロー制御 / Flow control”でどのようなフロー制御チェックを行うかを選択します。設定は:
Telnet パネルで Telnet セッションだけに適用されるオプションを設定します。
本来の Telnet の環境変数を渡す仕組みは間違って仕様化されました。標準仕様 (RFC 1408) が策定されたとき、BSD の Telnet 実装はすでにこの機能に対応していました。標準化の目的は BSD 実装が行っている挙動の記述でした。
残念ながら標準が発行されたとき誤植があり、2 つの重要な機能を逆に示してしまいました。 BSD の実装は変わらず、RFC は訂正されませんでした。そのため実装が BSD と RFC 準拠の 2 種類存在します。このスイッチで PuTTY をどちらにするか選びます。
この問題は次の標準 NEW_ENVIRON を策定して解決しました。元の OLD_ENVIRON と同じ仕組みですが、既存の実装に縛られません。ほとんどの Telnet サーバはこれに対応していて曖昧さがありません。切り替え機能は、非常に古いサーバに環境変数を渡して問題が出る場合以外、必要ないはずです。
Telnet 接続にはクライアントとサーバの間を流れるデータが 2 種類あります。実際のテキストと、Telnet のどの追加機能を使うかのネゴシエーションです。
PuTTY のネゴシエーションは 2 種類の方針から選べます:
パッシブモードの明らかな欠点は、サーバもパッシブモードだった場合にネゴシエーションが行われないことです。このため PuTTY のデフォルトはアクティブモードです。
しかし、ある種のファイアウォールやTelnet プロキシサーバを越えるのにパッシブモードが必要なことがあります。もしファイアウォールでややこしい問題があるなら、パッシブモードにして効果があるか試してみます。
有効にすると、いくつかのキーシーケンスの処理が変わります:
この機能は動作を理解して必要な場合以外は有効にするべきではないでしょう。
他の多くのリモートログインプロトコルと違い、Telnet プロトコルは通常の Control-M や Control-J による改行ではない特別な“改行”コードを持ちます。デフォルトでは Enter を押すと、他の多くのプロトコルで送られる Control-M ではなく Telnet New Line コードを送信します。
ほとんどの Unix スタイルの Telnet サーバは Telnet New Line でも Control-M でも気にしませんが、あるサーバは New Line や ^M どちらかを要求します。もし Telnet セッションで Enter を押すと意外なことが起きるなら、このオプションを切り替えてみてください。
Rlogin パネルで Rlogin セッションのみに適用されるオプションを設定できます。
Rlogin は自動ログイン (パスワードなし) をサーバの .rhosts ファイルで可能にします。 .rhosts ファイルに jbloggs@pc1.example.com のように書いておき、ログインするとクライアントがユーザ名を送ります。サーバがユーザ名とホストを .rhosts と比べて、一致したらパスワードを尋ねません。
これは Unix システムが Rlogin 接続でユーザ名を偽れないようにする対策を持っているため可能になります。 Rlogin 接続は 1024 未満のポートで接続する必要があり、非特権プロセスはこのポートを使えません。そのためサーバが少ない数字のポートから接続を受けたら、クライアントの接続は特権を持つ (信頼された) プロセスによるものなので、ユーザ名の申告を信用します。
Windows にはこの制限がありません。誰でも少ないポート番号で接続を開けます。よって Rlogin の .rhosts 機構は Windows マシンのユーザを区別するためのセキュリティとしては役立ちません。もし Windows PC の .rhosts エントリがある場合は、その PC の誰もが Rlogin 接続であなたの名前を偽って、サーバのあなたのアカウントにアクセスできると考えるべきです。
PuTTY の名乗るべきユーザ名が Windows ユーザ名 と一致しない場合は (ユーザ名を設定していない場合も) “ローカルユーザ名 / Local username”に指定できます。
SUPDUP パネルは SUPDUP セッションのみに適用されるオプションを設定できます。 SUPDUP プロトコルについては section 3.10 を参照してください。
SUPDUP ではクライアントは、ユーザの位置として短い好きなテキストをサーバに送信します。これは通常ログインユーザの一覧に表示されます。
デフォルトでは PuTTY は単に"The Internet"とします。もしあなたがより明確な場所を表示したいならば、ここで設定できます。
端末が対応している文字セット拡張の種類を設定します。サーバが対応している場合、サーバはその文字セットでテキストを送信します。 “なし / None”は 95 種類の表示可能な ASCII 文字です。 “ITS” は ASCII と制御文字領域を表示可能文字として拡張したもの (Stanford/ITS) です。この文字セットは SUPDUP プロトコル定義で解説されています。 “WAITS” は “ITS” に似ていますが、拡張部分のいくつかが別の文字になっています。最も目立つものとして、^ _ の代わりに ↑ ← が、~ の代わりに } が割り当てられます。 “ITS” 拡張 ASCII は ITS と Lisp マシンで使われる一方、“WAITS” はスタンフォード人工知能研究所による WAITS OS でのみ使われます。
**MORE** 処理を有効にすると、サーバは画面の下端に出力が達した時にスペースを押すまで出力を停止します。
カーソルが最後の行より下に行ったときに、端末がスクロールするか、それとも最初の行に戻るかを制御します。
[Custom] 設定を ini ファイルに保存する方法があります。 section 2.1.2 を参照してください。
今のところ PuTTY は設定をレジストリの代わりにファイルに保存できません。しかしバッチファイルでこれに対処できます。
(例えば) PUTTY.BAT という、ファイルの内容をレジストリに取り込んで PuTTY を実行し、レジストリの内容をファイルに書き出してからレジストリを削除するファイルが必要です。これはレジストリエディター (regedit) のコマンドラインオプションで実現できるのですべて自動です。 PUTTY.BAT はこのようにします:
@ECHO OFF
regedit /s putty.reg
regedit /s puttyrnd.reg
start /w putty.exe
regedit /ea new.reg HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
copy new.reg putty.reg
del new.reg
regedit /s puttydel.reg
このバッチファイルには二つの付属ファイルが必要です。 PUTTYRND.REG は乱数シードファイル PUTTY.RND を安全な場所に設定し、レジストリをファイルに保存した後で PUTTYDEL.REG はレジストリを削除します。
PUTTYDEL.REG は:
REGEDIT4
[-HKEY_CURRENT_USER\Software\SimonTatham\PuTTY]
PUTTYRND.REG は例えば:
REGEDIT4
[HKEY_CURRENT_USER\Software\SimonTatham\PuTTY]
"RandSeedFile"="a:\\putty.rnd"
a:\putty.rnd を乱数データを保存する場所で置き換えます。 PuTTY と設定を USB フラッシュメモリに入れて運ぶためならば、おそらく USB メモリ上でしょう。
このマニュアルや PuTTY のツールに意見がある場合は、 Feedback page を参照してください。
翻訳についてはフィードバックから送信できます。
©1997-2025 Simon Tatham ©2015-2025 SATO Kentaro
[PuTTY custom build 0.83.ranvis-doc]