SSH接続エラーの原因と解決法｜初心者向け完全ガイド

SSH接続エラーとは、リモートサーバーへの安全な接続を試みた際に発生する通信上の問題です。主な原因としては、SSHサーバーの未起動、ネットワーク設定の不備、公開鍵認証の設定ミス、ファイアウォールによるブロックなどが挙げられます。エラーメッセージを正しく読み解き、段階的にトラブルシューティングを行えば、初心者でもほとんどの問題を解決できます。

サーバー管理やWeb開発の現場では、SSHを使ったリモート接続は日常的に行われています。しかし、初めてSSH接続を試みる際にエラーが発生すると、何が原因なのか分からず作業が止まってしまうことも少なくありません。SSH接続エラーにはいくつかの代表的なパターンがあり、それぞれに明確な原因と解決法が存在します。この記事では、SSH接続で頻繁に遭遇するエラーの種類を網羅的に取り上げ、初心者にもわかりやすい形で原因の特定から解決までの手順を解説します。エラーの対処法だけでなく、公開鍵認証の基本設定やセキュリティ対策、Windows環境での注意点まで幅広くカバーしていますので、SSH接続のトラブルに直面した際の実用的なガイドとしてご活用ください。

SSHとは何か？安全なリモート接続を支えるプロトコル

SSHとは「Secure Shell」の略称で、ネットワークを通じてリモートのコンピュータに安全に接続するためのプロトコルです。従来使われていたTelnetやFTPとは異なり、通信内容がすべて暗号化されるため、パスワードやコマンドの内容が第三者に盗み見られる心配がありません。

SSHを使うことで、リモートサーバーへのログインと操作、SCPやSFTPを利用したファイルの安全な転送、ポートフォワーディングによるトンネリング、Gitリポジトリへの安全なアクセスなど、さまざまな操作が可能になります。SSHは通常、ポート番号22を使用して通信を行い、クライアント（自分のPC）からサーバーに対して接続要求を送り、認証が成功するとリモートのシェル環境にアクセスできる仕組みです。

SSH接続の仕組みと認証の流れ

SSH接続は5つのステップで成立します。まずクライアントがサーバーに接続要求を送信し、次にサーバーが自身のホスト鍵をクライアントに提示します。クライアントがホスト鍵を確認して接続を受け入れた後、パスワード認証または公開鍵認証による認証が行われます。認証が成功すると、暗号化された通信が確立されます。この一連の流れのどこかで問題が発生すると、SSH接続エラーとなります。エラーの種類によって問題が発生している箇所を特定することができるため、エラーメッセージを正確に把握することが重要です。

SSH接続エラーの主な種類と原因の分類

SSH接続で遭遇するエラーは、大きく分けてネットワーク関連、認証関連、サーバー設定関連、クライアント設定関連、ホスト鍵関連の5つのカテゴリに分類できます。以下の表に、代表的なエラーメッセージとその原因カテゴリをまとめます。

「Connection refused」エラーの原因と初心者向け解決法

「Connection refused」は、サーバー側で接続が明示的に拒否された場合に表示されるエラーです。エラーメッセージとしては ssh: connect to host 192.168.1.100 port 22: Connection refused のように表示されます。

このエラーが発生する原因として最も多いのは、SSHサーバー（sshd）が起動していないケースです。サーバーの再起動やアップデート後に、SSHデーモンが自動的に起動しないことがあります。また、新しくセットアップしたサーバーではSSHサーバーがインストールされていない場合もあり、特にUbuntuのデスクトップ版ではデフォルトでSSHサーバーが含まれていません。さらに、サーバー管理者がセキュリティ上の理由からSSHのポート番号をデフォルトの22番から変更している場合や、サーバー側のファイアウォール（iptables、firewalld、UFWなど）でSSHのポートがブロックされている場合にも、このエラーが発生します。

解決するには、まずサーバーに直接アクセスできる環境（コンソールやVNCなど）から systemctl status sshd コマンドでSSHサーバーの状態を確認します。停止している場合は sudo systemctl start sshd で起動し、sudo systemctl enable sshd で自動起動を有効にします。SSHサーバーがインストールされていない場合は、Ubuntu/Debianなら sudo apt update の後に sudo apt install openssh-server を実行し、CentOS/RHELなら sudo yum install openssh-server でインストールします。ポート番号が変更されている場合は ssh -p 2222 user@hostname のように正しいポート番号を指定して接続してください。ファイアウォールが原因の場合は、UFWなら sudo ufw allow ssh で許可し、firewalldなら sudo firewall-cmd --permanent --add-service=ssh と sudo firewall-cmd --reload で設定を反映させます。

