この記事の要点
Tera Term の秘密鍵読込み失敗は、まずローカルのファイル指定・形式・暗号化・パスフレーズ・読取可否を切り分ける。サーバーの認証拒否とは別 形式は拡張子だけで判断せず、Tera Term / TTSSH の版と鍵形式・暗号化方式を照合する。Tera Term 5 も OpenSSH / PuTTY 形式を扱う 暗号化された秘密鍵には、その鍵のパスフレーズが必要。サーバーのログインパスワードとは別 Tera Term を実行するユーザーが指定した鍵を読めるか確認。OpenSSH の Unix 権限検査を Windows の Tera Term へ一律適用しない 鍵の新規生成・原本の上書き変換・パスフレーズ解除・権限変更は自動対処にしない。下の旧コマンド例は各直前の条件と注意を先に読む

 

エラーの状況

対象は Windows の Tera Term 5（SSH機能は TTSSH）です。まず実際の鍵ファイルの場所、選択した認証方式、Tera Term / TTSSH の版を確認します。公開鍵（.pub）ではなく対応する秘密鍵を指定し、ファイルの存在と実行ユーザーの読取可否、形式・暗号化方式、パスフレーズを照合します。秘密鍵本文やパスフレーズは第三者へ送らないでください。公式の鍵指定・認証方式を参照してください。

次はクライアント別の旧表示例です。先頭の Tera Term の例と PuTTY の実際の表示文言を同一視しません。後半は OpenSSH の例で、bad permissions とファイルを開けない Permission denied を区別します。ssh -i はサーバーへ接続する命令であり、ローカルの鍵だけを調べる例ではありません。

# Tera Term / PuTTY 等で
SSH2 秘密鍵の読み込みに失敗しました。

# OpenSSH コマンドラインから
$ ssh -i ~/.ssh/id_rsa user@server
Load key "/home/user/.ssh/id_rsa": bad permissions
Permissions 0644 for ".ssh/id_rsa" are too open.

# または
Load key "/home/user/.ssh/id_rsa": Permission denied

原因と対処

原因 1: ファイルの読取可否とクライアント別の権限条件

次は OpenSSH 向けの旧例です。Unix の秘密鍵は本人が読め、他者にアクセスを許さない状態が必要ですが、400だけが唯一の正解ではなく600もこの条件を満たします。Tera Term では実行ユーザーの読取可否を確認し、権限を広く付与しません。chmod / icacls は確認ではなく変更です。所有者・現在の権限・管理方針と復帰手段を確認せず実行しないでください。Windows は所有者とACLを別に確認します。下の %USERNAME% はcmd.exe向けで、PowerShellの変数構文ではありません。/inheritance:r は継承ACEを除去し、/grant:r は指定ユーザーの明示許可を置換しますが他者のACEすべてを除去しません。F（フルコントロール）付与とUsers除去の一括適用を勧めず、この3行だけで適切なACLになると保証しません。根拠：sshの秘密鍵条件、Windows OpenSSHの鍵保護、icacls。

# 秘密鍵は所有者のみ読み取り可能でなければならない
$ ls -l ~/.ssh/id_rsa
-rw-r--r-- 1 user user 1675 May 15 12:00 id_rsa
# ↑ others が読める → 拒否される

# 修正
$ chmod 400 ~/.ssh/id_rsa
$ ls -l ~/.ssh/id_rsa
-r-------- 1 user user 1675 May 15 12:00 id_rsa

# .ssh ディレクトリ自体も
$ chmod 700 ~/.ssh

# Windows
> icacls C:\Users\user\.ssh\id_rsa /inheritance:r
> icacls C:\Users\user\.ssh\id_rsa /grant:r "%USERNAME%:F"
> icacls C:\Users\user\.ssh\id_rsa /remove "BUILTIN\Users"

原因 2: OpenSSH 形式と旧形式の不整合

