SSH が「サーバーへの接続の確立」で停止する場合のトラブルシューティング方法

公開: 2025-12-21

Secure Shell (SSH) は、サーバーをリモートで管理および管理するための重要なコンポーネントです。 SSH クライアントで「サーバーへの接続を確立しています」というメッセージが表示されなくなると、特に実稼働環境や時間に敏感な構成を扱っている場合はイライラすることがあります。この問題は漠然としているように見えるかもしれませんが、ネットワークの構成ミスからターゲット サーバーの SSH デーモンの問題まで、複数の潜在的な原因が考えられます。 SSH 接続の効果的なトラブルシューティング方法を知っていれば、時間と不必要なストレスの両方を節約できます。

TL;DR

SSH セッションが「サーバーへの接続の確立」で停止している場合は、まず宛先ホストの可用性とネットワーク接続を確認します。 SSH サービスが宛先で実行されており、正しいポートでリッスンしていることを確認します。次に、ローカルのファイアウォール、DNS 解決、または VPN 設定を確認します。接続試行中に詳細な情報を得るには、詳細な SSH ログ記録 (-vvv) を使用します。

1. 基本的なネットワーク接続を確認する

構成とログ ファイルについて詳しく調べる前に、最も簡単なチェックから始めてください。

  • サーバーに ping を実行する:pingを使用して、ホストが到達可能であることを確認します。
  • Traceroute または MTR:これは、ユーザーと SSH サーバー間のネットワーク ホップで接続ブロックがあるかどうかを判断するのに役立ちます。
  • Telnet または Netcat:ポート 22 (またはカスタム SSH ポート) にアクセスして、アクセス可能であることを確認します: telnet your.server.ip 22またはnc -zv your.server.ip 22

サーバーが ping に応答しない場合、または SSH ポートを拒否する場合は、ホストがダウンしているか、ネットワークがトラフィックをブロックしているか、SSH がサーバー上で適切に実行されていないかのいずれかです。

2. 詳細モードを使用して洞察を得る

SSH は、接続プロセスのどこで遅延が発生しているかを特定するのに役立つさまざまなレベルの冗長性を提供します。より詳細な出力を取得するには、 -v、-vv、または-vvvオプションを使用します。

 ssh -vvv [email protected]

詳細モードが役立つ一般的な場所は次のとおりです。

  • DNS解決の確認
  • 接続試行が特定のステップでタイムアウトするかどうかを判断する
  • キー交換または認証エラーの特定

3. ファイアウォールとセキュリティグループの設定

多くの場合、ファイアウォールまたはクラウドのセキュリティ設定が原因です。クライアント側とサーバー側の両方を確認する必要があります。

  • クライアント側のファイアウォール:ポート 22 (またはカスタム SSH ポート) での送信接続が許可されていることを確認します。
  • サーバー側ファイアウォール:iptablesやufwなどのツールが受信 SSH トラフィックをドロップしている可能性があります。
  • クラウド セキュリティ グループ:AWS、GCP、または Azure 環境では、セキュリティ グループが IP と正しいポートを許可しているかどうかを確認します。

「接続の確立」で接続がハングする場合は、パケットが積極的に拒否されているのではなく、サイレントにドロップされている可能性があります。

4. サーバー上の SSH デーモンを確認する

サーバーへの代替アクセス (コンソール、シリアル アクセス、または別のリモート セッションなど) がある場合は、直接ログインして SSH サービスを確認します。

 sudo systemctl status sshd
 sudo netstat -tulpn | grep ssh

注意すべき点:

  • サービスはアクティブで実行中ですか?
  • 期待された IP とポートでリッスンしていますか?
  • SSH 設定ファイル (通常は/etc/ssh/sshd_config) に最近、障害の原因となる可能性のある変更が加えられていますか?

SSH が最近再構成されたか、不適切に再起動された場合、プロセスがクラッシュするか、受信接続に応答しなくなる可能性があります。

5. DNS 解決の問題

IP アドレスではなくホスト名を使用して接続している場合は、DNS が適切に解決されていることを確認してください。

 nslookup your.server.domain
 dig your.server.domain

DNS 設定に問題があるため、ホスト名を解決できない場合は、SSH 接続が遅延または中断される可能性があります。また、ルーターまたは VPN の/etc/resolv.confまたは DNS 設定を確認してください。

6. TCP ラッパーとホストベースの制限

一部の Linux ディストリビューションでは、 /etc/hosts.allowおよび/etc/hosts.denyによって制御される TCP ラッパーによって SSH アクセスが制限される場合があります。

  • /etc/hosts.denyにsshd: ALLのような行が含まれていないことを確認してください。
  • sshd: your.ip.addressを使用して/etc/hosts.allowで IP を明示的に許可します。

TCP ラッパーは大部分が非推奨になっていますが、レガシー システムではログに明確な兆候が示されずに TCP ラッパーが依然として使用されている可能性があります。

7. VPN またはプロキシの干渉

VPN および特定のプロキシ設定は、SSH トラフィックに干渉する可能性があります。

  • VPN がアクティブであり、トラフィックが正しくルーティングされているかどうかを確認してください。
  • VPN 分割トンネルを使用している場合は、SSH サーバーへのトラフィックがトンネルに含まれていることを確認してください。
  • VPN を一時的に無効にして、直接インターネット アクセス経由で再接続してみてください。

同様に、企業プロキシまたは制限的なゲートウェイは SSH パケットをドロップまたは操作し、セッションがハングする可能性があります。

8. SSH キーの問題と認証の遅延

通常、認証エラーは明確な「許可が拒否されました」というメッセージを返しますが、場合によっては、キーの処理や認証されたキーの検索で長い遅延が発生し、接続のスタックを模倣する可能性があります。

  • ~/.sshディレクトリ内のキーが多すぎると、認証が遅くなる可能性があります。試行を減らすには、 ~/.ssh/configでIdentitiesOnly yesを使用します。
  • 指定したキーを構成します: ssh -i ~/.ssh/my_key user@host

9. サーバーの負荷とリソースの制約

サーバーの負荷が高くなると、速度が低下したり、新しい SSH 接続がブロックされたりする可能性があります。

  • サーバー上の CPU、RAM、またはプロセスの制限が高いかどうかを確認します
  • SSH 経由でアクセスできない場合は、クラウド コンソールを使用してシステム ステータスを検査します

メモリが不足すると、 sshd が不安定に動作したり、新しい接続の試行がタイムアウトになったりすることがあります。

10. Fail2Ban または同様のツールによる一時的な禁止

Fail2Ban や DenyHosts などのセキュリティ ツールは、認証に繰り返し失敗した IP をブロックする場合があります。これにより、サイレント接続がハングする可能性があります。

  • /var/log/fail2ban.logまたは関連ログで IP 禁止を確認します。
  • 可能であれば IP をホワイトリストに登録するか、別のネットワークからサーバーにアクセスします

結論

SSH 接続の問題、特に「サーバーへの接続の確立」で行き詰まった場合は、ローカルのファイアウォール設定からリモート サーバーのパフォーマンスの問題まで、さまざまな要因が原因で発生する可能性があります。基本的な接続テストから始まり、詳細なログ記録と構成チェックに進む、規律あるトラブルシューティング アプローチが不可欠です。詳細な SSH 出力、システム ログの確認、DNS の検証、サーバーの応答性の確認などのツールを使用すると、根本原因を効率的に切り分けることができます。

必ず変更を段階的にテストし、変更した構成をバックアップしてください。高可用性環境では、SSH が応答しない場合に、IPMI、シリアル コンソール、プライマリ サーバー アクセスなどの帯域外管理方法を備えていることが重要です。