ConoHa VPSでSSH接続できずハマった話(セキュリティグループとufw、2つの関所)

VPSを契約して、いよいよSSHで接続しようとしたところ、想像以上に長いトラブルシューティングになりました。原因が分かってしまえば単純なのですが、切り分けに丸一日近くかかったので、同じところでハマる人のために記録しておきます。

先に結論です。ConoHa VPS 3.0では、default のセキュリティグループが「全部許可」になっていても、SSH用の IPv4v6-SSH を別に追加しないとSSHはつながりません。 そしてこの件で、ファイアウォールが「ConoHa側」と「サーバーの中」の2か所にあることを初めて実感しました。

症状

契約直後、手元のPCから普通に接続を試みました。

ssh root@xxx.xxx.xxx.xxx

結果はこうでした。

ssh: connect to host xxx.xxx.xxx.xxx port 22: Connection timed out

切り分けの過程

「サーバー側の問題」か「自分側の問題」かを、順番に確認していきました。

1. サーバー自体は動いているか

ConoHaには、SSHを使わずブラウザ上でサーバーに直接ログインできる「コンソール」機能があります。これでログインを試したところ、問題なくログインできました。 サーバー自体は正常に起動していました。

2. SSHのサービスは動いているか

systemctl status ssh

active (running) で正常。

3. サーバーの中のファイアウォール(ufw)は許可しているか

sudo ufw status verbose

22/tcp ALLOW IN Anywhere と表示され、これも問題なし。

4. ConoHa側のセキュリティグループは許可しているか

管理画面で確認したところ、default というグループが適用されていて、中身は「全ポート・全プロトコル許可(All)」でした。一見、ここも問題なさそうに見えました。

5. 自分のネットワークを疑う

自宅のWi-Fi、スマホのテザリング、別のノートPCと環境を変えて何度も試しましたが、すべて同じくタイムアウト。

6. 外から見て、ポートが開いているか

自分のネットワークを通さずに、外からポートが開いているかを調べられる無料のツール(ポートチェッカー)で確認したところ、

Port 22 is closed

外から見ても閉じている、という結果でした。ここまでで「サーバーは正常」「自分のネットワークも関係ない」という、一見矛盾した状況になりました。

原因:ConoHa VPS特有の仕様だった

行き詰まってConoHaのサポートページを確認したところ、答えが見つかりました。

ConoHa VPSバージョン3.0をご利用の場合、SSHやSFTP接続を行う場合はSSH用のセキュリティグループ設定を追加する必要がございます。

つまり、default が「全ポート許可」になっていても、それとは別に IPv4v6-SSH というセキュリティグループを追加で割り当てないと、SSHは通らない仕様でした。default の中身だけを見て「All許可だから大丈夫」と判断していたのが、そもそもの見落としでした。

直し方

管理画面の「セキュリティグループ」一覧に、IPv4v6-SSH が最初から用意されていることを確認
サーバーの「ネットワーク情報」→ セキュリティグループの編集から、IPv4v6-SSH を追加して適用

これで無事に接続できました。

ConoHaのセキュリティグループの設定 — ConoHaの管理画面では、サーバーの「ネットワーク情報」の②で確認できます。このブログでは default に加えて IPv4v6-SSH と IPv4v6-Web を付けています

後日談:サイトを公開するときにも同じ罠

このあとNginxを入れてサイトを公開しようとしたところ、今度はブラウザで http://xxx.xxx.xxx.xxx を開いても「応答時間が長すぎます」と出ました。原因はまったく同じ構造で、HTTP/HTTPS用にも IPv4v6-Web というセキュリティグループが別に必要でした。

ConoHa VPS 3.0では用途ごとに専用のグループを追加する必要があり、default だけでは実質何も通らない、ということです。

ファイアウォールは2か所にある

この件で一番の学びは、通信を止める「関所」が2か所あるということでした。

インターネット
   ↓
① ConoHaのセキュリティグループ(サーバーの外の関所)
   ↓
② サーバーの中のufw(OSの関所)
   ↓
Nginx / SSH

① セキュリティグループ(ConoHa側)

VPSがあるデータセンターの入口に立っている関所です。

ConoHaの管理画面で設定する
サーバーの外、ネットワーク機器のレベルで通信を止める
サーバー(Ubuntu)が起動していなくても働いている

② ufw(サーバーの中)

サーバー(Ubuntu)自身が持っている関所です。

SSHで入ったあと、コマンドで設定する
OSの中で動くソフトウェア
sudo ufw status verbose で確認できる

両方そろって、はじめて通れる

どちらか一方だけ許可しても、通信は通りません。 マンションに例えるとこうです。

	セキュリティグループ	ufw
ある場所	サーバーの外(ConoHa側)	サーバーの中(OS)
設定する場所	ConoHaの管理画面	SSHで入ってコマンド
例えるなら	マンションのオートロック	部屋のドアの鍵

オートロックが開いていても、部屋の鍵がかかっていれば入れません。部屋の鍵を開けていても、オートロックを通れなければ部屋の前までたどり着けません。

今回のSSHは「部屋の鍵(ufw)は開いているのに、オートロック(セキュリティグループ)で止まっていた」状態でした。ufwだけ見て「許可されている」と安心していたのが、遠回りの原因です。

つながらないときに見る順番

今はこの順番で確認するようにしています。

ConoHaのコンソールで入れるか(サーバーが動いているか)
systemctl status ssh や systemctl status nginx(サービスが動いているか)
sudo ufw status verbose(サーバーの中の関所)
ConoHaの管理画面の「ネットワーク情報」のセキュリティグループ(サーバーの外の関所)
外部のポートチェッカー(外から見て開いているか)

3と4は必ずセットで見ます。この二重構造を理解してから、ポート関係のトラブルはすぐに切り分けられるようになりました。

つまずきポイントのまとめ

つまずいたこと	原因	学んだこと
SSH接続がタイムアウトし続けた	ConoHa VPS 3.0では、SSH用のセキュリティグループ(`IPv4v6-SSH`)を別に追加する必要があった	「All許可のグループがあるから大丈夫」と思い込まず、公式のヘルプを確認する
サイト公開時にも同じ症状が出た	HTTP/HTTPS用の `IPv4v6-Web` も別に必要だった	用途ごとに専用グループが要ると先に知っていれば、時間をかなり短縮できた
切り分けに時間がかかった	ufwだけ見て「許可されている」と判断していた	ファイアウォールは2か所。必ず両方見る
全部正常に見えるのにつながらない	サービス提供元の独自仕様だった	自分の設定が全部正しく見えるときは、サービス側の追加設定を疑う

接続できたあとは、パスワードではなく鍵で入る「公開鍵認証」に切り替えました。手順は第5回環境づくり編にあります。作業中は今つながっているSSHを切らずに、別のウィンドウで新しく接続できるか試すのが鉄則です。設定を間違えても、元の接続が生きていれば直せます。

一つひとつの原因は分かってみれば単純でしたが、「サーバーも自分の環境も正常」という状況から答えにたどり着くまでが本当に大変でした。ConoHa VPSを使う人には共通する話なので、同じ症状で困っている人の助けになればうれしいです。