「Connection timed out」エラーの原因と解決法

「Connection timed out」は、サーバーに接続を試みたが一定時間内に応答が返ってこなかった場合に表示されるエラーです。「Connection refused」がサーバーから明示的に拒否されるのに対し、「Connection timed out」はそもそも通信がサーバーに到達していない可能性が高いという点が大きな違いです。

このエラーの原因としては、接続先のIPアドレスやホスト名の誤り、クライアントとサーバー間のネットワーク経路の問題が挙げられます。AWS、GCP、Azureなどのクラウド環境においては、セキュリティグループやネットワークACLの設定不備が原因となるケースも多く見られます。そのほか、サーバー自体のダウン、VPN未接続やプロキシ設定の問題、会社や学校のネットワークによるSSHポートのブロックなども原因となり得ます。

解決するには、まず ping 192.168.1.100 でネットワークの疎通を確認します。pingが通らない場合はネットワークレベルの問題であるため、IPアドレスの確認やネットワーク設定の見直しを行います。pingが通る場合は nc -vz 192.168.1.100 22 でSSHポートへの接続を確認します。クラウド環境の場合は、セキュリティグループの設定を確認し、SSHのポートが自分のIPアドレスから許可されているかを確認してください。AWSのEC2であれば、セキュリティグループでタイプがSSH、プロトコルがTCP、ポート範囲が22、ソースが自分のIPアドレスまたは適切なCIDRとなっているか確認します。会社や学校のネットワークからの接続がブロックされている場合は、モバイル回線など別のネットワークから試すか、ネットワーク管理者への相談が必要です。

「Permission denied (publickey)」エラーの原因と解決法

「Permission denied (publickey)」は、公開鍵認証が失敗した場合に表示されるエラーで、サーバーがパスワード認証を無効にしている環境で特に多く見られます。エラーメッセージは Permission denied (publickey). や Permission denied (publickey,gssapi-keyex,gssapi-with-mic). といった形で表示されます。

このエラーの原因は多岐にわたります。SSH接続時に指定する秘密鍵のファイルパスが間違っている場合、サーバー側のauthorized_keysファイルに自分の公開鍵が登録されていない場合、秘密鍵ファイルのパーミッションが開きすぎている場合、接続先のユーザー名が間違っている場合、サーバー側の.sshディレクトリやauthorized_keysファイルのパーミッションが不適切な場合、サーバーに登録した公開鍵とクライアントの秘密鍵が対応するペアではない場合のいずれかが該当します。

解決するには、まず ssh -v user@hostname で詳細なデバッグ情報を確認します。さらに詳しい情報が必要な場合は ssh -vvv user@hostname を使用します。秘密鍵のパーミッションは chmod 600 ~/.ssh/id_rsa で修正し、.sshディレクトリは chmod 700 ~/.ssh に設定します。サーバー側のauthorized_keysも chmod 600 ~/.ssh/authorized_keys に設定する必要があります。公開鍵をサーバーに登録する際は ssh-copy-id user@hostname コマンドが便利です。手動で登録する場合は、クライアント側の公開鍵（~/.ssh/id_rsa.pub）の内容をサーバー側の~/.ssh/authorized_keysファイルに追記します。なお、クラウドサービスではデフォルトのユーザー名が異なる点にも注意が必要で、AWSのAmazon Linuxでは「ec2-user」、AWSのUbuntuでは「ubuntu」、GCPのVMでは自分のGoogleアカウント名がユーザー名となります。

「Host key verification failed」エラーの原因と解決法

「Host key verification failed」は、以前接続したことのあるサーバーのホスト鍵が変わっている場合に表示されるエラーです。SSHはセキュリティのため、既知のホスト鍵を~/.ssh/known_hostsファイルに保存しており、接続先のホスト鍵が保存されているものと異なると「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」という警告とともにこのエラーが発生します。

