MS_KiTTYPuTTY - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

KiTTY(PuTTY)

概要

  • PuTTY は、Windows の SSH、telnet クライアント、SSH 接続は、下記参考の通り行う。
  • KiTTY は フランス発プロジェクト PuTTY の派生で、Windows の GUI で便利に使えるようにした版。

ダウンロード

インストール

デフォルト設定でインストール

補足（PuTTY を使う最大の理由は「同梱ツール」）: 接続クライアントとしては
OpenSSHやRLoginで足りるが、
PuTTY には付属ツールに固有の価値がある。

ツール 役割
putty.exe 接続クライアント（GUI）
puttygen.exe 鍵の生成・変換（後述）
plink.exe CLI 版。バッチやスクリプトから使える
pscp.exe / psftp.exe ファイル転送
pageant.exe SSH エージェント（鍵をメモリに保持）

特に puttygen は、.ppk 形式と OpenSSH 形式の相互変換ができる
唯一の手軽な手段である。

【よくある場面】
  AWS / Azure からダウンロードした .pem（OpenSSH 形式）
     ↓ puttygen で変換
  PuTTY で使える .ppk 形式

  逆に、.ppk しか渡されなかった場合
     ↓ puttygen の Export → OpenSSH key
  ssh コマンドで使える形式

鍵の形式が合わずに接続できないという問題は頻出するため、
PuTTY を接続に使わなくても
puttygen だけは入れておくという運用は珍しくない。

公開鍵

キー生成

puttygen.exeを起動

Generateボタンを押下

（Please generate some randomness by moving the mouse over the blank area.）

→ 押下後、マウスカーソルを動かしてキー生成。

生成されたキーを保存

  • 公開鍵を上部テキストから取得
  • 秘密鍵をファイルに保存（passphrase は空のまま）

補足（マウスを動かす理由と、passphrase の扱い）: 2 点補足する。

① なぜマウスを動かすのか
鍵の生成には予測不可能な乱数が必要である。
ソフトウェアだけでは真の乱数を作れないため、
人間のマウス操作という物理的な揺らぎをエントロピー源にしている。
予測可能な乱数で作られた鍵は解読され得るため、
この手順には意味がある。

② passphrase を空にすることの是非
本文は「passphrase は空のまま」としているが、
これは自動化を前提とした選択である。

passphrase あり passphrase なし
鍵ファイルが漏れたら まだ守られる 即座に悪用される
自動実行（バッチ、CI） 都度入力が必要（agent が要る） そのまま使える

つまり、秘密鍵ファイル 1 つで侵入できる状態になる。
したがって、

  • 対話的に使う鍵は passphrase を設定する（pageant に登録すれば都度入力は不要）、
  • 自動化用の鍵は passphrase 無しでもよいが、
    ファイルの権限を厳格にし、用途と接続先を限定する
    （authorized_keys 側で command= や from= で制限できる）

という使い分けが正しい。

なお、鍵の種類も選択できる。現在は

種類 評価
Ed25519 現在の推奨。短く、速く、安全
ECDSA 可
RSA 3072/4096 互換性重視ならこれ
RSA 1024、DSA 使ってはいけない

となる。

キー配置

公開鍵をサーバの「~/.ssh/authorized_keys」ファイルに追加する。

.sshディレクトリの作成

mkdir ~/.ssh

authorized_keysファイルの作成

vi ~/.ssh/authorized_keys