OpenSSH 7.8は秘密鍵の既定保存形式をOpenSSH形式に変更しましたが、これをTera Term 5の非対応理由にはできません。Tera TermはOpenSSH形式を扱い、PuTTY形式はTTSSH 2.63（Tera Term 4.76）以降、PPK3はTTSSH 2.92（Tera Term 4.106）以降で対応しています。PuTTYの0.74以前という境界はPPK3の読込み条件であり、OpenSSH形式全般の境界ではありません。公式履歴には、5.7.0（TTSSH 3.7.0）で発生したPPKのDSA/RSA/ECDSA鍵読込み不具合の5.7.1修正と、5.6.2でのPuTTY Ed25519鍵読込み修正もあります。利用版と鍵種別を照合し、すべての鍵で同じ不具合が起きるとは判断しません。

次は旧変換例で、通常の解決手順ではありません。枠内の「古いツール非対応」「旧PEM形式（互換）」は全クライアントへの保証ではありません。PEM変換は対応する鍵種別に限り、Ed25519にはこの旧PEM変換を適用できません。ssh-keygen -p -m PEM -f は指定鍵を書き換えます。承認された互換性対応で必要な場合のみ、原本を保護して別名の作業コピーを対象とし、既存の暗号化保護を維持してください。空の新パスフレーズを選ばず、原本で試しません。ヘッダーだけでは暗号化方式・内容の健全性まで分かりません。根拠：ssh-keygen、PuTTYgenの形式・鍵種別条件。

# 形式確認
$ head -1 ~/.ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----   ← 新形式 (古いツール非対応)
-----BEGIN RSA PRIVATE KEY-----       ← 旧 PEM 形式 (互換)

# 新形式を旧形式（PEM）に変換
$ ssh-keygen -p -m PEM -f ~/.ssh/id_rsa
Enter old passphrase: ****
Key has comment ...
Enter new passphrase (empty for no passphrase): ****
Enter same passphrase again: ****
Your identification has been saved with the new passphrase.

# 確認
$ head -1 ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----   ← 旧形式に変換完了

原因 3: PuTTY 形式 (.ppk) と OpenSSH 形式の混同

id_rsaは慣例的なファイル名で形式名ではありません。PuTTYの秘密鍵形式はPPKで、PuTTYgenはOpenSSH形式の取込み・書出しに対応します。PPK3はPuTTY 0.75以降向けで、0.74以前では読めません。PPK2への降格は暗号化鍵の総当たり耐性を弱めるため、自動対処にしません。Tera Term 5でPPKを使うために必ず変換する必要もありません。形式だけでなく鍵種別・暗号化・利用版を確認します。

次は製品間変換の旧例です。sudo apt install は依存追加であり鍵の確認ではありません。未導入ならまず管理者の承認を確認します。-o の出力先が既存鍵と重ならない別名であることを確認し、秘密鍵の保管権限とパスフレーズ保護を維持してください。特に最後の -o ~/.ssh/id_rsa は既存OpenSSH鍵を上書きし得るため、そのまま使いません。PuTTYgenで既存鍵を読み込む変換と、新鍵の生成は別です。根拠：PuTTYgenのPPK版・取込みと書出し。

# OpenSSH → PuTTY (.ppk)
# Windows: PuTTYgen を使用
# Tera Term は OpenSSH 形式を直接使える

# Linux: puttygen コマンド
$ sudo apt install putty-tools
$ puttygen ~/.ssh/id_rsa -O private -o ~/.ssh/id_rsa.ppk

# PuTTY → OpenSSH
$ puttygen id_rsa.ppk -O private-openssh -o ~/.ssh/id_rsa

原因 4: パスフレーズ間違い

暗号化された鍵には保存時のパスフレーズが必要です。選択鍵の取り違え、大文字小文字・IME・不要な空白を確認し、サーバーのログインパスワードと混同しません。次の ssh-keygen -p は確認専用ではなく鍵のパスフレーズ変更です。後半の空入力は暗号化保護を解除するため、読込み失敗の対処として実行しません。「リセット」は忘れたパスフレーズの回復を意味せず、元の値を知らずに変更することはできません。紛失時は管理者に承認済みの復旧経路を相談し、新鍵生成・サーバー登録を自動で行わないでください。根拠：ssh-keygenの-pとパスフレーズ。

