WindowsからLinuxへSSH接続できないときの確認手順｜エラー別に切り分ける

最初に、操作する画面とエラー表示を確認する

SSHで接続できないときは、表示されたエラーから確認する場所を絞ります。このガイドは、SSH接続の基礎記事と同じ学習環境を使う目的別ガイドです。Windows 11のx64 PC、VirtualBox 7.2、AlmaLinux 9、Linuxユーザー labuser を前提にしています。該当する症状の節から進めてください。

VirtualBoxで直接開くLinuxの画面を、ここではコンソールと呼びます。SSHが使えなくても、仮想マシンが正常に起動していれば、この画面からLinuxを操作できます。PowerShellで以前のSSH接続が開いたままなら、新しいPowerShellを開いてください。

まずWindowsで、SSHクライアントが使えるか確認します。

ssh -V

OpenSSHを含むバージョンが表示されれば、次の接続コマンドを実行します。「認識されません」と表示された場合は、先に基礎記事のWindowsでSSHクライアントを確認する手順へ進みます。

ssh -p 2222 labuser@127.0.0.1

-p 2222はWindows側で接続するポート番号です。127.0.0.1は、そのコマンドを実行しているコンピューター自身を表します。この接続コマンドはWindowsで実行します。VirtualBoxがWindowsの2222番ポートからLinuxの22番ポートへ通信を転送します。

接続待ちのまま進まない場合は、WindowsのPowerShellで Ctrl＋C を押して接続の試行を中止し、入力待ちに戻ってから次の確認を行います。ssh: connect to host ... port ...: Permission deniedと出た場合は認証前の接続エラーなので、Windows側の接続確認へ進みます。

エラー名だけでは原因を一つに決められません。表示された全文を残し、設定を一つ確認・修正するごとに、同じ接続コマンドで変化を確かめます。初回の接続確認が出た場合も、ホスト鍵のフィンガープリントを照合してから接続してください。

接続拒否・タイムアウト：仮想マシンとポート転送を確認する

VirtualBoxマネージャーで linux-lab を確認します。「電源オフ」なら起動し、「一時停止」なら再開します。Linuxのログイン画面が出るまで待ってから、WindowsのPowerShellで次を実行します。

Test-NetConnection -ComputerName 127.0.0.1 -Port 2222

結果の TcpTestSucceeded を見ます。Trueなら、その時点でWindowsの2222番ポートへのTCP接続は成功しています。LinuxのSSHサーバーが応答したことや、ログインできることまでは確認できません。次のLinux側の確認へ進みます。Falseなら、以下の転送設定を確認します。PingSucceededだけで判断しないでください。

VirtualBoxの「設定（Settings）」→「ネットワーク（Network）」→「アダプター1（Adapter 1）」で、アダプターが有効、割り当てがNAT、「ケーブル接続（Cable Connected）」が有効になっているか確認します。「ポートフォワーディング（Port Forwarding）」のSSH用ルールは次の内容です。

ホストはWindows、ゲストは仮想マシン内のLinuxです。設定を変更する必要がある場合は、Linuxのコンソールで次を実行し、VirtualBoxの状態が「電源オフ」になってから編集します。

sudo poweroff

設定を保存したら仮想マシンを起動し、TCP接続の確認をやり直します。別の仮想マシンで同じホストポート2222を使っていると競合するため、同時に起動している仮想マシンのルールも確認します。ポートを使うアプリが不明な場合は、強制終了せず、最後の節の情報をそろえて調べます。

参照：MicrosoftのTCP接続確認、OracleのNATポート転送

Linux側でSSHサービスと通信の許可を確認する

ここからはVirtualBoxのLinuxコンソールで操作します。labuserでログインしてください。SSH接続を受け付けるサービスの名前は sshd です。

systemctl status sshd --no-pager

サービスが停止していた場合だけ、起動と次回以降の自動起動を設定します。

sudo systemctl enable --now sshd

failedが表示された場合や、起動できない場合は、設定ファイルとホスト鍵の検査を実行します。エラーが出たら、その内容を残します。何も表示されず入力待ちに戻れば、この検査では問題が見つかっていません。接続成功を保証する検査ではないため、ログも確認します。原因に該当する設定を修正した場合は、検査をやり直してから上の起動コマンドを実行し、状態を再確認します。

sudo /usr/sbin/sshd -t

22番ポートで接続を待っているか

サービスが実行中なら、TCPの22番ポートを調べます。

sudo ss -lntp 'sport = :22'

LISTENは接続待ちの状態です。この学習環境では、Local Address:Portに 0.0.0.0:22、Processに sshd を含む行が目安になります。0.0.0.0はLinux内のすべてのIPv4アドレスを指します。先ほどのVirtualBoxのホストIPとは別の設定です。

見出しだけで行がない場合や、127.0.0.1:22だけの場合は、NATから接続を受けられる待ち受けになっていません。SSHのポートや待ち受けアドレスを変更した覚えがないか確認し、ログを調べます。

firewalldでSSHが許可されているか

firewalldは、Linuxで許可する通信を管理するソフトウェアです。まず実行中か確認します。

systemctl is-active firewalld

activeなら次へ進みます。それ以外なら、基礎記事の導入・起動手順を確認します。停止しているという表示だけで、今回の接続失敗の原因とは断定できません。

sudo firewall-cmd --get-active-zones

public
  interfaces: enp0s3

ゾーンは、許可する通信をまとめた設定です。この例ではネットワークインターフェース enp0s3 に public が適用されています。以下の public は、実際のゾーン名に合わせてください。インターフェースの行が出ないときは、先にLinuxのネットワーク接続状態を確認します。

