タイトル: エラー一覧
SEOタイトル: TeraTerm のよくあるエラーと対処法完全ガイド — Connection refused /
| この記事の要点 |
|
TeraTerm でよく出るエラー一覧
対象は Windows の Tera Term（SSH機能は TTSSH）です。接続前の名前解決・TCP接続、ホスト鍵確認、利用者認証、接続後の表示・切断を分けて確認します。画面名や対応形式は利用版で確認してください。
子ページからエラーを選択してください。実際の表示順は次のとおりです。
- SSH2秘密鍵の読み込みに失敗しました：ローカルでの鍵読込み段階。子ページの OpenSSH/PuTTY 向け権限・変換例を Tera Term へ一律適用しないでください。
- 認証に失敗しました。再試行してください。：このタイトルの子ページは現在 Git の認証を解説しています。Tera Term のSSH認証とは別であり、PAT発行やGit資格情報削除をSSHの対処にしないでください。本ページの「エラー2」「エラー5」で段階と方式を確認します。
Tera Term は Windows 用の SSH / Telnet / シリアル端末ですが、サーバ設定・ネットワーク・鍵管理など多岐の原因でエラーが出ます。代表的なエラーごとに切り分けと対処をまとめます。
エラー1: Connection refused
表示: 「接続が拒否されました」「Connection refused」
TCP接続が拒否された段階です。SSH認証に進む前の失敗で、待受ポートや経路上の拒否応答を確認します。次表の項目を順に変更するのではなく、接続先・実ポートと既存の管理記録を照合します。
| 原因 | 確認 | 対処 |
|---|---|---|
| SSH デーモン未起動 | サーバで systemctl status sshd | 管理者が停止理由と実際のサービス名を確認。確認だけで起動しない |
| ポート違い（標準 22 以外） | 管理者に実際の待受ポートを確認。設定ファイルの1行だけで稼働値を断定しない | 接続先の承認済みポートと Tera Term の TCP port を照合 |
| ファイアウォールで遮断 | サーバで firewall-cmd --list-all | firewalld 使用時の確認例。許可範囲・拒否記録を管理者に確認し、自動で開放しない |
| クラウド側 SG / NSG | AWS Security Group / Azure NSG | 接続元・宛先・実ポートの既存ルールを管理者に確認 |
| サーバ自体ダウン | 管理画面の稼働状態と到達性を確認（ping無応答だけで停止としない） | VPC / 電源確認 |
エラー2: Authentication failed
表示: 「Authentication failed.」「ユーザー名またはパスワードが正しくありません」
利用者認証の失敗と、その前のローカル秘密鍵読込み失敗を分けます。ユーザー名・選択方式・サーバーの許可方式を確認し、鍵やパスワードの誤りだけに断定しません。
- パスワード違い → 大文字小文字に注意、CapsLock 確認
- SSH 鍵のパス間違い → 「RSA/DSA/ECDSA/ED25519 鍵を使う」のファイルパスを再指定
- 鍵のパーミッション → Tera Term 実行ユーザーが秘密鍵を読めるか確認。OpenSSH の Unix 権限検査を Windows の Tera Term へ一律適用せず、広い読取権限も与えない
- 鍵フォーマット不一致 → TTSSH 2.63（Tera Term 4.76）以降は PuTTY 形式にも対応。対応する鍵形式・暗号化方式を利用版で確認し、拡張子だけで不可と判断したり原本を上書き変換したりしない
- パスフレーズ違い → 鍵のパスフレーズを再入力
- ユーザー名間違い → 作成時のイメージ・設定と管理者の案内を照合。下の旧一覧から候補を総当たりしない
次の一覧は旧参考例です。OS名やクラウド名だけでは実際のログイン名は確定できず、作成時の設定を優先します。
よく使うデフォルトユーザー名:
AWS Amazon Linux 2 → ec2-user
AWS Ubuntu → ubuntu
AWS RHEL / CentOS → ec2-user
AWS Debian → admin
GCP → 各 OS のデフォルト
さくらのクラウド → ubuntu / centos / rootエラー3: The host key is not registered
表示: 「セキュリティ警告 — 接続しようとしているホストのホスト鍵は登録されていません」
利用者認証より前のホスト鍵確認です。初回にも表示されますが、未登録であることは接続先が正当な証明ではありません。
- 初めて接続するホストは known_hosts に登録されていない
- 管理者から信頼できる別経路で得たフィンガープリントと一致した場合に限り、保存・続行を判断する
- 保存済みの接続先・鍵と一致すれば通常は警告なし。再表示されたときは未登録か鍵不一致かを確認する
ただし2 回目以降も警告が出る場合は要注意:
- 再構築は鍵変更の理由の一例。管理者の変更記録と信頼できるフィンガープリントを先に照合する
- 使用中のホスト鍵ファイルは「設定 → SSH」の SSH Known Hosts で確認する。固定のユーザーフォルダと決めつけない
- 照合できない場合は接続を中止する。警告を消す目的で登録鍵を削除しない
- 中間者攻撃の可能性もあるので、サーバ管理者にフィンガープリント確認
エラー4: Connection timed out
表示: 「接続できませんでした」「タイムアウト」
接続試行が時間内に完了しなかった状態です。無応答だけでは遮断場所を特定できません。名前解決・ICMP応答・指定ホストのTCP接続は別々の観測です。
| 切り分け | コマンド | 原因 |
|---|---|---|
| 名前解決 | nslookup hostname | DNS 設定不正 |
| 疎通 | ping hostname | ICMP 遮断 / ルーティング |
| ポート開通 | Test-NetConnection -ComputerName hostname -Port 22（Windows PowerShell。hostnameと22は実接続先・実ポートに置換） | TcpTestSucceeded はTCP接続の結果。失敗だけでFW原因と断定しない |
| 経路 | tracert hostname | 途中で応答しない機器もあるため、欠落だけで故障と断定しない |
| VPN | VPN 接続状態確認 | 社内ネットへのアクセス |
エラー5: Disconnected: No supported authentication methods available
表示: 「サーバが提供する認証方式に対応していない」
許可方式とクライアントの選択を照合します。PasswordAuthentication no でも公開鍵のみとは限らず、keyboard-interactive が許可されている場合があります。Tera Term では password と keyboard-interactive は別の選択で、自動的に別方式へ再試行されません。次は管理者が公開鍵認証を指定した場合の確認例です。
- 管理者にその接続で許可された認証方式を確認。接続を通すためにサーバーの認証設定を変更しない
- TeraTerm でパスワード認証ではなく「RSA/DSA/ECDSA/ED25519鍵を使う」を選択
- 秘密鍵ファイルを指定
エラー6: 漢字コード文字化け
サーバから受信した日本語が 譁?ュ怜喧縺? のように化ける:
- 利用版の文字コード設定を確認。旧版の「設定 → 端末」に対し、5系の現行マニュアルは「設定」の Additional settings / Encoding タブで受信・送信を説明しています
- 受信は実際に出力されたデータの文字コードに合わせる（UTF-8出力ならUTF-8）
- 送信は接続先アプリが期待する文字コードに合わせる。受信と異なる場合もある
- OK で適用、設定 → 設定の保存で
TERATERM.INIに保存
サーバーの locale は出力条件を調べる一要素で、保存済みファイルの文字コードまで保証しません。次の旧例では locale は表示ですが、export は現在のシェル環境を、localectl / update-locale は永続設定を変更します。文字化け診断として一括実行せず、対象アプリとデータの実際の文字コードを先に確認してください。
# サーバで実行
locale
# LANG=ja_JP.UTF-8 になっているか確認
# 一時的に切り替え
export LANG=ja_JP.UTF-8
# 永続化（CentOS / RHEL）
sudo localectl set-locale LANG=ja_JP.UTF-8
# Ubuntu
sudo update-locale LANG=ja_JP.UTF-8エラー7: SSH protocol version mismatch
表示: 「SSH バージョン不一致」
- クライアントと接続先でSSHプロトコル版が合わない場合がある。5系公式マニュアルでも TTSSH は SSH1/SSH2 対応で、「新しい Tera Term は SSH2 のみ」という説明は誤り
- SSH接続先・ポート・双方の対応版を確認。SSH2へ移行が必要なら管理者が互換性と移行計画を検討する
- 警告を回避するためにSSH1へ切り替えることは勧めない
エラー8: 突然切断される（Connection closed by remote host）
| 原因 | 対処 |
|---|---|
| サーバーがクライアントの応答なしを検出 | OpenSSH の ClientAliveInterval は応答要求の間隔。ClientAliveCountMax と実ログを合わせて確認し、単なる無操作時間と混同して値を増やさない |
| NAT / FW のセッションタイムアウト | 切断までの時間と装置の既存記録を確認。Keepalive は無通信時のパケット送信で、全切断の修復や60秒の一律設定を保証しない |
| サーバー側の接続・セッション制限 | OpenSSH に max_connections という設定名はない。MaxStartups（未認証接続）と MaxSessions（1接続内のセッション）を区別し、発生段階とログを確認。上限を自動で増やさない |
| シェルが exit した | 正常終了の場合あり |
キープアライブは「設定 → SSH」の Keepalive で確認します。無通信時の指定間隔で送信し、0は無効です。変更はネットワーク管理方針に従い、切断理由の確認とは分けます。
エラーログの確認
権限のある管理者が、失敗時刻・接続元とサーバー側SSHログを照合します。次の旧例のファイルやサービス名はOS・ログ設定に依存し、存在しないだけで異常とは限りません。sudo権限の新規付与はせず、共有時はユーザー名・IP等を必要範囲で伏せます。
# CentOS / RHEL
sudo tail -f /var/log/secure
# Ubuntu / Debian
sudo tail -f /var/log/auth.log
# systemd journal
sudo journalctl -u sshd -f一次資料：Tera Term SSH接続・ホスト鍵確認、SSH設定、5系の文字コード設定、設定ファイル指定、OpenSSH sshd_config、Test-NetConnection、接続拒否・タイムアウト・名前解決の区別。
FAQ
Q: パスワード正しいのに Authentication failed
A: ユーザー名間違いを疑う。AWS なら ec2-user 等、サーバごとのデフォルト確認。root ログインは多くのサーバで無効化されています。
Q: 接続できていたのに急にできなくなった
A: 接続拒否・タイムアウト・ホスト鍵警告・利用者認証失敗のどこで止まったかを確認し、失敗時刻と接続先の変更記録を管理者に照合。ホスト鍵警告は鍵削除で消さず、相手の身元確認を優先します。
Q: TeraTerm を起動するたびに設定が初期化される
A: 保存忘れとは限りません。実際に読み込む設定ファイル（起動引数 /F を含む）と保存先・書込可否を確認します。5系では相対指定の基点も利用版のマニュアルで確認し、意図した設定だけを保存します。
Q: SCP でファイル転送したい
A: TeraTerm メニュー → ファイル → SSH SCP でダイアログから送受信できます。
公式仕様の確認先：Tera Term5 SSH、OpenSSHサーバー設定（2026-10-28確認）。画面・設定・コードは対象版と各例の前提条件を照合してください。