DevOpsナレッジハブ
DevOpsナレッジハブ

一般的なSSHエラーのトラブルシューティング：「Connection Refused」と「Permission Denied」

「Connection Refused」および「Permission Denied」エラーの診断を習得することで、煩わしいSSH接続の問題を解決します。この実用的なガイドでは、sshdサービスの状態の確認、ファイアウォール規則 (UFW) のデバッグ、鍵ベース認証の権限の修正、そして迅速な解決のためのサーバー認証ログの解釈など、体系的なトラブルシューティング手順を詳述しています。

45 ビュー

一般的なSSHエラーのトラブルシューティング：接続拒否と認証拒否

Secure Shell (SSH) はリモートシステム管理の基盤であり、サーバーへのアクセスに暗号化された通信を提供します。しかし、接続エラーに遭遇すると、すぐに生産性が停止してしまいます。ユーザーが直面する最も一般的で苛立たしい2つのエラーは、「Connection Refused (接続拒否)」と「Permission Denied (認証拒否)」です。

このガイドでは、これらの問題を診断し解決するための体系的なアプローチを順を追って説明します。ネットワークの障害から誤った認証設定まで、一般的な原因を理解することで、リモートマシンへのセキュアなアクセスを迅速に復旧できます。サーバーの状態確認から認証メカニズムのデバッグまで、不可欠なチェック項目を網羅します。

エラーの理解：拒否 (Refused) と拒絶 (Denied) の違い

根本原因が大きく異なるため、2つの主要なエラーメッセージを区別することが重要です。

  1. Connection Refused (接続拒否)： これは通常、ネットワーク接続がサーバーに到達したものの、指定されたポートで何もリッスンしていなかったか、オペレーティングシステムが接続試行を積極的に拒否したことを意味します。
  2. Permission Denied (認証拒否)： これは、SSHサービス (sshd) が接続要求を正常に受信したものの、サーバー設定に基づいて認証試行 (パスワードまたはキー) が失敗したことを意味します。

パート1：接続拒否のトラブルシューティング

「Connection Refused (接続拒否)」(多くの場合 ssh: connect to host <hostname> port 22: Connection refused として表示される) は、通常、デーモンが着信接続を受け入れるのを妨げているサーバー側の問題を示しています。

1. SSHデーモン (sshd) のステータスを確認する

拒否の最も一般的な原因は、SSHサーバープロセスが実行されていないか、クラッシュしていることです。

実行可能な手順 (リモートサーバー上で)：

systemctl (最新のLinuxディストリビューションで一般的) を使用してサービスステータスを確認します。

systemctl status sshd

ステータスが inactive または failed を示している場合は、サービスを開始します。

sudo systemctl start sshd
# 起動時に自動的に開始するように有効にする
sudo systemctl enable sshd

2. リッスンポートと設定を確認する

デフォルトでは、SSHはTCPポート22で実行されます。セキュリティ強化のためにポートが変更されている場合は、接続時に正しいポートを指定するか、サーバーが予期されたポートでリッスンしていることを確認する必要があります。

A. sshd_config を確認する

通常 /etc/ssh/sshd_config にあるSSH設定ファイルを確認します。Port ディレクティブを探します。

# /etc/ssh/sshd_config の例
Port 2222  # これが22でない場合、クライアント側で指定する必要がある

このファイルを変更した場合は、変更を反映するために sshd サービスを必ず再起動する必要があります。

B. リッスンソケットを確認する

sshd が予期されたインターフェースとポートでアクティブにリッスンしていることを確認するために ss または netstat を使用します。ここではポート22をチェックします。

# ss の使用 (最新のシステムで推奨)
sudo ss -tuln | grep 22

# リッスン状態を示す予想される出力：
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

ポート22に何も表示されない場合、デーモンは実行されていないか、異なるアドレス/ポートでリッスンするように設定されています。

3. ファイアウォールとネットワークの確認

sshd プロセスに到達する前にトラフィックをブロックするファイアウォールは、多くの場合タイムアウトを引き起こしますが、拒否として表示されることもあります。サーバー側のファイアウォールルールを確認することが不可欠です。

一般的なファイアウォールコマンド (Ubuntu/DebianでのUFW)：

SSHトラフィックが許可されていることを確認します。

# 現在のステータスを確認
sudo ufw status