このエラーの原因として最も多いのは、OSの再インストールやサーバーの入れ替えによりホスト鍵が新しく生成されたケースです。クラウド環境では、Elastic IPの付け替えやインスタンスの作り直しによって同じIPアドレスに別のサーバーが割り当てられることもあります。DNSの設定変更により同じホスト名が別のIPアドレスに解決されるようになった場合にも発生します。まれに中間者攻撃（Man-in-the-Middle Attack）の可能性もありますが、実際にはサーバーの再構築が原因であることがほとんどです。

解決するには、まずホスト鍵が変わった理由を確認します。サーバー管理者への確認や、自分でサーバーを管理している場合は再インストールなどの作業を行ったかを思い出しましょう。正当な理由でホスト鍵が変わったことが確認できたら、ssh-keygen -R hostname または ssh-keygen -R 192.168.1.100 で古いホスト鍵を削除します。その後、再度SSH接続を行うと新しいホスト鍵を受け入れるか確認されます。ホスト鍵の変更に心当たりがない場合は、中間者攻撃の可能性を疑い、サーバー管理者に確認してから対処してください。安易にホスト鍵を削除することはセキュリティ上危険です。

「No route to host」エラーの原因と解決法

「No route to host」は、クライアントからサーバーへのネットワーク経路が存在しない場合に表示されるエラーです。原因としては、サーバーのIPアドレスの誤り、サブネットマスクやデフォルトゲートウェイなどのネットワーク設定の不備、サーバーが別のネットワークセグメントにありルーティングが設定されていないケース、VPN接続が切れているケースなどが挙げられます。

解決するには、まずIPアドレスが正しいか再度確認します。Linuxでは traceroute 192.168.1.100、Windowsでは tracert 192.168.1.100 でネットワーク経路を調査し、どこで通信が途切れているかを特定します。VPN接続が必要な環境であれば、VPN接続の状態を確認してください。

秘密鍵のパーミッションエラーの原因と対処法

Permissions 0644 for '/home/user/.ssh/id_rsa' are too open. というエラーメッセージは、秘密鍵ファイルのパーミッションが緩すぎる場合に表示されます。SSHはセキュリティを重視しており、秘密鍵ファイルが他のユーザーから読み取り可能な状態では使用を拒否する仕様となっています。

解決するには、Linux環境では chmod 600 ~/.ssh/id_rsa で秘密鍵のパーミッションを適切に設定します。AWSのPEMファイルの場合も同様に chmod 600 ~/mykey.pem と設定します。Windows環境の場合は、ファイルのプロパティからセキュリティタブを開き、自分のユーザーアカウントのみにアクセス権を限定する必要があります。

SSH公開鍵認証の基本と設定方法

SSH接続のトラブルを未然に防ぎ、セキュリティを高めるためには、公開鍵認証の仕組みを理解しておくことが重要です。公開鍵認証では「公開鍵」と「秘密鍵」のペアを使用して認証を行います。公開鍵はサーバー側に配置し、秘密鍵はクライアント側で保管します。秘密鍵は絶対に他人に渡してはいけません。

認証の流れとしては、クライアントがサーバーに接続を要求し、サーバーがランダムなデータを生成してクライアントに送信します。クライアントが秘密鍵でデータに署名してサーバーに返送し、サーバーが公開鍵で署名を検証します。検証が成功すれば認証完了となります。

鍵ペアの作成には ssh-keygen -t ed25519 -C "your_email@example.com" コマンドを使用します。ed25519は現在推奨されている暗号アルゴリズムです。古い環境で使用できない場合は ssh-keygen -t rsa -b 4096 -C "your_email@example.com" でRSA形式の鍵を作成します。コマンドを実行すると保存先とパスフレーズの入力を求められますが、パスフレーズを設定すると秘密鍵が盗まれた場合でも不正利用を防ぐことができるため、設定することを推奨します。

作成した公開鍵をサーバーに配置する最も簡単な方法は ssh-copy-id -i ~/.ssh/id_ed25519.pub user@hostname コマンドです。このコマンドにより、公開鍵がサーバーの~/.ssh/authorized_keysファイルに自動的に追加されます。

sshd_configで押さえておきたい重要な設定項目

SSHサーバーの設定ファイルは /etc/ssh/sshd_config にあります。このファイルの設定内容を理解しておくと、エラーの原因究明やセキュリティの強化に大いに役立ちます。