# パスフレーズが正しいか確認
$ ssh-keygen -p -f ~/.ssh/id_rsa
Enter old passphrase: (入力)
# パスフレーズが間違っていれば「passphrase is incorrect」

# パスフレーズなしに変更
$ ssh-keygen -p -f ~/.ssh/id_rsa
Enter old passphrase: ****  (現在のパスフレーズ)
Enter new passphrase (empty for no passphrase):  (空でEnter)
Enter same passphrase again:  (空でEnter)

# パスフレーズリセット (鍵自体は同じ、暗号化のみ変更)

原因 5: 鍵ファイルが破損

次は旧確認・変換例です。1.6KB～3.4KBというサイズだけで正常・破損を判断できません。鍵種別・形式・暗号化で大きさは変わります。原本を保持し、取得元の正常な控えと照合します。head は秘密鍵本文を端末・ログへ出すため、画面共有中などに実行したり出力を公開したりしません。CRLFだけで破損と断定せず、dos2unix による原本の書換えを初手にしません。修正が必要と確認できた場合だけ保護した作業コピーで検討し、本文を手作業で継ぎ足さないでください。鍵の秘密保持はTera Term公式の注意も参照してください。

# サイズ確認
$ ls -l ~/.ssh/id_rsa
# 普通は 1.6KB - 3.4KB 程度

# 内容確認
$ head ~/.ssh/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABDx...

# 改行コードが Windows (CRLF) になっている場合は LF に変換
$ dos2unix ~/.ssh/id_rsa

新しい鍵ペアの生成は別の判断

次は旧生成・登録例で、この読込みエラーの推奨対処ではありません。新鍵が必須とは限りません。紛失・漏えい等で交換が必要と管理者が判断した場合に、別名保存先・対応鍵種別・公開鍵の登録先・既存アクセスを保つ移行計画を確認します。-fを省略した例は既定名の既存鍵と衝突し得るため、上書きを承認しないでください。-N ""は保護なしの秘密鍵を作るため安易に使用しません。ssh-copy-idと末尾のssh/catはサーバーへの接続・公開鍵登録を伴い、読込み診断ではありません。また末尾は既定のid_ed25519.pubを参照し、直前のid_ed25519_workやRSA鍵とは一致するとは限りません。各行を連続実行せず、登録する公開鍵の対応を確認します。秘密鍵はサーバーへ転送しません。根拠：鍵生成の指定、OpenSSH公開鍵認証。

# Ed25519 (推奨、最新)
$ ssh-keygen -t ed25519 -C "your@email.com"

# RSA 4096 bit (互換性重視)
$ ssh-keygen -t rsa -b 4096 -C "your@email.com"

# 出力ファイル名指定
$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work

# パスフレーズなし (自動化用、推奨されない)
$ ssh-keygen -t ed25519 -N ""

# 公開鍵をサーバにコピー
$ ssh-copy-id user@server

# または手動
$ cat ~/.ssh/id_ed25519.pub | ssh user@server "cat >> ~/.ssh/authorized_keys"

各 SSH クライアントでの鍵設定

Tera Term

1. 「設定」 → 「SSH 認証」
2. 「RSA / DSA / ECDSA / ED25519 鍵を使う」を選択
3. 「秘密鍵」で対応する秘密鍵ファイルを指定。id_rsaは名前の一例で、.pubは選ばない。日本語や空白のあるパスだけで不適合と断定せず、実在するフルパス・読取可否と利用版を照合する。起動引数の/keyfileを使う場合、相対パスは設定ファイルフォルダー基準で、空白を含む値は引用が必要。公式の引数・パス規則を確認し、鍵を移動するだけの対処にしない
4. 暗号化した鍵のパスフレーズを入力。設定メニューは既定値の設定で、接続時にもユーザー名と選択方式を確認。Pageant選択時はTTSSH自身が秘密鍵ファイルを扱う経路とは異なる

PuTTY

