エラーメッセージで原因の範囲を絞る

SSH接続の失敗は、表示されるメッセージによって疑う場所が大きく変わります。まず詳細なログを出して接続し、最後に表示されたエラーを確認します。-v は詳細表示(verbose)のオプションです。

ssh -v [email protected]
エラー意味最初に見る場所
Connection timed out応答が返ってこない。通信が途中で捨てられている到達性、クラウドのセキュリティグループ、BAN
Connection refusedサーバーには届いたが、そのポートで待ち受けがないか、拒否されたsshdの稼働状態、ポート番号、OSのファイアウォール
Permission denied (publickey)接続は成立したが、認証に失敗したユーザー名、鍵、パーミッション
Host key verification failed接続先サーバーの識別情報が以前の記録と一致しない手元の known_hosts

timed out と refused は通信の段階で失敗しています。Permission denied は通信が成立した後の認証の段階です。Host key verification failed はこれらとは性質が違い、手元のPCに残っている記録との食い違いです。そのため最初に片付けます。

Host key verification failed の場合

OSを再インストールした場合や、同じIPアドレスでサーバーを作り直した場合は、ホスト鍵(サーバーを識別するための鍵)が変わっただけです。手元の古い記録を削除してから再接続します。

ssh-keygen -R 203.0.113.10

心当たりがないのにホスト鍵が変わった場合は、通信の乗っ取り(中間者攻撃)の可能性を否定できません。記録を削除する前に、後述するWebコンソールからサーバー側のフィンガープリント(鍵の要約値)を表示します。その値を、接続時に表示される値と照合してください。

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

ステップ1:ネットワークでサーバーまで届いているか確認する

timed out が出たら、最初にコントロールパネルを開きます。サーバーの状態が「起動中」になっているか、接続先のIPアドレスが正しいかを確認します。作り直したサーバーはIPアドレスが変わっていることがあります。

次に、SSHのポートまで通信が届くかを調べます。Linux・macOSでは nc、Windowsでは PowerShell の Test-NetConnection を使います。

nc -vz 203.0.113.10 22
Test-NetConnection 203.0.113.10 -Port 22

ping が通らなくても、異常とは限りません。クラウドの初期設定では、pingが使うICMPという通信を許可していないことが多いためです。

会社や学校のネットワーク、公衆Wi-Fiでは、外向きの22番ポートが塞がれていることがあります。スマートフォンのテザリングなど別の回線から試して、そちらで繋がれば手元のネットワークが原因です。別の回線でも timed out になるならステップ2へ進みます。refused に変わったらステップ3へ進みます。

ステップ2:クラウドとOSのファイアウォールを確認する

ファイアウォールは2か所にあります。1つはコントロールパネルで設定するクラウド側のフィルタです。事業者によって「セキュリティグループ」「パケットフィルター」などと名前が異なります。もう1つはサーバーのOS内のファイアウォールです。

クラウド側のセキュリティグループ

SSHのポートが受信許可になっているかを確認します。標準は22番で、変更している場合はその番号です。接続元を自宅のIPアドレスに限定している場合、プロバイダー側でIPアドレスが変わると急に繋がらなくなります。現在の自分のグローバルIPアドレスと、許可しているIPアドレスが一致しているかを確認してください。ここで遮断されていると、通常は timed out になります。

OS側のファイアウォール

クラウド側の設定が正しいのに繋がらない場合は、OS側を疑います。確認にはサーバーへのログインが必要なので、ここからは後述するWebコンソールで作業します。

sudo ufw status                 # Ubuntu・Debianでufwを使う場合
sudo firewall-cmd --list-all    # AlmaLinux、Rocky LinuxなどのRHEL系
sudo nft list ruleset           # 上記のどちらも使っていない場合

SSHのポートが許可されていなければ追加します。ufwの場合は sudo ufw allow 22/tcp を実行します。firewalldの場合は sudo firewall-cmd --permanent --add-service=ssh の後に sudo firewall-cmd --reload を実行します。ポート番号を変えているときは、ufwでは番号を置き換え、firewalldでは --add-port=番号/tcp を使います。遮断ルールの動作がDROP(黙って破棄)なら timed out、REJECT(拒否を返す)なら refused として見えます。

ステップ3:sshdが動いているか確認する

Connection refused の原因として最も多いのは、sshd(SSHの接続を待ち受けるサーバープログラム)の停止です。想定と違うポートで待ち受けていることもあります。Webコンソールから次のコマンドを実行します。

sudo systemctl status ssh     # Ubuntu・Debian
sudo systemctl status sshd    # RHEL系
sudo ss -tlnp | grep ssh

ss の出力で、待ち受けているポートが接続時に指定した番号と一致しているかを確認します。sshdが起動に失敗している場合、典型的な原因は設定ファイルの書き間違いです。sudo sshd -t で構文を検査でき、問題がなければ何も表示されません。エラーが出た行を直してから、sudo systemctl restart ssh で再起動します。RHEL系では ssh を sshd に読み替えてください。