PasswordAuthenticationを「no」に変更する際は、必ず公開鍵認証の設定が完了してから行ってください。変更前にパスワード認証を無効にすると、サーバーにログインできなくなる危険があります。設定を変更した後は sudo systemctl restart sshd でSSHサービスを再起動する必要があります。設定変更時は既存のSSH接続を維持したまま、別のターミナルから新しい接続でテストしてください。設定にミスがあった場合でも、既存の接続から修正することができます。

SSHのデバッグ方法と問題の特定手順

SSH接続のトラブルシューティングにおいて、デバッグ情報の確認は最も重要なステップです。クライアント側では ssh -v user@hostname コマンドで接続過程の詳細なログを表示できます。ログの内容を読むことで、接続のどの段階で問題が発生しているかを特定できます。-vの数を増やすとより詳細な情報が得られ、ssh -vv がレベル2、ssh -vvv が最も詳細なレベル3となります。

デバッグログには、接続先のIPアドレスとポート番号、使用されるプロトコルバージョン、鍵交換アルゴリズムの選択、認証方法の試行順序、各認証方法の成功や失敗といった情報が含まれています。たとえば debug1: Authentications that can continue: publickey に続いて debug1: No more authentication methods to try. と表示された場合、公開鍵認証のみが許可されており、指定された秘密鍵では認証に失敗したことを意味します。

サーバー側でもSSHのログを確認することで問題を特定できます。Ubuntu/Debianでは /var/log/auth.log、CentOS/RHELでは /var/log/secure にSSH関連のログが記録されます。systemdを使用している環境では journalctl -u sshd -f コマンドでリアルタイムにログを確認することも可能です。

SSH接続のセキュリティベストプラクティス

SSH接続のエラーを未然に防ぎ、セキュリティを高めるための対策として、まずパスワード認証を無効にし、公開鍵認証のみを使用することが強く推奨されます。パスワード認証はブルートフォース攻撃の対象になりやすいためです。

rootユーザーでの直接ログインは禁止し、一般ユーザーでログインしてから必要な場合にsudoで管理者権限を使用する運用が安全です。SSHのポート番号をデフォルトの22番から変更することも有効で、自動化された攻撃ツールの標的になるリスクを軽減できます。ただし、2222や8022といった推測されやすいポート番号は避け、ランダムなポート番号を選択してください。

さらに、ファイアウォールやsshd_configのAllowUsersディレクティブを使用して接続元IPアドレスを制限すること、Fail2Banなどのツールを導入して一定回数ログインに失敗したIPアドレスを自動的にブロックすること、SSHの鍵を定期的に更新して古い鍵を無効化することも重要な対策です。

2025年10月にリリースされたOpenSSH 10.1では、ポスト量子暗号への対応強化など最新のセキュリティ技術が導入されました。常に最新バージョンを使用することが推奨されます。加えて、公開鍵認証にGoogle Authenticatorなどを使った二要素認証を組み合わせることで、セキュリティをさらに強化することも検討に値します。

SSH接続トラブルシューティングを体系的に進める手順

SSH接続に問題が発生した場合は、体系的な手順に従ってトラブルシューティングを行うことで効率的に原因を特定できます。

最初のステップとして、接続先のIPアドレスまたはホスト名、ポート番号（デフォルト22、変更されている場合は確認）、ユーザー名、使用する秘密鍵のパスといった基本情報の確認を行います。初歩的なミスが原因であるケースは意外と多いため、まずはこの段階で見落としがないか丁寧に確認することが大切です。

次にpingコマンドやtracerouteコマンド、nc -vz hostname 22 を使ってネットワークの疎通確認を行います。ネットワークに問題がないことが確認できたら、ssh -vvv で詳細なデバッグ情報を取得し、秘密鍵のパーミッションが600であること、~/.ssh/known_hostsの内容、~/.ssh/configの設定といったクライアント側の確認を進めます。

サーバーに直接アクセスできる場合は、SSHサーバーの起動状況、/etc/ssh/sshd_configの設定、ファイアウォールの設定、SSHログの確認、.sshディレクトリとauthorized_keysのパーミッション確認というサーバー側の確認を実施します。クラウド環境の場合はさらに、セキュリティグループの設定、ネットワークACLの設定、インスタンスの状態、VPCのルーティングテーブルの確認といったクラウド固有の確認も必要です。

よくあるSSH接続トラブルへの対処法

初心者が特に遭遇しやすいトラブルについて、代表的なケースの対処法を紹介します。

