ssh.com SSH-2 の秘密鍵の読み込みに対応していますかcat するとコマンドラインに“PuTTYPuTTYPuTTY”と出ますcat するとウインドウタイトルが変な文字列になりますscreen.127.0.0.2.C:\WINDOWS\SYSTEM32 に置くと“セッションの複製 / Duplicate Session”が動作しませんputty.org があなた方のウェブサイトですか?the.earth.li and not chiark? Has your website been hacked?sha1sums / sha256sums / etc files on your download page don't match the binaries.この FAQ は PuTTY のサイトに掲載しています。また付録としてマニュアルにも添付してあります。
PuTTY は SSH, Telnet, Rlogin, SUPDUP ネットワークプロトコルに対応した クライアントプログラムです。
これらのプロトコルはネットワーク越しにリモートセッションを張るために使うものです。PuTTY はセッションのクライアント側の処理を実装しています。つまりセッションを実行する側ではなく表示する側です。
単純な言葉で言うと: PuTTY を Windows マシンで動作させて、(例えば) Unix マシンに接続できます。 PuTTY が表示するウインドウに入力したものが Unix マシンに送信されて Unix マシンの応答はすべてウインドウに表示されます。つまり別の場所にいながら Unix マシンのコンソールの前にいるように仕事ができるのです。
一般に、PuTTY が特定の機能に対応しているかは PuTTY のウェブサイトで確認できます。特に:
はい。 PuTTY バージョン 0.50 (2000 年) から SSH-2 に対応しています。
SSH-2 の公開鍵認証 (RSA と DSA) は バージョン 0.52 (2002 年) で追加されました。
ssh.com SSH-2 の秘密鍵の読み込みに対応していますか
PuTTY はこれらにネイティブ対応していません (理由については ウィッシュリストのエントリを参照してください) 0.53 から、PuTTYgen が OpenSSH と ssh.com の秘密鍵を PuTTY の形式に変更できます。
はい。PuTTY は最初から SSH-1 に対応していました。
ただ、SSH-1 プロトコルは多くの脆弱性があり、もはや安全でないと考えられているため、可能な限り SSH-2 を利用するべきです。
0.68 以降、PuTTY はサーバが SSH-2 に対応していないようでも SSH-1 にフォールバックしません。 SSH-1 を明示的に指定してください。
はい。バージョン 0.52 でローカルエコーを正式にサポートしました。
バージョン 0.51 とそれ以前ではローカルエコーはローカル行編集と不可分で、 Enter キーを押すまで入力がサーバに送られず、入力ミスをサーバが拾う前に 訂正できました。バージョン 0.52 より、ローカルエコーとローカル行編集が別のオプションとなり、 PuTTY はデフォルトではプロトコルやサーバからのヒントによりそれらを有効にすべきか判断しようとします。もしデフォルトに問題があるならば、オプションの有効無効を自分で選択できます。この制御は端末パネルの“LDISC オプション / Line discipline options” セクションにあります。
はい。 PuTTY のすべての設定をセッションプロファイルとして名前をつけて保存できます。新しいセッションのためにデフォルトの設定も変更できます。方法は section 4.1.2 を参照してください。
今のところできません。ただし同じ結果となる方法は section 4.35 で解説しています。
[Custom] 設定を ini ファイルに保存する方法があります。 section 2.1.2 を参照してください。
はい。バージョン 0.52 (2002 年) に実装しました。
ありません。
パスワードを記憶させるのはセキュリティ上の理由から明らかに悪いことです。あなたがいない間にマシンにアクセスできる人は誰でもパスワードを見つけて使い、悪用し、変更できます。
さらに、Telnet では PuTTY がパスワードを自動的に送ることは不可能です。なぜなら Telnet ではいつパスワードの入力を求めているのかクライアントソフトウェアが知るすべがないからです。 PuTTY は“password”のような文字をセッションデータから探して推測するしかありませんが、これが英語でかかれていなければ動作しません。
SSH では理論的にはパスワードを記憶できます。しかし SSH はより柔軟で安全な公開鍵認証に対応しているのであまり利点がありません。公開鍵認証に関しては chapter 8 を参照してください。
[Custom] 過去の Pageant に公開鍵のパスフレーズを保存する機能がありましたが、この機能は削除されました。代わりに KeePass など、暗号化機能を備えたパスワード管理ソフトを利用してください。
過去にこの機能で保存したパスワードはレジストリの場合 HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Passphrases 以下、 .ini ファイルの場合 [Passphrases] セクションに保存されます。マスク処理されていますが暗号化されていません。
ありません。もし仮にあなたがパッチを送ってもマージしません。
この煩わしいホスト鍵の表示が SSH の本質です。これがなければ、セッションを安全にするために SSH が使う暗号技術のすべては攻撃者を少し面倒にさせる程度になってしまいます。パケットスニッファを起動する代わりにあなたとサーバの間に立ってルータをいじって行き来するパケットを変更する行為、それはスニッフィングと比べて大して難しくありません。そしてホスト鍵を検証しないと、クライアントもサーバもそれを感知できません。
ホスト鍵の検証でクライアントで行った暗号化がサーバ側で行った暗号化と同じであるという確証を得られます。途中で削除されたり置き換えられたりしていないことはあなたが保証するのです。ホスト鍵の検証はパケットスニッフィングやルータの改竄に比べて攻撃を 天文学的に難しくします。攻撃にはほんの少しの知識と oss-security を確認するだけでよかったのが、少なくとも軍用強度の暗号に対して総当り攻撃をする羽目になります。この些細なホスト鍵の表示が、実際にその違いを生みます。
ホスト鍵の検証が特定の問題となるのは、おそらく自動バッチ処理に PSCP や Plink を使うときで、ホスト鍵の表示ダイアログがバッチを止めてしまうのでしょう。それであれば、正しい修正方法は前もって正しいホスト鍵をレジストリに加えておくことです。 ([Custom] ini ファイル を利用する場合は section 2.1.2 参照。) もしレジストリが使えないならば、-hostkey コマンドラインオプションを使います。そうすればホスト鍵の検証の重要な特長、正しいホスト鍵を受け付けて間違ったものを排除する処理を維持できます。ホスト鍵の検証を無効化するオプションの追加は間違った解決法であり、これは実装しません。
kh2reg.py スクリプトによって Windows の .REG ファイルに変換できます。そうしてダブルクリックするか REGEDIT を使い、前もってインストールできます。
使いたいようなものは加わりません。
プロトコルやネットワークのコードの多くはクライアントとサーバで共通化できますが、役に立つ汎用のサーバを作るには、OS の認証データベースとのやり取りなどの手間のかかる様々な新しいコードが必要になります。
特別な用途の SSH サーバ (Uppity という名前) が PuTTY のソースコードからビルドできますが、実際、汎用のサーバにはなりません。主にテストハーネスのためにあります。
もし誰かがこれを元にして汎用の SSH サーバを書きたいならば、もちろん歓迎します。しかし時間も動機も私たちにはありません。誰かが試したいならばコードは利用できます。
残念ながらできません。
元々 SCP や SFTP プロトコルにはバイナリモードの転送以外の記述がなかったたため (今でも SCP にはありません)、ファイル転送の制限となっていました。
過去の SFTP のドラフト仕様には ASCII 転送の提案が含まれていました。いつか PSCP/PSFTP がこれを実装するかもしれません。
訳注: ASCII モードは ファイルをテキストとして扱い改行コードを変換するモードのことです。 FTP などに存在しますが、テキストのエンコーディングとは関係ありません。
PuTTY の最終目標はマルチプラットフォームプログラムとなり、少なくとも Windows, Mac OS, Unix で動作することです。
PuTTY は一般移植レイヤーを実装しつつあり、プラットフォーム依存のコードと非依存のコードを明確に分けようとしています。この移植レイヤーを最初の移植で自然に発展させるのが目的でした。 Unix ポートがリリースされ、計画は今のところうまく行っているようです。
現在リリースされている PuTTY ツールは Windows と Unix のみで動作します。
0.68 以降、公式の PuTTY 実行ファイルは Windows 11 を含む Windows XP 以降 で動作します。また将来のバージョンでも動作するはずです。一般的な x86 プロセッサ向けに 32-bit と 64-bit の Windows 実行ファイルを提供しています。互換性に関連する話題は question A.6.10 を参照してください。 32-bit の実行ファイルは Pentium 4 以降のプロセッサが必要です。 Windows の Arm プロセッサ向けにも実行ファイルを用意しています。
(Alpha プロセッサ向けの Windows にも実行ファイルを作成していましたが、関心が低下したため 0.58 で停止しました。)
開発コードでは部分的に Mac OS 向け移植が存在します (question A.3.6 を参照してください)。
現在 PuTTY は Windows CE では動作しません (question A.3.4 を参照してください)。
今のところ他のシステムへの移植でリリースできる品質のものはありません。もし Android 向けや iOS 向けなど他の移植版があるといわれたなら、それは間違いです。ありません。
ウェブサイトのリンクページにサードパーティーによる様々なプラットフォーム向けの移植版があります。
ほとんどの PuTTY ツールとまったく新しいアプリケーションの移植版が存在します。
ソースリリースに unix ディレクトリがあります。ビルドには cmake が必要です。ソースの README を参照してください。これでビルドできるのは:
pterm という PuTTY と同じ種類の端末エミュレーションを持った xterm タイプのプログラム
いろいろなこまごまとした理由があります。 pterm は PuTTY の xterm ターミナルエミュレーションが好きな人にとって有用で、そのような人は少なくとも多少はいます。 Unix の Plink は、OpenSSL の複雑さから OpenSSH がインストールしにくいと思っている人に (そして Plink がそんなに多機能でないことを気にしない人に) 向けた明らかな市場を見出しました。一部のユーザはたくさんの SSH 鍵を Unix で生成し、PuTTY にコピーしようとしていました。 Unix の PuTTYgen で変換を自動化できるようになります。
開発する上での利点もあります。 PuTTY を Unix に移植すると、将来他に移植する時の価値のある指針となります。また Linux の素晴らしいツール Valgrind を使ってデバッグできるようになりました。これによってすべてのプラットフォームで PuTTY の安定性が向上しました。
しかし、Unix ユーザで OpenSSH から PuTTY/Plink に切り替える理由が見つからなければ、それはきっと正しいでしょう。 Unix 移植版が誰にでも向いているとは考えていません。
We once did some work on such a port, but it only reached an early stage, and certainly not a useful one. It's no longer being actively worked on.
PuTTY is a 32-bit application from the ground up, so it won't run on Windows 3.1 as a native 16-bit program; and it would be very hard to port it to do so, because of Windows 3.1's vile memory allocation mechanisms.
However, it is possible in theory to compile the existing PuTTY source in such a way that it will run under Win32s (an extension to Windows 3.1 to let you run 32-bit programs). In order to do this you'll need the right kind of C compiler - modern versions of Visual C at least have stopped being backwards compatible to Win32s. Also, the last time we tried this it didn't work very well.
We hope so!
We attempted one around 2005, written as a native Cocoa application, but it turned out to be very slow to redraw its window for some reason we never got to the bottom of.
In 2015, after porting the GTK front end to work with GTK 3, we began another attempt based on making small changes to the GTK code and building it against the OS X Quartz version of GTK 3. This doesn't seem to have the window redrawing problem any more, so it's already got further than the last effort, but it is still substantially unfinished.
If any OS X and/or GTK programming experts are keen to have a finished version of this, we urge them to help out with some of the remaining problems! See the TODO list in unix/main-gtk-application.c in the source code.
I hope so, but given that ports aren't really progressing very fast even on systems the developers do already know how to program for, it might be a long time before any of us get round to learning a new system and doing the port for that.
However, some of the work has been done by other people; see the Links page of our website for various third-party ports.
We have no plans to write such a port ourselves; none of us has an iPhone, and developing and publishing applications for it looks awkward and expensive.
However, there is a third-party SSH client for the iPhone and iPod Touch called pTerm, which is apparently based on PuTTY. (This is nothing to do with our similarly-named pterm, which is a standalone terminal emulator for Unix systems; see question A.3.2.)
いいえ、できません。そうするには少なくない量の書き換えが必要になりますが、PuTTY プロジェクトは DLL を信頼していないため (インストールの問題を起こしやすいので) 私達の誰もその手間を掛けていません。
ほとんどのコードクリンアップの成果は一般によい事象なので、誰かが手伝いたいならば、私達は受け入れないことはないでしょう。
ウィッシュリストの項目 も参照してください:
No, it isn't. None of the PuTTY team uses Visual Basic, and none of us has any particular need to make SSH connections from a Visual Basic application. In addition, all the preliminary work to turn it into a DLL would be necessary first; and furthermore, we don't even know how to write VB components.
If someone offers to do some of this work for us, we might consider it, but unless that happens I can't see VB integration being anywhere other than the very bottom of our priority list.
Plink というコマンドラインの接続ツールを使うのがおそらく最も確実です。 Plink を Windows のサブのプロセスとして起動して、メインプロセスから Plink のプロセスへパイプ経由でデータを送ったり受け取ったりできるように準備します。そうすればあなたのプログラムから SSH 接続を利用できます。
例えば Windows 版の CVS がこの方法を行っています。
For most purposes, PuTTY can be considered to be an xterm terminal.
PuTTY also supports some terminal control sequences not supported by the real xterm: notably the Linux console sequences that reconfigure the colour palette, and the title bar control sequences used by DECterm (which are different from the xterm ones; PuTTY supports both).
By default, PuTTY announces its terminal type to the server as xterm. If you have a problem with this, you can reconfigure it to say something else; vt220 might help if you have trouble.
Windows では PuTTY はほとんどのデータ (保存済みセッション、SSH ホスト鍵) をレジストリに保存します。正確な場所は
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY
で、その中の Sessions が保存済みセッションで、SshHostKeys がホスト鍵です。
([Custom] ini ファイル を利用する場合は section 2.1.2 参照。)
PuTTY は SSH の暗号化で乱数データの予測不可能性を改善するために乱数シードファイルも必要とします。このファイルはデフォルトで PUTTY.RND という名前で“Application Data”ディレクトリか、いくつかの代替ディレクトリに保存されます。保存するパスを変更したい場合、レジストリの次のパスにファイルパスを設定します:
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\RandSeedFile
PuTTY はこれらのデータすべてを削除できます。Question A.8.2 を参照してください。
Unix では PuTTY はすべてのデータをデフォルトで ~/.putty ディレクトリ内に保存します。
PuTTY 0.71 から、端末上の一部の行のテキストに小さな PuTTY アイコンが (ピクセルが許す限りは) 付くようになりました。
これは信頼性を示します。 PuTTY アイコンが行の隣に出る場合、その行のテキストは PuTTY 自身が出力したもので、サーバが生成して PuTTY に送信されたものではないことを示します。
サーバから来るテキストにはアイコンが付きません。そしてサーバが捏造できないようにしました。 (サーバが送信できる制御コードに PuTTY にアイコンを描かせるものはありません。そしてもしサーバが既にアイコンのある行にカーソルを動かしてテキストを上書きしたら、アイコンは消えます。)
これによってあなたは (例えば) PuTTY が秘密鍵のパスフレーズを尋ねた正規のプロンプトと、サーバが同じテキストを送って秘密鍵のパスフレーズをそこに入力させようとする偽のプロンプトを区別できます。
PuTTY 0.71 より、 Plink を対話型 SSH セッションで使うと、ログインが完了したときに最後の対話型プロンプトとして “Access granted. Press Return to begin session.” と表示します。
これはセッションが開始した後でサーバが認証プロンプトを模倣しようとするのに対するもう一つの防御策です。プロンプトが出た後はすべて、サーバが生成したもので Plink 自体のものではないと判ります。そのため秘密鍵のパスワードを求められても、疑いを持って対処できます。
Plink では section A.5.3 の、アイコンを表示する防御策は使えません。
Plink は端末の中で動作しているので、Plink が書き込める (表示できる) ものはなんでも、セッションが開始した後にはサーバも書き込めます。そして単に一時停止なしで区切りのメッセージを表示することはできません。なぜならサーバはカーソルを上に動かしてそれを上書きできるからです (おそらく多少のフリッカーが出るでしょうが、簡単に見逃しえます)。誰もが思いつく堅牢な対策は一時停止を含めることです。
もしサーバがそのような悪用をしないと信頼するならば、この処理を無効にできます。また Plink が不要と確実に判断するいくつかの状況でも表示されません。詳細は section 7.2.3.6 を参照してください。
それは私たちにする質問ではありません。
PuTTY は他のコンピュータに接続を確立する通信ツールです。ツールをメンテナンスしていますがあなたの使えそうなコンピュータの管理はしていません。ウェブブラウザを開発している人たちがそれで閲覧できるコンテンツのほとんどに関わっていないのと同じです。 この種の質問には応えられません。
接続したいコンピュータの名前が判っていてログイン名やパスワードが分からない場合、コンピュータの管理者に訊ねます。それが誰か分からない場合は次の質問で可能性のある方法を見つけてください。
これもやはり私たちにする質問ではありません。 接続したコンピュータのマニュアルを読むか、管理者に尋ねます。
PuTTY は入力したコマンドを実行しません。ただの通信ツールです。他のコンピュータに接続を確立して、入力されたコマンドをそのコンピュータに送ります。そしてそのコンピュータの応答をあなたに返します。そのため使える正確なコマンドは、PuTTY によらずに接続したコンピュータと動作しているソフトウェアによります。 PuTTY 開発チームは助けになれません。
(PuTTY を電話のようなものと考えてください。誰かに電話して、相手に理解できる言語が判らないとき、それを調べるのは電話会社の仕事ではありません。連絡手段を提供していても、理解してもらうのは他の問題です。)
サーバの管理者をどうやって探せばよいか分からない場合、PuTTY の設定に入力したホスト名をどうやって見つけたかがよい出発点です。例えばメールで教えられたならばそのメールを送った人に訊いてみます。会社の IT 部門が PuTTY の保存済みセッションを用意したなら、その IT 部門がセッションで使えるコマンドについて何か教えてくれるかもしれません。 PuTTY のメンテナチームはあなたが繋ぎそうなサーバは管理していませんし、この種の質問には応えられません。
PuTTY を起動する Windows ショートカットを作り、プロパティから実行時の大きさを“最大化”にします。
“mysession”という名前で保存した PuTTY セッションを開始するには、次のような PuTTY コマンドラインを実行する Windows ショートカットを作ります:
\path\name\to\putty.exe -load "mysession"
(注: 0.53 以前では ...\putty.exe @session という書式でした。これは古い書式で将来廃止する予定です。)
putty -ssh host.name を使います。もしくは SSH プロトコルを指定した保存済みセッションを作成し、question A.6.4 の通りにセッションを開始します。
コピー&ペーストは X Window システムと似た形で動作します。 PuTTY ウインドウ上でマウスの左ボタンでテキストを選択します。選択すると自動的にテキストをクリップボードにコピーしますので Ctrl-Ins も Ctrl-C も押す必要はありません。実際 Ctrl-C を押すと Ctrl-C 文字を接続に対して (他の入力と同じように) 送信するので、喜ばしくない結果に終わるでしょう。クリップボードにテキストをコピーするのに唯一必要なのは、選択することだけです。
クリップボードの内容を貼り付けるには、マウスの右ボタンをクリックします。 3 ボタンマウスを使っていて X アプリケーションに慣れているならば、中ボタンで貼り付けるよう設定できます。ほとんどの Windows ユーザは中ボタンが無いのでデフォルトにはなっていません。
Shift-Ins で貼り付けることもできます。
主要な機能のほとんど (例えば公開鍵やポート転送) はコマンドラインオプションから使えます。 Section 3.11.3 を参照してください。
コマンドラインからはまだ使えない機能もありますが、修正したいと思っています。それまでは、保存済みセッションを作成して、保存済みセッションの名前をコマンドラインで指定すればほぼ代用できます。 PSCP, PSFTP, Plink で使えます (ですがファイル転送プログラムでポート転送は動作しません)。
PSCP はコマンドラインアプリケーションで、GUI アプリケーションではありません。引数を指定しないで実行すると、単にヘルプメッセージを表示して終了します。
PSCP を正しく使うには、コマンドプロンプトウインドウから実行します。詳しくは chapter 5 を参照してください。
通常 PSCP は SFTP プロトコルを使っています。その場合、スペースを含むファイル名はクオートで囲みます:
pscp "local file" user@host:
pscp user@host:"remote file" .
非常に古いサーバの場合など、SFTP プロトコルが使えない場合は、PSCP は伝統的な SCP プロトコルを使いますが、この場合ややこしいです。ローカル側のファイル名を指定する場合は通常通りクオートで囲みます:
pscp "local filename with spaces" user@host:
pscp user@host:myfile "local filename with spaces"
しかしリモート側のファイル名を指定する場合はバックスラッシュ (日本語環境では円記号) を使って 2 組のクオートで囲みます:
pscp user@host:"\"remote filename with spaces\"" local_filename
pscp local_filename user@host:"\"remote filename with spaces\""
なお悪いことに、リモートからローカルへのコピーではローカル側のファイル名も指定の必要があります。そうしないとリモート側から転送されたファイル名がローカル側と一致しないと PSCP がエラーを表示します (危険な -unsafe オプションを指定した場合は別です)。以下のコマンドはエラーメッセージを表示します:
c:\>pscp user@host:"\"oo er\"" .
warning: remote host tried to write to a file called 'oo er'
when we requested a file called '"oo er"'.
警告: '"oo er"' というファイルを要求しましたが、
リモートホストは 'oo er' というファイルに書き込もうとしました。
代わりにローカル側のファイル名も指定します:
c:\>pscp user@host:"\"oo er\"" "oo er"
分からないならば 32-bit 版が安全な選択です。 PuTTY が対応しているすべてのプロセッサのすべての Windows のバージョンで完全に動作します。 PuTTY は適切な動作に 64-bit アプリケーションを必要としませんし、32-bit 版 PuTTY を 64-bit システムで動作しても何も問題を起こしません。
64-bit 版 (0.68 からリリース) は 64-bit プロセッサかつ 64-bit 版 Windows でのみ動作します (最近の Windows PC はこの条件を満たすでしょう)。いくらか速く動作する (特に、接続時の暗号処理は速いでしょう) 一方で、ややメモリを多く消費します。
GSSAPI 認証のために外部 DLL を利用する必要があり、その DLL が 32-bit か 64-bit でしか提供されていないならば、その版の PuTTY を使うことになります。 (これは当然のことです。section 4.25.2 を参照してください。)
This happens because PSCP was expecting to see data from the server that was part of the PSCP protocol exchange, and instead it saw data that it couldn't make any sense of at all.
This almost always happens because the startup scripts in your account on the server machine are generating output. This is impossible for PSCP, or any other SCP client, to work around. You should never use startup files (.bashrc, .cshrc and so on) which generate output in non-interactive sessions.
This is not actually a PuTTY problem. If PSCP fails in this way, then all other SCP clients are likely to fail in exactly the same way. The problem is at the server end.
色パネルはそうやって使うものではありません。
セッションの中で PuTTY は色パネルの色すべてを使う可能性があります。一つだけを使うからどれかを選ぶという話ではありません。 すべてを使うのです。色パネルの目的はそれらすべての色の見た目の調整です。例えばカーソルの色を変えるならば、“カーソルの色 / Cursor Colour”を選び、“変更 / Modify”ボタンを押して、表示されるダイアログから新しい色を選びます。同様に、セッションを緑で出したいならば、“標準の文字 / Default Foreground”をを選んで“変更 / Modify”ボタンを押します。 “ANSI 緑 / ANSI Green”を押してもセッションは緑にはなりません。 “ANSI 緑 / ANSI Green”はサーバが緑の文字を表示するように求めたときに PuTTY がどのような色調を使うかを調整します。
If this happens just while the connection is starting up, this often indicates that for some reason the client and server have failed to establish a session encryption key. Somehow, they have performed calculations that should have given each of them the same key, but have ended up with different keys; so data encrypted by one and decrypted by the other looks like random garbage.
This causes an “out of memory” error because the first encrypted data PuTTY expects to see is the length of an SSH message. Normally this will be something well under 100 bytes. If the decryption has failed, PuTTY will see a completely random length in the region of two gigabytes, and will try to allocate enough memory to store this non-existent message. This will immediately lead to it thinking it doesn't have enough memory, and panicking.
If this happens to you, it is quite likely to still be a PuTTY bug and you should report it (although it might be a bug in your SSH server instead); but it doesn't necessarily mean you've actually run out of memory.
This is almost always caused by your login scripts on the server generating output. PSCP or PSFTP will receive that output when they were expecting to see the start of a file transfer protocol, and they will attempt to interpret the output as file-transfer protocol. This will usually lead to an “out of memory” error for much the same reasons as given in question A.7.3.
This is a setup problem in your account on your server, not a PSCP/PSFTP bug. Your login scripts should never generate output during non-interactive sessions; secure file transfer is not the only form of remote access that will break if they do.
On Unix, a simple fix is to ensure that all the parts of your login script that might generate output are in .profile (if you use a Bourne shell derivative) or .login (if you use a C shell). Putting them in more general files such as .bashrc or .cshrc is liable to lead to problems.
The throughput of PSFTP 0.54 should be much better than 0.53b and prior; we've added code to the SFTP backend to queue several blocks of data rather than waiting for an acknowledgement for each. (The SCP backend did not suffer from this performance issue because SCP is a much simpler protocol.)
You almost certainly need to change the “Use background colour to erase screen” setting in the Terminal panel. If there is too much black space (the commoner situation), you should enable it, while if there is too much colour, you should disable it. (See section 4.3.5.)
In old versions of PuTTY, this was disabled by default, and would not take effect until you reset the terminal (see question A.7.7). Since 0.54, it is enabled by default, and changes take effect immediately.
Some of the terminal options (notably Auto Wrap and background-colour screen erase) actually represent the default setting, rather than the currently active setting. The server can send sequences that modify these options in mid-session, but when the terminal is reset (by server action, or by you choosing “Reset Terminal” from the System menu) the defaults are restored.
In versions 0.53b and prior, if you change one of these options in the middle of a session, you will find that the change does not immediately take effect. It will only take effect once you reset the terminal.
In version 0.54, the behaviour has changed - changes to these settings take effect immediately.
Some types of firewall, and almost any router doing Network Address Translation (NAT, also known as IP masquerading), will forget about a connection through them if the connection does nothing for too long. This will cause the connection to be rudely cut off when contact is resumed.
You can try to combat this by telling PuTTY to send keepalives: packets of data which have no effect on the actual session, but which reassure the router or firewall that the network connection is still active and worth remembering about.
Keepalives don't solve everything, unfortunately; although they cause greater robustness against this sort of router, they can also cause a loss of robustness against network dropouts. See section 4.16.1 in the documentation for more discussion of this.
This is a Windows problem, not a PuTTY problem. The timeout value can't be set on per application or per session basis. To increase the TCP timeout globally, you need to tinker with the Registry.
On Windows 95, 98 or ME, the registry key you need to create or change is
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\
MSTCP\MaxDataRetries
(it must be of type DWORD in Win95, or String in Win98/ME). (See MS Knowledge Base article 158474 for more information.)
On Windows NT, 2000, or XP, the registry key to create or change is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\
Parameters\TcpMaxDataRetransmissions
and it must be of type DWORD. (See MS Knowledge Base articles 120642 and 314053 for more information.)
Set the key's value to something like 10. This will cause Windows to try harder to keep connections alive instead of abandoning them.
cat するとコマンドラインに“PuTTYPuTTYPuTTY”と出ますそれなら、やらないでください。
これは意図した挙動です。 PuTTY が Control-E をリモートサーバから受け取ると、端末についての要求として処理され、“PuTTY”とキーボードで入力したものとして送信します。 Control-E は応答を処理できるプログラムによってのみ送信されるべきです。バイナリファイルをターミナルに出力するとたくさんの Control-E を出力することになり、このような動作を引き起こします。やらないでください。それはよくない操作です。
この影響を抑えるために、応答する文字列を空にできます (section 4.3.7 参照)。しかしバイナリファイルを端末に出力するのは他にもよくない挙動を引き起こしかねないので、わずかな改善しかできません。
訳注: それでも必要ならば cat -v や less が使えるかもしれません。
cat するとウインドウタイトルが変な文字列になりますそれなら、やらないでください。
これは意図した挙動で、サーバの要求で PuTTY がウインドウタイトルを変更するために必要な機能です。通常この制御シーケンスはどれが何を引き起こすかわかっているプログラムによって意味のあるウインドウタイトルを設定するために意図的に送られるものです。バイナリファイルを端末に出力すると偶然に同じ制御シーケンスを送信してしまい、ウインドウタイトルを予期せず変更してしまう危険があります。やらないでください。
そんなことはありません。 PuTTY はあなたの入力したパスワードを表示しないだけです。そうすれば、画面を見ている人はパスワードが何なのか見えません。
Windows のログインプロンプトと違い、PuTTY はパスワードをマスクした文字で表示しません。これで画面を見ている誰かはパスワードがどれだけ長いかも判りません。パスワードの長さは有用な情報になるかもしれません。
PuTTY のキーボードパネルにある関連するオプションをすべて試したならば、PuTTY のメンテナにメールして尋ねる必要があるかもしれません。
どのアプリケーション、どの OS、どのキーが動作しないかを知らせてもらっても、通常は役に立ちません。それでは問題を再現するのに私たちがそれらすべての OS やアプリケーションを用意する必要があります。
PuTTY はファンクションキーの押下に対してサーバに制御文字列を送信します。もしファンクションキーが思ったように動作しないならば、PuTTY の送信する文字列が、そのアプリケーションの期待するものでない可能性があります。そのため、私たちが実際に知る必要があるのは、アプリケーションが期待する文字列です。
これを調べる一番簡単な方法は、そのファンクションキーが動作する他の端末環境を探すことです。そしてその環境でどんな文字列をファンクションキーが送っているかを調べます。 Unix 環境で調べる手軽な方法の一つは、cat コマンドをタイプして、それからファンクションキーを押してみることです。そうすると ^[[11~ のような形の出力が出るはずです。これと同じ事を PuTTY でもやってみます。そうして、PuTTY のメンテナに、 “F1 キーを押したら ^[[11~ を送ってほしいのですが、^[OP が送られてしまいます。どうやったらできますか？”と言った風に連絡します。
ですが、PuTTY ウェブサイトの Feedback page を読んで (マニュアルの appendix B にもあります )、ガイドラインに従う必要があります。
It's likely that you've generated an SSH protocol 2 key with PuTTYgen, but you're trying to use it in an SSH-1 connection. SSH-1 and SSH-2 keys have different formats, and (at least in 0.52) PuTTY's reporting of a key in the wrong format isn't optimal.
To connect using SSH-2 to a server that supports both versions, you need to change the configuration from the default (see question A.2.1).
A common complaint is that hyphens in man pages show up as a-acute.
With release 8.0, Red Hat appear to have made UTF-8 the default character set. There appears to be no way for terminal emulators such as PuTTY to know this (as far as we know, the appropriate escape sequence to switch into UTF-8 mode isn't sent).
A fix is to configure sessions to RH8 systems to use UTF-8 translation - see section 4.10.1 in the documentation. (Note that if you use “Change Settings”, changes may not take place immediately - see question A.7.7.)
If you really want to change the character set used by the server, the right place is /etc/sysconfig/i18n, but this shouldn't be necessary.
screen.PuTTY's terminal emulator has always had the policy that when the “alternate screen” is in use, nothing is added to the scrollback. This is because the usual sorts of programs which use the alternate screen are things like text editors, which tend to scroll back and forth in the same document a lot; so (a) they would fill up the scrollback with a large amount of unhelpfully disordered text, and (b) they contain their own method for the user to scroll back to the bit they were interested in. We have generally found this policy to do the Right Thing in almost all situations.
Unfortunately, screen is one exception: it uses the alternate screen, but it's still usually helpful to have PuTTY's scrollback continue working. The simplest solution is to go to the Features control panel and tick “Disable switching to alternate terminal screen”. (See section 4.6.4 for more details.) Alternatively, you can tell screen itself not to use the alternate screen: the screen FAQ suggests adding the line “termcapinfo xterm ti@:te@” to your .screenrc file.
The reason why this only started to be a problem in 0.54 is because screen typically uses an unusual control sequence to switch to the alternate screen, and previous versions of PuTTY did not support this sequence.
127.0.0.2.
Some people who ask PuTTY to listen on localhost addresses other than 127.0.0.1 to forward services such as SMB and Windows Terminal Services have found that doing so no longer works since they upgraded to WinXP SP2.
This is apparently an issue with SP2 that is acknowledged by Microsoft in MS Knowledge Base article 884020. The article links to a fix you can download.
(However, we've been told that SP2 also fixes the bug that means you need to use non-127.0.0.1 addresses to forward Terminal Services in the first place.)
Some people have reported the following incorrect behaviour with PSFTP:
psftp> pwd
Remote directory is /dir1/dir2
psftp> get filename.ext
/dir1/dir2filename.ext: no such file or directory
This is not a bug in PSFTP. There is a known bug in some versions of portable OpenSSH (bug 697) that causes these symptoms; it appears to have been introduced around 3.7.x. It manifests only on certain platforms (AIX is what has been reported to us).
There is a patch for OpenSSH attached to that bug; it's also fixed in recent versions of portable OpenSSH (from around 3.8).
PuTTY のバージョン 0.53 と 0.53b のドキュメントには、このエラーについて報告してもらいたいと書いてありました。しかし PuTTY 0.54 のリリース以降は、このエラーは PuTTY が何かを間違えたせいで起きるのではないと私たちが確信できたので、もう私たちが知る必要はありません。このエラーについての説明は section 10.16 を参照してください。
最近のバージョンの PuTTY は一時間に一度、自動的に鍵交換を再実行してセッションのセキュリティを改善します。クライアントやサーバマシンの処理速度が遅い場合、これによって最大 30 秒近く処理が遅延することがあります。
この遅れの発生は不便ですが、あなたを保護するためにあります。本当にこれが問題ならば、“Kex”設定パネルで定期的な鍵交換を無効にできます (section 4.20 参照)。ただしこれはセキュリティを犠牲にすることに注意してください。 (代わりに SSH-1 を使っても遅れがなくなりますが、より多大な安全性を犠牲にするので推奨しません。)
This is caused by a bug in certain versions of Windows XP which is triggered by PuTTY 0.58. This was fixed in 0.59. The “xp-wont-run” entry in PuTTY's wishlist has more details.
C:\WINDOWS\SYSTEM32 に置くと“セッションの複製 / Duplicate Session”が動作しません一言でいうなら、PuTTY の実行ファイルをそこに置かないでください。
64-bit システムでは C:\WINDOWS\SYSTEM32 は 64-bit バイナリだけを含むことになっています。 Windows の 32-bit バイナリは C:\WINDOWS\SYSWOW64 に置かれます。 32-bit PuTTY の実行ファイルが 64-bit システムで実行されると、“実際の” C:\WINDOWS\SYSTEM32 が見えなくなります。実行しているプログラムが適切な種類のバイナリが SYSTEM32 に見つかるようにファイルシステムリダイレクタが調整するためです。よって、PuTTY などが自分自身の実行ファイルにアクセスしようとする“新しいセッション / New Session”や“セッションの複製 / Duplicate Session”は動作しません。
If your SSH server has started unexpectedly closing SSH connections after you enter your password, and it worked before 0.68, you may have a buggy server that objects to certain SSH protocol extensions.
The SSH protocol recently gained a new “terminal mode”, IUTF8, which PuTTY sends by default; see section 4.26.2. This is the first new terminal mode since the SSH-2 protocol was defined. While servers are supposed to ignore modes they don't know about, some buggy servers will unceremoniously close the connection if they see anything they don't recognise. SSH servers in embedded devices, network appliances, and the like seem to disproportionately have this bug.
If you think you have such a server, from 0.69 onwards you can disable sending of the IUTF8 mode: on the SSH / TTY panel, select IUTF8 on the list, select “Nothing”, and press “Set”. (It's not possible to disable sending this mode in 0.68.)
PuTTY 0.78 では、 SSH 公開鍵認証の .PPK ファイルを指定する、“認証のための秘密鍵ファイル / Private key file for authentication”コントロールは設定ダイアログに新しく追加された“クレデンシャル”パネルに移動しました。左のツリービューより“SSH”カテゴリを開き、“認証 / Auth”サブカテゴリを開き、そして“クレデンシャル / Credentials”をクリックします。 Section 4.24.1 にある通り、このページで On this page you'll find the “参照... / Browse...”ボタンで認証のための .PPK ファイルを選択します。
(このコントロールは 2002 年に公開鍵認証がリリースされた当時から以前までは“認証 / Auth”パネルにあり、多くのオンラインの How-to ガイドはそのままの場所で解説しています。 OpenSSH 証明書などの 0.78 で追加された機能の場所を作るために、設定コントロールは再配置されました。)
その PC を信頼するかどうかによります。公共の PC を信頼しないなら、PuTTY をそこで使わないでください。他のパスワードを入力するソフトウェアも同様です。その PC がキー入力を監視しているかまたは、ダウンロードした PuTTY を改竄しているかもしれません。悪意のある PC で安全に動かせるプログラムはありませんので、そこでパスワードを入力しないでください。
PC を信頼するならば、PuTTY を実行してもおそらく大丈夫です (ですが接続したネットワークを信頼しないならば、ダウンロードした PuTTY は改竄されているかもしれません。PuTTY を USB フラッシュメモリにいれておく方がいいでしょう)。
PuTTY は PC にレジストリエントリと乱数シードファイルを残します (Question A.5.2 参照)。 Windows 7 以降は“ジャンプリスト”機能のために、使用したセッションの情報を記憶しています。 PuTTY を公共の PC や他人の PC で使う場合、最後にこれらの情報を削除したほうがいいでしょう。 putty -cleanup コマンドを実行すると削除できます。詳しくは section 3.11.2 を参照してください。 (マルチユーザシステムでは現在のユーザの設定のみ削除します。) [Custom] ini ファイルを使っている場合、このオプションは ini ファイルのデータを削除します。
PuTTY をインストーラでインストールした場合、“プログラムと機能”にも表示されます。現在のバージョンのアンインストーラは上記のレジストリエントリやファイルを削除しません。それらを削除したいならば、アンインストール前に putty -cleanup を実行します。
DSA は乱数生成器に非常に多く依存しているため、誤った実装に大きな脆弱性があります。乱数生成器が攻撃者が予測できる数値を生成した場合、DSA 秘密鍵が暴露されます。つまり攻撃者は、その鍵を受け付けるすべてのシステムにあなたとしてログインできます。
開発者に対し、この脆弱性にそれほど悩まされないかつ乱数にまったく依存しない方法が知らされたため、PuTTY の方針が変わりました。そのため PuTTY の DSA 実装はおそらく大丈夫です。 0.68 で追加された楕円曲線の署名方式も DSA 形式のアルゴリズムです。そのため原理的に同じ弱点があります。 PuTTY の ECDSA 実装は DSA と同様の対策を取っており、一方 Ed25519 の実装は類似した (しかし詳細は異なる) 仕組みを Ed25519 の仕様が要求する通りに使っています。
VirtualLock() を使って秘密鍵がディスクに書き込まれないようにできませんか
残念ながらできません。 Windows API の VirtualLock() は適切に動作しません。プロセスの動作中にプロセスメモリの一部がディスクにページアウトしないようにできますが、プロセスが長期間非アクティブなときにプロセスメモリ全体をディスクにスワップアウトしないようにはできないのです。そして Pageant は起動中の多くの時間、非アクティブです。
訳注: Windows にはページファイルを暗号化する機能があり、fsutil behavior query encryptPagingFile で設定の確認、fsutil behavior set encryptPagingFile 1 または 0 で有効無効を変更できます。変更後は再起動が必要です。
このリンクにある無料の “PuTTY” アプリケーションは、私たちによってメンテナンスされ、提供されています。最新版は、私たちのウェブサイトに公開されてから数日以内に公開されます。
ストアには他にも PuTTY が存在するようです。非常に似通ったものや、有料のものがあります。それらは別の人たちによってアップロードされており、私たちは何も保証できません。
Microsoft Store に最初に公開したバージョンは 0.76 です。 (ウェブサイトに公開してからいくらか時間が経ってから行われました。)
putty.org があなた方のウェブサイトですか?
いいえ、違います。 putty.org はそのドメインを使って、私たちの無料の SSH クライアントを探しに来た人に商業版の SSH 実装を宣伝する、便乗サイトです。私たちはそのサイトを所有していませんし、管理できません。そして私たちはそのサイトを私たちのサイトの代わりに使うように勧めてもいません。
PuTTY の本当の、PuTTY チームによって運営されているウェブサイトは今までもこれからも https://www.chiark.greenend.org.uk/~sgtatham/putty/ です。
the.earth.li and not chiark? Has your website been hacked?
We haven't been hacked: links to the.earth.li are legit. The files for released versions of PuTTY are hosted on a different server from the web pages, for bandwidth reasons.
The download site the.earth.li is hosted by Mythic Beasts, and we're very grateful to them!
いいえ、結構です。もし見つけても (ほとんどは私たちに実際欲しいかどうか確認せずに申請した人たちによって登録済みでしょうが)、PuTTY のウェブサイトは今のままで十分満足しています。見つけるのは難しくないですし (“putty”とgoogle.comに打てば最初に出てきます)、サイトを移転する面倒ごとに見合う利点があるとは思えません。
訳注: 過去に“putty”と検索すると非公式なミラーサイトがトップに出る“事件”が起きたことがあります。正規配布のバイナリかどうかは GPG で確認するのが安全です。
さらに、もし仮に独自ドメインが欲しければ、それは自分で運用したいと思います。そうすればドメインが確実に意図したとおりのサイトを指すようにできますし、突然それが変わったり変なことになったりしません。ドメインを知らない第三者に取得してもらうのは最善の方法ではありません。
ありがとう、もう持っています。
Only if the content of your web page is of definite direct interest to PuTTY users. If your content is unrelated, or only tangentially related, to PuTTY, then the link would simply be advertising for you.
One very nice effect of the Google ranking mechanism is that by and large, the most popular web sites get the highest rankings. This means that when an ordinary person does a search, the top item in the search is very likely to be a high-quality site or the site they actually wanted, rather than the site which paid the most money for its ranking.
The PuTTY web site is held in high esteem by Google, for precisely this reason: lots of people have linked to it simply because they like PuTTY, without us ever having to ask anyone to link to us. We feel that it would be an abuse of this esteem to use it to boost the ranking of random advertisers' web sites. If you want your web site to have a high Google ranking, we'd prefer that you achieve this the way we did - by being good enough at what you do that people will link to you simply because they like you.
In particular, we aren't interested in trading links for money (see above), and we certainly aren't interested in trading links for other links (since we have no advertising on our web site, our Google ranking is not even directly worth anything to us). If we don't want to link to you for free, then we probably won't want to link to you at all.
If you have software based on PuTTY, or specifically designed to interoperate with PuTTY, or in some other way of genuine interest to PuTTY users, then we will probably be happy to add a link to you on our Links page. And if you're running a particularly valuable mirror of the PuTTY web site, we might be interested in linking to you from our Mirrors page.
一つの理由はウェブサイトを別の場所に移したくないからです (Question A.9.3 参照)。
またセキュリティ上の理由もあります。 PuTTY はセキュリティ製品なのでコードやウェブサイトをセキュリティの欠陥を生むような不正な変更から守る必要があります。そのため Git リポジトリ、ウェブサイト、FTP サイトを、私たちが会ったことがない人たちがたくさんいる巨大な団体の、過去に侵入されたことがある場所に移動せず、個人的に知っていて信頼しているシステム管理者の下に残しています。
SourceForge が悪いわけではありません。非常に素晴らしいサイトだと思います。しかし誰にでも理想的ではありません。特に私たちには違います。
Because you're not a member of the PuTTY core development team. The putty-bugs mailing list is not a general newsgroup-like discussion forum; it's a contact address for the core developers, and an internal mailing list for us to discuss things among ourselves. If we opened it up for everybody to subscribe to, it would turn into something more like a newsgroup and we would be completely overwhelmed by the volume of traffic. It's hard enough to keep up with the list as it is.
There isn't one, that we know of.
If someone else wants to set up a mailing list or other forum for PuTTY users to help each other with common problems, that would be fine with us, though the PuTTY team would almost certainly not have the time to read it.
http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-donations
どうか、どうか寄付しなければならないとは思わないでください。 PuTTY は完全に無料のソフトウェアで、シェアウェアではありません。私たちは PuTTY を使いたい人はお金があってもなくても誰でも使えることが重要だと考えています。そのため PuTTY ユーザが私たちにお金を支払っていないからと後ろめたい気持ちになるような事態が起こってほしくありません。もしお金を手元に残しておきたいなら、そうしてください。私たちはお金を得ようとは夢にも思っていません。
その上で、それでも本当にカンパしたいなら、それに反対はしません :-) 私たちにとって一番簡単な方法は PayPal (www.paypal.com) で <anakin@pobox.com> 宛てに送ってもらうことです。 PayPal が好きではないなら、連絡をもらえれば別の方法を用意できると思います。
少額の寄付 (数十米ドルやユーロ) は多分ビールやカレーになって、そしてボランティアチームがこの世界のために開発する刺激になります。より大きい額の場合、実際に開発を助ける何かがあれば、それに使われます (多分、新しいハードウェアや新しい Windows のライセンスに)。ですがもし何も見つからなければお金は開発者に分配します。もしあなたの寄付を何か価値のあるものに使って欲しいならば、最初に私たちに尋ねてください。これらの予定が気に入らなければ、寄付をしないでまったく問題ありません。
はい。ほとんどの事はわざわざ明確に許可を求める必要はありません。ライセンスで既に許諾されています。
より詳しくは section B.9 を参照してください。
いいえ!
物理的なセキュリティ製品 (例えば錠前) の製造会社はおそらく広告されたとおりに動作せず損害が発生した場合 (貴重品を盗まれるなど) 金融債務を負う契約をするでしょう。彼らがそうできるのは、大量に販売するからで、残りの売り上げからの収入からの一部の負担で済むからであり、支払っても利益を生めるからです。金銭的債務は本質的に製品の販売と結びついています。
この文脈では PuTTY が物理的な錠前と類似していない点が二つあります。一つはソフトウェア製品は不規則変動を示さないことです。 もしも PuTTY にセキュリティホールがあったら (これは起こりますが、最大限発生を防ぎ、起こった場合はすばやく対応します (訳注: カスタム版は更新が遅れる場合があります。本家サイトで公開されるセキュリティホールの詳細を評価できない場合は古いバージョンの利用を停止してください)) 、すべての PuTTY のバイナリコピーが同じ欠陥を持ちます。そのためすべてのユーザに同時に影響する可能性が大きいです。そのためもしユーザ全員が PuTTY に対価を払ったとしても、支払い以上の補償を影響のあったユーザすべてに同時には、そもそもできません。まったく機能しません。
二番目のより重要な理由は、PuTTY のユーザはお金を支払わないことです。 PuTTY の開発チームには収入がありません。空いた時間を使って有用なソフトウェアを作ろうという人たちのボランティアの努力の結晶なのです。私たちは法人でも法的に認知された団体でもありません。単に余暇を使って何かしようという人たちの集まりです。
つまり、金銭的債務を求めることは衣食住に使う予算と同じ個人のポケットから支払うリスクを負わせることです。これは私たちが提供したいことを超えています。すでに自分の多くの空いた時間を使ってソフトウェアを無償で開発しているのに自分の金銭までも同じように使うとしたら、一体何をしているのか自問するでしょう。
フリーソフトウェアは根本的に金銭的約束の上には成り立ちません。ソフトウェアが正しく動作するという補償は、ソースコードを持っていて使う前に確認できる場合だけです。セキュリティホールがないことを確実にしたいならば、PuTTY のコードのセキュリティ監査を行うか、スキルがないならばセキュリティエンジニアを雇ってください。もしもの時の補償を得ようとするのではなく、そもそもの事態が起こらないようにしてください。
もし本当に補償が必要ならば、レビューの正確さに金銭的債務を負うセキュリティエンジニアを探してください。 (この場合、前述の“すべてが一度にダメになる問題”は起こりにくいでしょう。なぜならエンジニアは独立して機能しなくなる異なった製品をいくつもレビューしているはずだからです。) そうでなければ、保険会社がセキュリティインシデントに保険をかけてくれるか確認して、保険の要求を満たすセキュリティエンジニアにコードをレビューさせるとよいでしょう。
“the undersigned represents and warrants”という条項がある場合は署名しないでしょう。特に PuTTY が安全であるという保証を要求する場合です。これについては question A.9.11 を参照してください。しかし実際は何を私たちが保証するかという問題ではありません。たとえそれを私たちがすでに満たしていると確信していても、例えば第三者の著作権を侵害していないとかでも、法的または金銭的な保証の書類には署名しません。これは単に PuTTY 開発プロジェクトにその責任や法的費用を支払うに足る収入がないからです。私たちは訴訟を受ける余裕がありません。 私たちがベストを尽くしたことは保証します。それが十分でないならば、それで仕方ありません。
PuTTY のライセンス文書では、あなたがこれを作ったと見せかける場合や、誤動作した場合に訴えない限りにおいて、すでに利用と配布を行う許諾を与えています。誰にとってもそれで十分だと私たちは考えています。
この種の保証をしたくない別の理由については question A.9.14 を参照してください。
原理的には可能ですが、それが何の役に立つのかが明確でありません。もし PuTTY の著作権保持者の一人があなたを告訴する十分な可能性がある (私たちはしませんが!) とあなたが思っているとして、全員の署名付き通知を欲しがっても、私たちはやりたくてもできません。なぜなら権利者の多くは過去にコードを提供してくれて、その後接触のない人たちだからです。そのため可能なことは理屈上でさえ良くてコア開発者が書類に署名するくらいで、他の権利者が訴えないことは保証できません。
この種のことをしたくない他の理由については question A.9.14 を参照してください。
Not unless there's an incredibly good reason.
We are generally unwilling to set a precedent that involves us having to enter into individual agreements with PuTTY users. We estimate that we have literally millions of users, and we absolutely would not have time to go round signing specific agreements with every one of them. So if you want us to sign something specific for you, you might usefully stop to consider whether there's anything special that distinguishes you from 999,999 other users, and therefore any reason we should be willing to sign something for you without it setting such a precedent.
If your company policy requires you to have an individual agreement with the supplier of any software you use, then your company policy is simply not well suited to using popular free software, and we urge you to consider this as a flaw in your policy.
言える、言えない、どちらでもあります。
もしすでにダウンロードした現在のバージョンについてフリー (無償かつ自由) であるという確約ならば、あなたはすでに PuTTY ライセンスという形でそれを得ています。ソフトウェアを使用し、配布し、複製する許可は、私たちが一旦許諾すると (してありますが)、単に取り消せません。
一方で、将来のバージョンの PuTTY についてクローズドソースにしないという約束は、より難しくなります。原理的にはクローズドソースの PuTTY をリリースしないという書類に署名できますが、それはオープンソースの PuTTY を将来もリリースし続けるという約束ではありません。 PuTTY の開発を停止する選択がありますし、それはクローズドソースにするよりもあなたにとって良くないでしょう。 (そして私たちは PuTTY の開発作業を続けるという約束をする書類には、無償では絶対に署名したくないです。そのような書類は雇用契約書と呼ばれ、一般には相当な額の給与と引き換えにしないと署名しません。)
私たちが PuTTY の開発を停止しようとする、または将来リリースするのバージョンすべてをクローズドソースにする場合、最後のオープンソース版のリリースを現在のライセンス (the current licence) に沿って自由に複製できます。
訳注: リリースに同梱のライセンス文書が有効です。
特に、そのリリースから独自のバージョンをフォークできます。開発の停止が起こった場合、誰かがそうすると私は自信を持って予測できますし、その種のフリーな PuTTY は開発され続けるでしょう。フリーソフトウェアではその種の先例があります。もちろん、あなた以外の誰かがやると保証はできません。あなたが自分でやる必要があるかもしれません。ですが私たちがフリーの開発を止めても、誰かの自由な開発を妨げるものは何もないと約束できます。
(最後に、私たちが PuTTY をクローズドソースにして誰かがオープンソースのフォークを作ったならば、ほとんどの人がそちらに切り替えるとも自信を持って予測できます。そのため、クローズドソースにするのはとても馬鹿げています。)
Some people have asked us for an Export Control Classification Number (ECCN) for PuTTY. We don't know whether we have one, and as a team of free software developers based in the UK we don't have the time, money, or effort to deal with US bureaucracy to investigate any further. We believe that PuTTY falls under 5D002 on the US Commerce Control List, but that shouldn't be taken as definitive. If you need to know more you should seek professional legal advice. The same applies to any other country's legal requirements and restrictions.
Similarly, some people have asked us for FIPS certification of the PuTTY tools. Unless someone else is prepared to do the necessary work and pay any costs, we can't provide this.
We periodically receive requests like this, from organisations which have apparently sent out a form letter to everyone listed in their big spreadsheet of “software vendors” requiring them all to answer some long list of questions about supported OS versions, paid support arrangements, compliance with assorted local regulations we haven't heard of, contact phone numbers, and other such administrivia. Many of the questions are obviously meaningless when applied to PuTTY (we don't provide any paid support in the first place!), most of the rest could have been answered with only a very quick look at our website, and some we are actively unwilling to answer (we are private individuals, why would we want to give out our home phone numbers to large corporations?).
We don't make a habit of responding in full to these questionnaires, because we are not a software vendor.
A software vendor is a company to which you are paying lots of money in return for some software. They know who you are, and they know you're paying them money; so they have an incentive to fill in your forms and questionnaires, to research any local regulations you cite if they don't already know about them, and generally to provide every scrap of information you might possibly need in the most convenient manner for you, because they want to keep being paid.
But we are a team of free software developers, and that means your relationship with us is nothing like that at all. If you once downloaded our software from our website, that's great and we hope you found it useful, but it doesn't mean we have the least idea who you are, or any incentive to do lots of unpaid work to support our “relationship” with you.
It's not that we are unwilling to provide information. We put as much of it as we can on our website for your convenience, and if you actually need to know some fact about PuTTY which you haven't been able to find on the website (and which is not obviously inapplicable to free software in the first place) then please do ask us, and we'll try to answer as best we can. But we put up the website and this FAQ precisely so that we don't have to keep answering the same questions over and over again, so we aren't prepared to fill in completely generic form-letter questionnaires for people who haven't done their best to find the answers here first.
If you work for an organisation which you think might be at risk of making this mistake, we urge you to reorganise your list of software suppliers so that it clearly distinguishes paid vendors who know about you from free software developers who don't have any idea who you are. Then, only send out these mass mailings to the former.
sha1sums / sha256sums / etc files on your download page don't match the binaries.People report this every so often, and usually the reason turns out to be that they've matched up the wrong checksums file with the wrong binaries.
The PuTTY download page contains more than one version of the software. There's a latest release version; there are the development snapshots; and when we're in the run-up to making a release, there are also pre-release builds of the upcoming new version. Each one has its own collection of binaries, and its own collection of checksums files to go with them.
So if you've downloaded the release version of the actual program, you need the release version of the checksums too, otherwise you will see a mismatch. Similarly, the development snapshot binaries go with the development snapshot checksums, and so on. (We've colour-coded the download page in an effort to reduce this confusion a bit.)
Another thing to watch out for: as of 0.71, executables like putty.exe come in two flavours for each platform: the standalone versions on the website, each of which contains embedded help, and the versions installed by the installer, which use a separate help file also in the installer. We provide checksums for both; the latter are indicated with “(installer version)” after the filename.
If you have double-checked all that, and you still think there's a real mismatch, then please send us a report carefully quoting everything relevant:
いいえ。PuTTY はほとんど一から書かれたコードで成り立っています。 OpenSSH と共有しているコードは SSH-1 CRC compensation 攻撃の検出部分で、CORE SDI S.A によって書かれました。 OpenSSL のコードは含まれません。
このサイトでは買えません。ここにある PuTTY はコンピュータプログラムだけです。
オフィスのインテリアとして何か putty を買うなら、PuTTY チームは個人的に Thinking Putty をお勧めします。 Crazy Aaron's Putty World で購入できます: www.puttyworld.com.
みんなのための SSH/Telnet クライアントの名前です。それ以外の意味はそれを見た人の内にあります。 “PuTTY”は“getty”の対義語だとか、Windows を便利にするものだとか、プルトニウムテレタイプ (plutonium Teletype) の略だとか噂されてきました。そのような主張には私たちはとてもコメントできません。
英単語の“putty”と同じです。 /ˈpʌti/ (パティ) と発音します。
このマニュアルや PuTTY のツールに意見がある場合は、 Feedback page を参照してください。
翻訳についてはフィードバックから送信できます。
©1997-2025 Simon Tatham ©2015-2025 SATO Kentaro
[PuTTY custom build 0.83.ranvis-doc]