SSH接続できないときの切り分け方法｜実務で使えるトラブルシューティング手順
KoAN
目次
SSH接続トラブルを効率よく切り分ける方法を理解しよう
Linuxサーバ管理において最も頻繁に発生するトラブルの一つがSSH接続障害です。
普段は問題なく接続できていても、設定変更やサーバ再起動、ファイアウォール設定変更などをきっかけに突然SSH接続できなくなることがあります。
初心者のうちは「SSHできない」という状態だけで混乱しがちですが、実務ではどの段階で失敗しているのかを切り分けることが重要です。
SSH接続は複数の工程によって成立しているため、障害箇所を特定できれば原因はかなり絞り込めます。
本記事では実務で利用されるSSH接続障害の切り分け手順について詳しく解説します。
SSH接続の流れを理解する
まずSSH接続の流れを確認しましょう。
- IP通信の確立
- TCP 22番ポートへの接続
- SSHサービス応答
- ホスト鍵確認
- ユーザー認証
- シェル起動
どの段階で失敗しているかによって確認すべきポイントが変わります。
まずはPingを確認する
最初にネットワーク疎通を確認します。
$ ping 192.168.60.101応答が返る場合はIP通信自体は成立しています。
応答がない場合は以下を確認します。
- サーバが起動しているか
- IPアドレスが正しいか
- ネットワーク設定に誤りがないか
- ルーティングに問題がないか
- ICMPが遮断されていないか
ただしPingが通らなくてもSSH接続できる環境もあります。
22番ポートへ接続できるか確認する
次にTCP接続を確認します。
Linuxではncコマンドを利用できます。
$ nc -zv 192.168.60.101 22
成功例です。
Connection to 192.168.60.101 22 port [tcp/ssh] succeeded!失敗する場合は以下が考えられます。
- sshd停止
- firewalld設定
- nftables設定
- クラウド側のセキュリティ設定
Connection refused の場合
以下のエラーは非常によく発生します。
ssh: connect to host 192.168.60.101 port 22:
Connection refusedこの場合はサーバまで到達しています。
しかしSSHサービスが応答していません。
主な原因です。
- sshd停止
- 待受ポート変更
- firewalld設定ミス
まずはサーバコンソールで確認します。
$ systemctl status sshdConnection timed out の場合
次のエラーも頻繁に見られます。
Connection timed outこれは通信が途中で破棄されている状態です。
主な原因です。
- ファイアウォール遮断
- ルーティング異常
- クラウドのセキュリティグループ設定
- VPN経路障害
ネットワーク側の問題を疑うべきケースです。
sshdが起動しているか確認する
SSHサーバ側ではまずサービス状態を確認します。
$ systemctl status sshd
正常な例です。
Active: active (running)
停止している場合は起動します。
# systemctl start sshd待受ポートを確認する
sshdが本当に待ち受けているか確認します。
$ ss -tlnp | grep sshd
例です。
LISTEN 0 128 *:2222番以外が表示される場合はポート変更されている可能性があります。
firewalldを確認する
AlmaLinuxやRocky Linuxではfirewalldが原因になることがよくあります。
確認方法です。
# firewall-cmd --list-services
正常なら以下が表示されます。
ssh
無い場合は追加します。
# firewall-cmd --permanent --add-service=ssh
# firewall-cmd --reloadSELinuxを確認する
ポート変更時によく発生する問題です。
現在の状態を確認します。
# getenforceS
SHポートを変更した場合はSELinuxへ登録が必要です。
# semanage port -a -t ssh_port_t -p tcp 2222これを忘れると接続できません。
SSH設定ファイルを確認する
設定ミスがないか確認します。
/etc/ssh/sshd_config
変更後は必ず構文チェックを行います。
sshd -t
エラーが表示されなければ構文は正常です。
Permission denied の場合
次のエラーも非常に多く発生します。
Permission denied主な原因です。
- パスワード誤り
- ユーザー名誤り
- 公開鍵未登録
- authorized_keys権限異常
公開鍵認証を確認する
公開鍵認証の場合は以下を確認します。
$ ls -ld ~/.ssh
$ ls -l ~/.ssh/authorized_keys
一般的な権限です。
700 ~/.ssh
600 authorized_keys権限が緩すぎると認証に失敗します。
known_hostsエラーの場合
以下のエラーが表示される場合があります。
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!主な原因です。
- サーバ再構築
- IPアドレス再利用
- ホスト鍵変更
不要な情報を削除します。
$ ssh-keygen -R 192.168.60.101SSHデバッグを利用する
最も有効な調査方法です。
$ ssh -v user@serverさらに詳細な情報を取得できます。
ssh -vv
ssh -vvv認証失敗や鍵読み込み状況などが確認できます。
サーバログを確認する
サーバ側のログ確認も重要です。
AlmaLinuxやRocky Linuxでは以下を利用します。
# journalctl -u sshd
リアルタイム確認です。
# journalctl -fu sshd接続失敗の原因を確認できます。
実務での切り分け手順
現場では以下の順番で確認することが多いです。
- Ping確認
- 22番ポート確認
- sshd確認
- firewalld確認
- SELinux確認
- sshd_config確認
- クライアントログ確認
- サーバログ確認
この順番で進めると効率よく原因を特定できます。
学習環境で多いトラブル
VirtualBox環境では以下がよく発生します。
- IPアドレス設定ミス
- ブリッジ接続設定ミス
- Host-Only Adapter設定ミス
- firewalld設定忘れ
- sshd起動忘れ
Linuxサーバ構築演習では特によく見られる障害です。
まとめ
SSH接続障害は闇雲に設定を変更するのではなく、どの段階で失敗しているかを確認しながら切り分けることが重要です。
Ping、TCP接続、sshd、firewalld、SELinux、認証設定という順番で確認していけば、多くの障害は原因を特定できます。
特に実務では「Connection refused」「Connection timed out」「Permission denied」の違いを理解するだけでも調査効率が大きく向上します。
SSHはLinux管理の基盤となる技術ですので、トラブルシューティング手順もしっかり身につけておきましょう。