パスワードを正しく入力しているのにログインできない場合は、サーバー側でパスワード認証が無効になっている可能性があります。/etc/ssh/sshd_configファイルのPasswordAuthenticationの設定を確認し、「no」になっている場合は公開鍵認証を使用する必要があります。

AWSのEC2インスタンスにSSH接続できない場合は、まずセキュリティグループで22番ポートが自分のIPから許可されているかを確認します。次に正しいユーザー名を使用しているか（Amazon Linuxならec2-user、Ubuntuならubuntu）を確認し、正しいPEMファイルを指定しているか、PEMファイルのパーミッションが600になっているか、インスタンスが起動しているかを順番に確認してください。

急にSSH接続がタイムアウトするようになった場合は、自分のパブリックIPアドレスが変わった可能性があります。プロバイダから動的IPアドレスが割り当てられている環境では、IPアドレスの変更によりセキュリティグループの許可リストと合わなくなることがあります。現在のIPアドレスを確認し、セキュリティグループの設定を更新してください。

SSH接続が途中で切断されてしまう場合は、ネットワークの不安定さやサーバー側のタイムアウト設定が原因です。クライアント側の~/.ssh/configファイルに ServerAliveInterval 60 と ServerAliveCountMax 3 の設定を追加すると、60秒ごとにサーバーに生存確認パケットを送信するようになり、接続が維持されやすくなります。3回連続で応答がない場合に接続が切断される仕組みです。

WindowsからのSSH接続で困っている場合は、Windows 10以降に標準搭載されているOpenSSHクライアントを活用するのが最も手軽です。コマンドプロンプトやPowerShellから直接sshコマンドを使用できます。PuTTYやTeraTermなどの専用クライアントソフトを使う方法もありますが、PuTTYでは秘密鍵をPuTTY独自の.ppk形式に変換する必要がある点に注意してください。PuTTYgenを使用して変換できます。

Windows環境でのSSH接続の注意点と設定方法

Windows環境からSSH接続を行う場合には、いくつかの固有の注意点があります。Windows 10バージョン1809以降ではOpenSSHクライアントが標準搭載されており、コマンドプロンプトやPowerShellからsshコマンドを直接使用できます。

Windowsでは秘密鍵のパーミッション設定にchmodコマンドが使えないため、ファイルのプロパティからセキュリティ設定を変更する必要があります。秘密鍵ファイルを右クリックしてプロパティを開き、「セキュリティ」タブで自分のユーザーアカウント以外のアクセス権を削除します。PowerShellでは icacls .\id_rsa /inheritance:r と icacls .\id_rsa /grant:r "%USERNAME%:R" で同様の設定を行うこともできます。Windowsの場合、SSHの設定ファイルや鍵は C:\Users\ユーザー名\.ssh\ フォルダに保存されます。

PuTTYを使用する場合は、PuTTY独自の鍵形式（.ppk）への変換が必要です。PuTTYgenの「Conversions」メニューから「Import key」を選択し、OpenSSH形式の秘密鍵を読み込んでから「Save private key」で.ppk形式に変換します。

まとめ

SSH接続のエラーは初心者にとって大きな壁に感じられることがありますが、エラーメッセージを正しく読み解き、体系的にトラブルシューティングを行うことで、ほとんどの問題は解決できます。

本記事で取り上げた主要なエラーの対処法を整理すると、「Connection refused」はSSHサーバーの起動確認とファイアウォールの確認で対処します。「Connection timed out」はネットワーク疎通とセキュリティグループの確認が有効です。「Permission denied (publickey)」は鍵のパーミッションと公開鍵の登録を確認し、「Host key verification failed」は正当な理由を確認した上で古いホスト鍵を削除します。「No route to host」はネットワーク経路とVPN接続の確認で解決でき、「Permissions too open」は秘密鍵のパーミッションを600に設定することで対処できます。

トラブルシューティングの基本は ssh -v オプションでデバッグ情報を確認することです。これにより問題の発生箇所を特定し、適切な対処を行うことができます。また、エラーを未然に防ぐためにも、公開鍵認証の使用、ポート番号の変更、rootログインの禁止、ファイアウォールの適切な設定といったセキュリティベストプラクティスを日頃から実践しておくことが大切です。SSH接続はサーバー管理やWeb開発において日常的に使用する重要な技術ですので、本記事を参考にエラーへの対処力を高め、スムーズなリモート接続環境を構築してください。