sudo firewall-cmd --zone=public --query-service=ssh
sudo firewall-cmd --permanent --zone=public --query-service=ssh

1行目は現在有効な設定、2行目は再起動後にも使う永続設定です。両方が yesなら許可済みです。どちらかが noの場合だけ、同じゾーンにSSHの許可を追加します。

sudo firewall-cmd --zone=public --add-service=ssh
sudo firewall-cmd --permanent --zone=public --add-service=ssh

この2行は、現在の設定と永続設定をそれぞれ変更します。successまたは既に許可済みを示す ALREADY_ENABLED を確認し、上の照会を再実行します。両方が yesになったらWindowsから接続を試します。

Permission denied：ユーザー名と認証方法を確認する

パスワード入力後の Permission denied, please try again.や、labuser@127.0.0.1: Permission denied (...)は、認証に失敗したという意味です。何度も入力し直す前に、次の順で確認します。パスワード認証で接続する、この学習環境を対象とした手順です。

1. 接続コマンドが labuser@127.0.0.1 になっているか確認します。labuserはWindowsのユーザー名ではなく、AlmaLinuxのインストール時に作ったユーザー名です。
2. 入力するのはLinuxのlabuserのパスワードです。WindowsのPINではありません。パスワード入力中に文字や ＊ が表示されないのは通常の動作です。
3. VirtualBoxのLinuxコンソールがログイン画面なら、同じユーザー名とパスワードでログインできるか確認します。既にログイン済みなら、その画面はログアウトせずに残し、SSHサービスのログ確認に使います。

公開鍵認証は、ユーザーの鍵を使ってログインを許可する方法です。パスワードの入力ミスとは対処が異なります。既に鍵でログインするよう設定した環境なら、その設定で使用する鍵を確認します。認証方法が分からないまま設定を上書きせず、表示された認証方式と最近変更した設定を照合してください。

ホスト鍵が変わったときは、接続先を確かめてから登録を更新する

REMOTE HOST IDENTIFICATION HAS CHANGED!は、Windowsに記録されたホスト鍵と、今回の接続先が提示した鍵が異なるという警告です。ホスト鍵はSSHサーバーを識別するための鍵で、ユーザーのログイン用パスワードや認証用の鍵とは役割が異なります。

仮想マシンを再インストールした場合などにも起こります。まず接続を中止し、次の3点を確認します。

1. Linuxの再インストールや仮想マシンの作り直しなど、鍵が変わる理由を説明できるか。
2. VirtualBoxで、意図した linux-lab を起動しているか。
3. Windowsの2222番ポートの転送先が、その仮想マシンになっているか。

次に、VirtualBoxのLinuxコンソールでホスト鍵のフィンガープリントを表示します。フィンガープリントは公開鍵から計算する確認用の値で、鍵本体ではありません。警告の中で今回の接続先が提示した鍵の方式を確認します。古い登録の鍵方式と取り違えないでください。今回提示された鍵が ED25519 の場合は次を使います。

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub

256 SHA256:〈公開鍵から計算された値〉 … (ED25519)

警告に ECDSAまたは RSA と表示されている場合は、次のコマンドで対応する鍵を確認します。.pubは公開鍵のファイルです。

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ecdsa_key.pub
ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_rsa_key.pub

Windowsの警告に表示された新しい鍵のフィンガープリントと、Linuxのコンソールで確認した値を照合します。同じ鍵方式の SHA256:から始まる文字列が、最後まで一致するかを確認してください。ファイルが見つからない場合は、確認のために新しい鍵を生成せず、対象の仮想マシンと鍵方式を調べ直します。

ssh-keygen -R "[127.0.0.1]:2222"

このコマンドは、Windowsユーザーの known_hosts（接続先の公開鍵を記録するファイル）から、127.0.0.1:2222に対応する登録だけを削除します。ファイル全体を削除する操作ではありません。

最初のSSHコマンドで再接続し、初回と同じ確認が出たら、もう一度フィンガープリントを照合してからyesを入力します。鍵の確認を省略する設定に変更する必要はありません。

参照：OpenSSHのフィンガープリント表示と接続先を指定した登録削除

解消しない場合は、接続直後の表示とログをそろえる

ここまで確認しても接続できない場合は、Windowsで接続経過を詳しく表示します。-vは診断用の表示を増やす指定、ConnectTimeout=10は接続や初期のSSH通信を待つ時間を10秒にする指定です。パスワード入力の制限時間ではありません。

ssh -v -o ConnectTimeout=10 -p 2222 labuser@127.0.0.1

再試行した直後に、VirtualBoxのLinuxコンソールでSSHサービスのログを読みます。ログは、起きたことを時刻とともに記録したものです。

sudo journalctl -u sshd -n 30 --no-pager

-u sshdでSSHサービスに絞り、-n 30で最近の30件を表示します。今の再試行に対応する時刻を探してください。Failed passwordならパスワード認証の失敗、Invalid userなら指定されたユーザーが存在しないことが手がかりです。接続したはずの時刻に記録がなくても、それだけで通信が届いていないとは断定できません。

調べるときや人に相談するときは、次の情報をまとめます。公開する場合はユーザー名や個人のフォルダー名などを必要に応じて伏せ、パスワードや秘密鍵は共有しないでください。

• 最初から接続できないのか、接続できていたものが急に失敗したのか
• Windowsで実行した接続コマンドと、エラーの全文
• TcpTestSucceeded、sshdの状態、22番ポートとfirewalldの確認結果
• 再試行の時刻、直前に変えた設定、その時刻のSSHサービスのログ

接続できたら、基礎記事の whoami と hostname による確認へ戻ります。labuserと linux-lab を確認し、何を直したら接続できたかを残しておきましょう。