どうも。
まず、ブログのテーマ更新（Xserver）を楽にするにあたって、
githubにリポジトリを作って管理することから始めました。
AIによると、子テーマだけ管理すればいいとのことでしたので、子テーマだけpushしました。
これでテーマ管理は楽になるのですが、サーバーにあげるのがまだ面倒、、、
どうせやるなら自動デプロイもしてほしいよなあ！
そう思い立ったが、ここからが長かった、、、
広大な海へ旅立ち、徒歩1秒で見つけたこちらのサイトを参考にレッツトライ。https://zenn.dev/joh_luck/articles/6e0d029bd6a33a
しかし、序盤にて詳しいことはググれというハードスタイルが故、すぐAIに泣きつきました。
助けてぇ、ドラえもぉぉぉん(´;ω;｀)
で、この記事はここからが本編なのです。
が、今回の記事はほぼAI頼みです。
ブログのテーマ更新を楽にしたくて色々コーくん（Copilot）に聞いて聞いて聞きまくりました。
AIの奴隷とお呼びください。
ほな、AIに今回の内容もまとめてもらいましょう。
では、どうぞ。
1. 環境準備：GitHub と Xserver の下ごしらえ
1.1 SSH設定（初回設定）
GitHub Actions から Xserver に接続するためには、まずサーバー側で SSH を使える状態にしておく必要がある。Xserver の SSH 設定は少し独特で、初回は “公開鍵の登録” がそのまま SSH の有効化になる。
初めて SSH 設定画面を開いたときは、まだ有効化できる公開鍵が存在しないため、 「公開鍵を登録」から始めるのが正しい流れになる。
初回設定の手順
- Xserver のサーバーパネルにログイン
- 左メニューの 「SSH設定」 を開く
- 画面上部の 「公開鍵を登録」 をクリック
- 表示される公開鍵登録フォームで
- 登録方式：自動生成
- ラベル：任意（デフォルトのままでOK）
- パスフレーズ：空欄でOK
- 「登録して秘密鍵をダウンロード」 を押す
この操作を行うと：
- Xserver に公開鍵が登録される
- SSH が自動的に有効化される
- 画面上部の 「設定状況」が ON になる
- ローカルに 秘密鍵（.key） がダウンロードされる
- ※ Xserver は OpenSSH 形式の .key を配布する仕様
- ※ AWS などで見かける .pem とは異なるが問題なし
2回目以降の SSH設定画面でできること
初回登録が終わると、SSH設定画面には「登録済み公開鍵」が表示され、次の操作が可能になる。
- 公開鍵ごとの SSH有効化／無効化
- 公開鍵の 削除
- 新しい公開鍵の 追加登録
つまり、初回だけは「公開鍵登録＝SSH有効化」だが、 2回目以降は通常の管理画面として扱えるようになる。
1.2 GitHub Actions を動かすための前提
GitHub Actions は、GitHub 上で自動的にスクリプトを実行できる仕組みだ。 今回の目的は「GitHub に push → Xserver に自動反映」なので、最終的には次の流れを作る必要がある。
- GitHub Actions が Xserver に SSH 接続
- サーバー側で
git pullを実行 - テーマの最新状態が反映される
この仕組みを成立させるために、後で SSH鍵の生成・配置 と GitHub Secrets の設定 を行う。 ここが今回の作業の中で最もトラブルが起きやすい部分でもある。
1.3 デプロイ先ディレクトリの確認
Xserver 側で、テーマを配置するディレクトリを事前に確認しておく。 これは サーバーパネル →「ファイル管理」 から確認できる。
- サーバーパネルの 「ファイル管理」 を開く
- ドメイン名フォルダ →
public_html→wp-content/themes/と進む - 子テーマ（例：
cocoon-child-master）のフォルダを確認 - このフォルダのパスを控えておく
例：
コード
/home/ユーザーID/ドメイン名/public_html/wp-content/themes/cocoon-child-master
GitHub Actions から git pull を実行する際、このディレクトリにアクセスする必要があるため、正確なパスを把握しておくことが重要。
1.4 ここまでで整ったこと
- Xserver の SSH が 公開鍵登録によって有効化 された
- ローカルに秘密鍵（.key）がダウンロードされた
- GitHub Actions が接続するための前提（ポート番号・ユーザー名）が揃った
- デプロイ先ディレクトリを ファイル管理画面で確認 できた
ここまでが、自動デプロイの“土台づくり”。 次の章から、いよいよ SSH鍵の生成と配置 という本番に入っていく。
2. GitHub Actions 用の鍵ペアを生成し、配置する
1章で Xserver の SSH を有効化し、ログイン用の秘密鍵（.key）を取得した。
ここからは、GitHub Actions が Xserver に接続するための専用鍵ペアを作り、正しい場所に配置していく。
2.1 Xserver に SSH ログインする
まず、1章でダウンロードした .key を使って Xserver にログインする。
手順
ssh -i ダウンロードしたkeyファイルのパス \
サーバーID@svXXXX.xserver.jp -p 10022
ログインできれば、Xserver 側の SSH が正しく有効化されている証拠になる。
2.2 GitHub Actions 用の鍵ペアを生成する
GitHub Actions から Xserver に接続するためには、専用の鍵ペアを作る必要がある。
これは Xserver 上で生成する。
手順
ssh-keygen -t ed25519 -f ~/.ssh/github
- パスフレーズは空欄でOK
- 生成されるファイル
~/.ssh/github（秘密鍵）~/.ssh/github.pub（公開鍵）
2.3 公開鍵（github.pub）を authorized_keys に登録する
GitHub Actions が Xserver に接続できるように、公開鍵を登録する。
手順
cat ~/.ssh/github.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh
これで Xserver は github.pub の鍵を持つクライアントを受け入れる準備が整う。
2.4 GitHub に秘密鍵（github）を登録する
GitHub Actions が秘密鍵を使えるように、GitHub Secrets に登録する。
手順
- Xserver 上で秘密鍵を表示
cat ~/.ssh/github - BEGIN〜END までを 改行を含めてそのままコピー
- Windows Terminal でのコピーが安全
- GitHub リポジトリ →
Settings → Secrets and variables → Actions - SSH_PRIVATE_KEY という名前で登録
2.5 ここまでで整ったこと
- GitHub Actions 専用の鍵ペア（github / github.pub）が生成された
- 公開鍵が authorized_keys に登録され、認証が可能になった
- 秘密鍵が GitHub Secrets に登録され、Actions が使える状態になった
ここまでで、GitHub Actions が Xserver に接続するための準備が完了した。
次の章では、実際に起きたエラーと、その原因をどう特定していったかをまとめていく。
3. 最初のエラー祭り：Permission denied と格闘
GitHub Actions 用の鍵を整えて「これで接続できるはず」と思った直後に出迎えてくれたのが、 Permission denied (publickey) というエラーだった。 SSH 接続の段階で止まっており、Xserver に到達する前に弾かれている状態だった。 ここから、原因を一つずつ切り分けていく作業が始まった。
3.1 エラー内容を落ち着いて読む
GitHub Actions のログを見ると、SSH クライアント側が「有効な公開鍵がない」と判断して接続を拒否している形だった。 つまり、コマンドの問題ではなく、鍵の組み合わせか配置が間違っている可能性が高い。
ポイント
Permission denied (publickey)は「鍵が認識されていない」サイン- GitHub Actions 側と Xserver 側のどちらが原因かを切り分ける
3.2 公開鍵の不一致を疑う
最初に疑ったのは、Xserver に登録されている公開鍵と、 GitHub Actions が使っている秘密鍵が本当にペアになっているかどうかだった。 Xserver には「ログイン用の鍵」と「GitHub Actions 用の鍵」が混在しやすく、 どの鍵がどの用途なのか曖昧になりやすい。
確認したこと
~/.ssh/github.pubの内容が正しいかauthorized_keysにgithub.pubが追記されているか- 不要な鍵が複数登録されていないか
3.3 authorized_keys の落とし穴
次に疑ったのは authorized_keys 自体の書式だった。 公開鍵を追記する際に余計な空行やスペースが入っていたり、 鍵が途中で改行されていると、SSH が正しく認識してくれない。
見直したポイント
- 鍵が 1 行ごとに並んでいるか確認
- 途中で改行されていないかチェック
- 不要な空行や謎の文字を削除
3.4 GitHub 側の Deploy Keys / Secrets を整理する
GitHub 側にも過去に試した鍵が複数残っており、 どれが現在使われているのか分かりにくくなっていた。 一度リセットするつもりで、不要な鍵を削除し、最小構成に戻した。
行ったこと
- 不要な Deploy Keys を削除
- 使っていない Secrets を整理
- 現在使う鍵だけを登録し直す
3.5 ここまでで見えてきたこと
Permission denied (publickey) と向き合う中で分かったのは、 「設定を増やすより、まずは減らしてシンプルにする方が原因にたどり着きやすい」ということだった。 鍵の種類や登録場所が増えるほど、どこか一箇所のズレを見落としやすくなる。
この段階で得た学び
- ログイン用の鍵と GitHub Actions 用の鍵は役割を明確に分ける
authorized_keysは「きれいな 1 行 1 鍵」に保つ- GitHub 側の鍵設定は最小構成にすると原因を追いやすい
Permission denied (publickey) を乗り越えたあと、次に現れたのが EOF という謎のエラーだった。
4. EOF の正体：鍵は正しいのに接続できない理由
EOF これは「接続が途中で切れた」という意味だが、原因が幅広く、 最初はどこから手をつければいいのか分からなかった。
4.1 EOF は「鍵が正しい」サインでもある
実は EOF が出るということは、 「公開鍵・秘密鍵のペアは正しく認識されている」ことを意味している。 つまり、前章までの鍵設定はクリアできているということだ。 ここから先は、鍵以外の要因を疑う必要があった。
この時点で分かったこと
- 鍵の不一致ではない
- 接続は開始されているが、途中で落ちている
- 別の設定ミスが原因で通信が途切れている可能性が高い
4.2 改行・エンコード問題を疑う
最初に疑ったのは、GitHub Secrets に登録した秘密鍵の改行が壊れている可能性だった。 特に Windows 環境では、コピー時に改行コードが変わったり、 途中でスペースが入ったりすることがある。
見直したポイント
- 秘密鍵の BEGIN〜END が正しく改行されているか
- 余計なスペースやタブが混入していないか
- VSCode や PowerShell ではなく、Windows Terminal でコピーし直す
4.3 ホスト名の指定ミスを疑う
次に疑ったのは、GitHub Actions の SSH 接続先ホスト名だった。 Xserver のホスト名は svXXXX.xserver.jp の形式だが、 ここを間違えると接続が途中で落ちることがある。
確認したこと
- Xserver のサーバーパネルに表示されているホスト名と一致しているか
- ポート番号が
10022になっているか - ユーザー名（サーバーID）が正しいか
4.4 ローカルからの SSH テストで切り分ける
GitHub Actions だけで原因を追うのは難しいため、 まずはローカルから同じ鍵で SSH 接続できるかを試した。 これに成功すれば、問題は GitHub Actions 側に絞り込める。
テスト方法
ssh -i ~/.ssh/github サーバーID@svXXXX.xserver.jp -p 10022- ローカルでは接続できる → GitHub Actions 側の問題
- ローカルでも接続できない → 鍵 or authorized_keys の問題
私の場合はローカル接続が成功したため、 「鍵は正しい。GitHub Actions 側の設定が怪しい」と切り分けられた。
5. まとめ（AIの奴隷著）
「まとめって？おい！解決してねえじゃねえか！」
おっしゃる通りです。まだ解決していません。
しかし、これ以降コーくんは4.2に執着し、執拗に私にコピペをさせ続けました。
(´;ω;｀)ツライ
さすがの奴隷もこれには辟易し、ジェミちゃん（Gemini）に助けを乞うのでした。
という訳で次回、ジェミちゃんのまとめです。
ご期待ください。
コメント