1. セッション設定の「Connection」 → 「SSH」 → 「Auth」を確認。PuTTY 0.85の鍵ファイル欄は配下の「Credentials」にあるため利用版の画面を確認
2. 「Private key file for authentication」で .ppk 指定
3. パスフレーズはセッション開始時に入力

OpenSSH (Linux/Mac)

次はOpenSSHの別クライアント向け旧接続・設定例で、Tera Termの設定ではありません。user@server・IP・User・Portは説明用なので、承認済みの接続先と対応鍵へ置き換えます。ssh はネットワーク接続を行い、configへの追記は以後の接続設定を変更します。既存の設定全体を置き換えず、ホスト鍵警告を無視しません。鍵を読めても接続先・利用者名・サーバーの許可方式・公開鍵登録・署名方式等により認証は別途失敗し得ます。根拠：ssh、sshdの公開鍵認証。

# コマンドラインで
$ ssh -i ~/.ssh/id_rsa user@server

# config ファイルに登録 (~/.ssh/config)
Host myserver
    HostName 192.168.1.100
    User myuser
    IdentityFile ~/.ssh/id_rsa
    Port 22

# 接続
$ ssh myserver

VSCode Remote SSH

次はVS Code Remote - SSHの旧設定断片で、Tera Termの鍵読込みを直す設定ではありません。remote.SSH.configFile は使用するSSH設定ファイルの指定です。既存settings.jsonを断片で上書きせず、実際のファイル位置と拡張機能の対応クライアントを確認してください。接続時はリモート環境のセットアップも伴い得るため、鍵の読込み確認だけの目的で開始しません。根拠：Remote - SSH公式。

# settings.json
{
    "remote.SSH.configFile": "~/.ssh/config"
}

# .ssh/config に Host を定義してから VSCode で接続

SSH エージェント活用

次は任意のエージェント導入の旧例で、鍵読込み失敗の初手ではありません。evalはプロセス起動と現在のシェル環境の変更、ssh-addは鍵のエージェント登録、.bashrcの追記は次回以降の起動処理変更、Start-ServiceはWindowsのサービス開始です。利用中のエージェントと管理方針を確認し、一括実行・起動の重複・エラーの抑制を避けます。「以後そのターミナルでは入力不要」は登録成功・同じエージェントを使うプロセス・鍵の保持期限等に依存します。Tera TermのPageant選択とOpenSSHのSSH_AUTH_SOCK / ssh-agentを同一視せず、エージェント利用は秘密鍵のパスフレーズ解除とは別に判断します。根拠：ssh-agent、Windows OpenSSH鍵管理、Tera TermのPageant選択。

# Linux/Mac
$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/id_rsa
Enter passphrase: ****
# → 以後そのターミナルではパスフレーズ入力不要

# ~/.bashrc で自動起動
if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/id_rsa 2>/dev/null
fi

# Windows OpenSSH (Win10+)
Start-Service ssh-agent
ssh-add ~/.ssh/id_rsa

関連エラー

• Permission denied (publickey): 公開鍵認証が成立していない。公開鍵の未登録だけに断定せず、接続先・利用者名・提示鍵・サーバーの許可方式やログを管理者と照合する
• Host key verification failed: サーバーのホスト鍵確認が成立していない。利用者の秘密鍵読込みとは別で、未登録と変更・不一致を区別し、信頼できる別経路で照合するまで受け入れない。known_hosts削除を自動対処にしない
• Connection refused: 認証前のTCP接続拒否。接続先・実ポート・待受や拒否応答を確認し、SSHサーバー停止やファイアウォールだけに断定しない
• Bad owner or permissions on .ssh/config: OpenSSH設定ファイルの所有者・権限を確認するエラー。秘密鍵のエラーと分け、chmod 600だけで所有者・ACLを含む全問題が直ると保証しない

関連エラーの確認先：OpenSSHクライアント、OpenSSHサーバー認証、WindowsのTCP接続拒否。Tera Termの接続段階は実親のエラー一覧で確認できます。

関連記事

• git
• Cannot rebase: You have unstaged changes