# デフォルトポート22でのトラフィックを許可
sudo ufw allow ssh
# またはポート番号で許可
sudo ufw allow 22/tcp

# ファイアウォールルールを再読み込み
sudo ufw reload

⚠️ 外部ファイアウォールに関する警告： リモートネットワークから接続している場合、中間にあるネットワークデバイス、クラウドセキュリティグループ (AWSセキュリティグループやAzure NSGなど)、またはハードウェアファイアウォールがSSHポートでのトラフィックを明示的に許可していることを確認してください。

パート2：Permission Denied (認証拒否) のトラブルシューティング

サーバーに正常に接続できたが、すぐに「Permission denied (publickey,password)」というメッセージが表示される場合、問題は厳密には認証にあります。

1. ユーザー名とパスワードを確認する

これは最も簡単なチェックですが、見落とされがちです。

  • ユーザー名： 対象システムに正しいユーザー名を使用していますか？rootログインが無効になっている可能性があります。
  • パスワード： パスワード認証を使用している場合、Caps Lock、タイプミスを確認し、アカウントがロックされていないことを確認してください。

クライアント側での確認： 詳細なデバッグ出力を表示するには、詳細フラグを付けてクライアントを実行します。

ssh -vvv user@hostname

この出力は、クライアントがどの認証方法を試行し、サーバーがどれを拒否したかを明確に示します。

2. キーベース認証の失敗

キーベース認証は優れていますが、設定エラーが拒否の頻繁な原因となります。

A. .ssh ディレクトリの不適切なパーミッション

SSHはセキュリティのためにファイルパーミッションに非常に厳格です。パーミッションが緩すぎると、サーバーはキーファイルを完全に無視します。

リモートサーバー上 (パーミッションの修正)：

# ユーザーのホームディレクトリのパーミッションは通常問題ありませんが、.ssh フォルダーを確認する
chmod 700 ~/.ssh

# authorized_keys ファイルは所有者のみが書き込み可能である必要がある
chmod 600 ~/.ssh/authorized_keys

B. キーが存在しないか、形式が不適切

あなたの公開鍵 (id_rsa.pub または類似のもの) が、ターゲットユーザーのサーバーの ~/.ssh/authorized_keys ファイルに正しく追加されていることを確認してください。各キーは、キー文字列の途中に改行を挿入せずに、自身の行にある必要があります。

C. サーバー設定によるキーの無効化

サーバーの /etc/ssh/sshd_config を確認し、キー認証が許可されていることを確認します。

PubkeyAuthentication yes

# パスワードに依存している場合、パスワード認証が無効になっていないことを確認する
PasswordAuthentication yes

3. サーバー側ログの調査

認証が失敗した場合、サーバーログが究極の真実の情報源です。失敗したログイン試行に関連するメッセージを探してください。

一般的なログの場所：

  • Debian/Ubuntu： /var/log/auth.log
  • RHEL/CentOS/Fedora： /var/log/secure

grep を使用して最近の接続試行をフィルタリングします。

# RHEL/CentOS システム上
sudo grep 'Failed password' /var/log/secure

# または一般的なSSHアクティビティを探す
sudo tail -f /var/log/secure

ログメッセージは、キーが拒否された理由 (例：不正なオプション、一致するキーが見つからない、不適切なユーザーコンテキストなど) を明示的に示していることがよくあります。

信頼性の高いSSHアクセスのためのベストプラクティス概要

  1. キーペアを使用する： キーアクセスが確認されたら、sshd_config でパスワード認証 (PasswordAuthentication no) を無効にします。
  2. デフォルトポートを変更する： SSHをポート22から移動させることで、自動スキャンノイズを減らすことができます。
  3. PermitRootLogin no を使用する： 標準ユーザーを介した管理アクセスを強制し、sudo の使用を義務付けます。
  4. 設定をバックアップする： /etc/ssh/sshd_config に大幅な変更を加える前に、常に元のファイルをバックアップしてください。
    bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
  5. ローカルでテストする： 設定変更後、アクティブなセッションを切断してロックアウトされないように、(可能であれば) サーバー上でローカルに接続をテストしてください。

サービスステータス、ネットワークパス、および認証設定レイヤーを体系的にチェックすることで、リモートアクセス管理に内在する、苛立たしい Connection Refused および Permission Denied エラーを迅速に解決できます。