Ubuntu 24.04など、systemdのソケット(ssh.socket)経由でsshdを起動する構成では、ポート変更の反映方法が異なります。/etc/ssh/sshd_config のポート番号を変えた後、sudo systemctl daemon-reload と sudo systemctl restart ssh.socket を実行しないと、新しいポートで待ち受けません。

ステップ4:鍵と認証の設定を確認する

Permission denied (publickey) は、通信が成立していて認証だけが失敗している状態です。まず手元のPCで確認できる項目から見ていきます。

最初に確認するのはユーザー名です。クラウドのOSイメージには初期ユーザーが決まっています。Ubuntu公式イメージでは ubuntu、Amazon Linuxでは ec2-user、事業者によっては root など、OSや事業者によって異なります。コントロールパネルか事業者のマニュアルで確認してください。

次に、使う鍵を明示して接続します。ssh -v の出力にある「Offering public key」の行で、実際に試した鍵が分かります。

ssh -v -i ~/.ssh/id_ed25519 [email protected]

手元の秘密鍵のパーミッション(ファイルのアクセス権限)が緩いと、OpenSSHは「UNPROTECTED PRIVATE KEY FILE」と警告してその鍵を使いません。chmod 600 ~/.ssh/id_ed25519 で直します。

手元に問題がなければ、サーバー側を確認します。~/.ssh は700、authorized_keys は600に設定し、所有者をログインするユーザー本人にする必要があります。この条件を満たしていないと、sshdは鍵を無視します。原因はサーバーのログに記録されます。

sudo journalctl -u ssh -n 50         # RHEL系は -u sshd
sudo tail -n 50 /var/log/auth.log    # Debian系でログをファイルに記録している場合

ログに「Authentication refused: bad ownership or modes」とあれば、パーミッションか所有者が原因です。接続を試した時刻の記録が見当たらない場合は、そもそも別のサーバーに接続している可能性があります。

ステップ5:fail2banなどによるBANを確認する

前日まで繋がっていたのに突然 timed out や refused になった場合は、BAN(接続元IPアドレスの遮断)を疑います。fail2banは、ログイン失敗が続いたIPアドレスを自動で遮断するツールです。パスワードや鍵を何度か間違えた直後なら、特に可能性が高くなります。別の回線からは繋がるのに手元の回線だけ繋がらない場合も、BANされている可能性が高いと判断できます。

別の回線かWebコンソールからログインし、BANの状況を確認して解除します。

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.20

同じIPアドレスが再びBANされないようにするには、/etc/fail2ban/jail.local の ignoreip に自分のIPアドレスを追加します。ただし、固定IPではない回線ではIPアドレスが変わると効果がなくなります。fail2banが入っていない場合は、sshguardなど別の遮断ツールも確認します。事業者によっては、不正アクセス対策として事業者側で遮断していることもあるため、サポート情報もあわせて確認してください。

最終手段:Webコンソールから入って復旧する

多くのVPSやクラウドには、コントロールパネルからサーバーの画面を直接操作できるWebコンソールがあります。VNCコンソールやシリアルコンソールと呼ばれ、SSHやネットワークの設定が壊れていても使えます。ステップ2〜5のサーバー側の作業も、SSHで入れないときはここから行います。

注意点として、コンソールからのログインにはパスワードが必要です。鍵認証だけでユーザーを作成してパスワードを設定していない場合は、コンソールからも入れません。その場合は、事業者が用意している次のような手段をマニュアルで探します。1つはコントロールパネルのrootパスワード再設定機能です。もう1つは、レスキューモード(OSとは別の起動環境)で起動し、元のディスクをマウントして設定ファイルを直す方法です。AWSのEC2では、Session Managerを使う方法と、ディスク(EBSボリューム)を別のインスタンスに付け替えて修正する方法があります。Session Managerを使うには、事前にSSMエージェントとIAMロールを設定しておく必要があります。

VNCコンソールでは、キーボード配列の違いにより | や : などの記号が正しく入力できないことがあります。コンソール側の配列設定を確認するか、コピー&ペースト機能を使ってください。

ログインできたら、ステップ2〜5の順にファイアウォール、sshd、authorized_keys、BANを確認します。修正後はコンソールを開いたまま手元からSSH接続を試し、成功を確認してからコンソールを閉じます。

設定変更で締め出されないための作業手順

SSHで入れなくなる原因の多くは、ファイアウォールや sshd_config を変更した直後に発生します。今後これらを変更するときは、既存のSSHセッションを1つ開いたままにして、別のターミナルから新しい接続を試してください。繋がらなかった場合は、開いておいたセッションで元の設定に戻せます。sshdの設定を変更したら、再起動の前に必ず sudo sshd -t を実行します。あわせて、Webコンソールでログインできるパスワード付きのユーザーがあるかを今のうちに確認してください。用意しておけば、最終手段が使えないという事態を避けられます。