Kagoya（カゴヤ・ジャパン）の VPS を、新規作成ではなく**コントロールパネルからのOS再インストール（初期化）**で作り直したとき、なぜか最初だけ外部から SSH が繋がらない、という現象に毎回ハマっています。
結論から言うと、初期化したサーバ自身から ping 8.8.8.8 を一発打つと直ります。理屈はわかっていないのですが、再現性は高く、私の環境では契約以来ずっとこの挙動です。同じところで詰まる人のために、現象と暫定対処、調べた範囲を残しておきます。
これは原因が特定できていない経験則ベースの対処メモです。「pingで直る」のは事実ですが、根本原因の解明には至っていません。同じ症状でも環境によっては別の要因の可能性があります。
現象
- Kagoya のコントロールパネル（GUI）から OS を再インストール（初期化） する
- 起動後、別のサーバから SSH で接続しようとすると応答がない（タイムアウトする）
- ところが、初期化したサーバ側のコンソール（GUIのコンソール）からは普通に操作できる
- そのコンソールから外向きに
ping 8.8.8.8を打つと、そこから急に外部 SSH が通るようになる
新規にサーバを「作成」した場合は問題なく繋がります。「初期化（再インストール）」したときだけこの症状が出る、というのがやっかいなところです。
暫定対処：初期化したサーバから外向きにpingを打つ
外部から SSH が無反応なので、ここは Kagoya の Web GUI（コントロールパネル）からコンソールを立ち上げて、そこからサーバにログインし、ping を打ってください。SSH ではなく Web コンソール経由なのがポイントです。
Kagoya の Web GUI でコンソールを立ち上げる
Kagoya のコントロールパネル（Web GUI）から、対象サーバの コンソール（VNC等）を起動します。
コンソールからサーバにログインする（root＋コンソールログインパスワード）
立ち上げたコンソール画面で、サーバに直接ログインします（外部からの SSH が通らなくても、このコンソールからは操作できます）。
ここでのログインは root ユーザで行い、パスワードは**初期化（再インストール）時に指定した「コンソールログインパスワード」**を使います。外部からの SSH 接続で使う rocky ユーザ＋鍵とは別物なので注意してください。
外向きに ping を打つ
ログインしたら、外向きに ping を一発打ちます。
ping -c 4 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=2.34 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=2.31 ms
...これだけで、それまで無反応だった外部からの SSH が通るようになります。宛先は 8.8.8.8（Google Public DNS）でなくても、外部に到達するアドレスなら何でも構いません。
外向きに一度トラフィックを発生させるのがポイントのようです。ping が通らない環境なら、curl https://example.com や dnf check-update のような外向き通信でも代替できる可能性があります（ICMP が遮断されているケース向け）。
正直なところ、Kagoya は 「パスワード」「秘密鍵」「公開鍵」がそれぞれどこにどう設定されているのかが分かりにくいです。整理すると:
| 認証情報 | どこで使う | 何を使うか |
|---|---|---|
| コンソールログインパスワード | Web GUI のコンソール（root ログイン） | 初期化時に指定したパスワード |
| 公開鍵 | サーバ側（rocky ユーザの authorized_keys） | GUI で登録した公開鍵が自動設置 |
秘密鍵（.key） | 手元 → 外部からの SSH 接続 | 「ログイン用認証キー追加」でDLした鍵 |
このあたりはおそらく Kagoya の公式サイトのどこかに記載があるはずなので、正確な仕様は公式ドキュメントもあわせて確認してください。
調べたこと（が、いずれも空振り）
「サーバ側の設定が悪いのでは」と思って、次のあたりを一通り見直しましたが、いずれも問題は見つかりませんでした。
firewalld を止めてみる
ファイアウォールが SSH を弾いているのかと思い、一時的に停止して確認。
sudo systemctl stop firewalld
sudo firewall-cmd --list-all→ 停止しても、ping を打つまでは外部 SSH は通らなかった。firewalld は原因ではない。
sshd の設定を見直す
ListenAddress や AddressFamily、ポート設定など、sshd_config を確認。
sudo sshd -T | grep -Ei 'listenaddress|port|addressfamily'
sudo systemctl status sshd→ sshd は正常に起動し、ローカルからは応答する。設定上の問題は見当たらない。
リンク・経路を確認する
インターフェースや経路、ARP/近隣テーブルもチェック。
ip -br addr
ip route
sudo ss -tlnp | grep :22→ IP は正しく付与され、22番でリッスンしている。見た目には異常なし。
それでも ping 8.8.8.8 を打った瞬間に直るので、サーバ内部の設定というより、初期化直後のネットワーク経路（上流）側が、外向きの通信を一発見るまで戻りパケットを通さないような挙動に見えます。あくまで推測です。
心当たりとしては、上流スイッチ／仮想ネットワークの MAC アドレス学習 や ARP テーブルの更新タイミングあたり。初期化でサーバ側の状態がリセットされ、上流が新しいサーバの存在を認識するまで「外から入ってくる」通信だけが宙ぶらりんになり、サーバが自分から外へ一発出すと経路が確立する……という仮説です。確証はありません。
わかっていること・いないこと
| 項目 | 状況 |
|---|---|
| 再現条件 | Kagoya コントロールパネル（GUI）からの OS再インストール（初期化）時 |
| 確認したOS | Rocky Linux 9 のみ（GUIインストール） |
| 新規作成時 | 問題なし |
| 対処 | 初期化したサーバから外向きに ping 8.8.8.8（または外向き通信）を一発 |
| 根本原因 | 不明（firewalld / sshd / 経路設定には問題なし） |
| 発生期間 | 契約以来（昨年〜）ずっと同じ症状 |
| Kagoyaへの問い合わせ | 未実施（ping で直るため運用上困っていない） |
- Rocky 9 でしか試していないので、別 OS のインストールなら起きない可能性があります。
- 毎回の初期化で忘れていると「あれ、繋がらない…」と無駄に悩むので、初期化したら最初に外向き ping、を儀式にしておくと安全です。
補足：Rocky 9 ではログインユーザは rocky、鍵は GUI 登録のものが入る
そもそも「繋がらない」と思っていた原因が、接続ユーザや鍵の取り違えだった、というのも初期化あるあるです。pingの話とあわせて整理しておきます。
Kagoya の Rocky Linux 9 を GUI から構築した場合:
- GUI で登録した公開鍵が
rockyユーザに設置されます（rootではない） - したがって外部からは
rockyユーザで接続する必要があります
ssh -i <ダウンロードした鍵ファイル>.key rocky@<契約したVPSのIPアドレス>鍵を Kagoya の GUI で生成した場合
コントロールパネルの 「ログイン用認証キー追加」ボタンから鍵を生成すると、.key ファイル（秘密鍵）が自動でダウンロードされます。その鍵ファイルを -i で指定して接続します。
GUIで認証キーを追加
Kagoya のコントロールパネルで「ログイン用認証キー追加」ボタンから鍵を生成。.key ファイルがダウンロードされる（このとき以外に再ダウンロードできないことが多いので必ず保管）。
鍵ファイルのパーミッションを絞る
ダウンロードした秘密鍵は、所有者だけが読めるようにしておく（緩いと SSH が拒否する）。
chmod 600 ~/Downloads/<ダウンロードした鍵ファイル>.keyrocky ユーザで接続
ssh -i ~/Downloads/<ダウンロードした鍵ファイル>.key rocky@<契約したVPSのIPアドレス>root@... で繋ごうとして弾かれているだけ、というケースも多いです。Rocky 9 は基本 root の直接 SSH ログインを許可しない設定で、かつ GUI 登録の鍵は rocky ユーザに入ります。「鍵は正しいのに繋がらない」ときは、まず接続ユーザが rocky になっているかを確認してください。
それでも基本は押さえておく
「pingで直るから」で済ませてはいますが、SSH が外から繋がらないときに最初に疑うべき正攻法は変わりません。今回はたまたまどれも該当しませんでしたが、切り分けの基本として:
ファイアウォールで22番が開いているか
sudo firewall-cmd --list-services
sudo firewall-cmd --add-service=ssh --permanent && sudo firewall-cmd --reloadsshd が起動・リッスンしているか
sudo systemctl status sshd
sudo ss -tlnp | grep :22Kagoya側のパケットフィルタ／セキュリティ設定
Kagoya のコントロールパネルにもパケットフィルタ／セキュリティグループ的な設定がある場合があります。OS のファイアウォールとは別レイヤなので、初期化で設定が戻っていないか・SSH(22) が許可されているかを確認しておくと安心です。
これらに問題がないことを確認したうえで、それでも繋がらないなら——外向きに ping を一発、です。
もし同じ症状で、原因の心当たりや確かな情報をお持ちの方がいたら、ぜひ知りたいところです。気が向いたら Kagoya にも問い合わせてみようと思います。