authorized_keysファイルに公開鍵を[ペースト](#terminalvi にコピペ)

接続テスト

SSHサーバと接続をテスト

plink.exe を使用して接続テストする。

c:\...\plink.exe -i c:\...\ssh-key.ppk xxxx@yyyy -batch -T echo "hello world"
REM 'hello world' should print

初回は以下の表示がある。

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's ssh-ed25519 key fingerprint is:
ssh-ed25519 255 ae:c6:f5:99:ab:41:39:ad:7d:fa:8b:9a:8d:bd:c0:24
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y

補足（このメッセージを「とりあえず y」で流してはいけない）: これは
ホスト鍵の検証であり、中間者攻撃を検知する唯一の仕組みである。

【正常】 初回のみ表示 → y で登録 → 2 回目以降は出ない

【異常】 2 回目以降に「WARNING - POTENTIAL SECURITY BREACH!」
           ↑ サーバの鍵が変わった＝
             ・サーバを再構築した（正当）
             ・別のサーバに繋がされている（攻撃）

初回接続時に本当にそのサーバかを確認する正しい方法は、
別経路でフィンガープリントを入手して照合することである。

# サーバ側（コンソールなど、SSH 以外の手段で）で確認
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

実務では省略されがちだが、
インターネット越しに初めて繋ぐ相手では実施する価値がある。

なお、plink をバッチから使う場合、
未登録のホストだと確認待ちで止まる。
本文の例が -batch を付けているのはこのためで、
-batch は対話プロンプトを出さずに失敗させる。
事前に一度手動で接続して登録しておく必要がある
（または -hostkey でフィンガープリントを明示する）。

ハマり所

ハマり所のメモ。

Terminal＋vi にコピペ

公開鍵を、

補足（この作業でよくある失敗）: 公開鍵の貼り付けは
単純に見えて失敗しやすい。原因は 3 つある。

失敗 内容
改行が入る 公開鍵は1 行でなければならない。折り返して貼ると壊れる
vi の自動インデント ペースト時に階段状にずれる。:set paste で回避
形式の取り違え .ppk の中身を貼ってはいけない。puttygen 上部の「OpenSSH 形式の公開鍵」を貼る

3 つ目が本文の「公開鍵を上部テキストから取得」の意味である。
puttygen の画面上部に表示される

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... rsa-key-20250101

という1 行の文字列が authorized_keys に貼るべきものであり、
「Save public key」で保存したファイルの中身は
RFC4716 形式（複数行、ヘッダ付き）でそのままでは使えない。

貼り付けミスを避けるなら、
ファイルとして転送して cat で追記する方が確実である。

cat id_ed25519.pub >> ~/.ssh/authorized_keys

パーミッション

ファイル属性のパーミッションについては、コチラ。

.sshディレクトリ

755 でないと正しく動作しない。

$ cd ~/
$ ls -al
total xx
...
drwxrwxrwx 1 seigi seigi   512 Aug 20 13:29 .ssh
$ chmod 755 .ssh
$ ls -al
total xx
...
drwxr-xr-x 1 seigi seigi   512 Aug 20 13:29 .ssh

authorized_keysファイル

644 または 600 でないと正しく動作しない。

$ cd ~/.ssh
$ ls -l
total 0
-rw-rw-rw- 1 seigi seigi 398 Aug 20 13:12 authorized_keys
$ chmod 600 authorized_keys
$ ls -l
total 0
-rw------- 1 seigi seigi 398 Aug 20 13:12 authorized_keys

補足（なぜパーミッションが厳格に検査されるのか）: sshd は
**「他人が書き込める場所に置かれた鍵は信用しない」**という方針を取る。
理由は明確で、

もし ~/.ssh/authorized_keys が誰でも書き込める（666）状態なら
   ↓
悪意ある別ユーザが自分の公開鍵を追記できる
   ↓
そのユーザとして自由にログインできてしまう

したがって、書き込み権限が要点である。

対象 推奨 条件
ホーム ディレクトリ 755（drwxr-xr-x） グループ／その他に書き込み権を与えない
~/.ssh 700 または 755 同上
authorized_keys 600 または 644 同上
秘密鍵 600 他人に読ませない

本文が 755 / 644 も可としているのは、
「読めてもよいが、書けてはいけない」という基準だからである
（公開鍵は秘密ではない）。
ただし、秘密鍵だけは 600 必須である（読まれてもいけない）。

なお、ホーム ディレクトリ自体の権限も検査対象である点は
見落とされやすい。~ が 777 だと .ssh が正しくても弾かれる。

原因を調べるには、サーバ側で sshd のログを見るのが確実である。

# /var/log/secure または /var/log/auth.log
Authentication refused: bad ownership or modes for directory /home/user

このメッセージが出ていれば権限の問題で確定する。
OpenSSHで触れたクライアント側の秘密鍵の権限と
対になる話である。

参考

Tags: 移行, Windows, Linux

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️