ConoHa WING は、SSH も WP-CLI も対応していると公式ページに書いてあるし、Xserver やさくらと同じ感覚で動くと思って触ると、意外と一手間かかるサーバーでした。実運用に組み込むまでに踏んだ罠を 5 つ並べておきます。
罠① SSH ポートが 22 ではなく 8022
普段ポート指定なしで SSH 接続している人や、自動化スクリプトに 22 をハードコードしている場合、最初の接続でタイムアウトを食らいます。
ssh -p 8022 c1234567@xxxx-xxxx.conohawing.com
エラーメッセージが「接続できません」「タイムアウト」系なので、原因がポート番号だけだとは中々気づけない。
罠② SSH 鍵は .pem 形式
コントロールパネルで発行される鍵は .pem ファイル。中身は OpenSSH 互換の秘密鍵なので普通に使えますが、macOS だけは chmod 600 ~/.ssh/conoha.pem を一度実行しないと「Permissions are too open」で読んでくれません。Windows は %USERPROFILE%\.ssh\ に置けばたいてい権限調整なしで動きます。
罠③ WP-CLI がそのままでは見つからない
Xserver・さくら・Heteml と違って、wp コマンドが PATH の通った場所に置かれていません。
$ wp --info
-bash: wp: command not found
$ which wp
（何も出ない）
自分で ~/bin/wp に配置してあげる必要があります。
罠④ ファイルマネージャー経由のアップロードで PHAR が壊れる
これが一番ハマったところ。
ターミナルを開かずに「Mac で wp-cli.phar をダウンロード → リネームして wp → コントロールパネルのファイルマネージャー（ブラウザ）でドラッグ＆ドロップ」という流れで配置すると、ファイルサイズもパーミッションも正常なのに broken signature で落ちることがあります。
Fatal error: Uncaught PharException: phar "/home/c1234567/bin/wp"
SHA1 signature could not be verified: broken signature
確実なのは、Mac もファイルマネージャーも経由せず、SSH 接続してから curl で直接取得すること。
ssh -p 8022 c1234567@xxxx-xxxx.conohawing.com '
mkdir -p ~/bin && cd ~/bin &&
curl -sO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar &&
mv wp-cli.phar wp && chmod 755 wp &&
~/bin/wp --info
'
このあたり、再現実験と PHAR の SHA1 署名のしくみを別記事に書きました：コマンドが見つからない… WP-CLIが動かない理由
罠⑤ wp コマンドは絶対パスで呼ぶ
~/bin を .bashrc で PATH に通しても、非対話シェル（自動化スクリプト等）からは .bashrc が読み込まれないことが多く、「対話 SSH では動くのに、cron からだと動かない」というやっかいな問題になりがち。
確実なのは絶対パスで呼ぶこと。
/home/c1234567/bin/wp plugin list
c1234567 の部分はアカウントごとの SSH ユーザー名。コントロールパネルの「サーバー管理 → SSH」画面で確認できます。
チェックリスト
- SSH ポートは 8022（22 ではない）
- 秘密鍵は .pem 形式。macOS は
chmod 600忘れずに - WP-CLI は 自分で
~/bin/wpに配置 - ファイルマネージャー経由のアップロードは NG。SSH + curl 直接取得が確実
- 自動化からは 絶対パス（
/home/c1234567/bin/wp）で呼ぶ
「対応サーバー一覧」に ConoHa WING が入っていても、運用に組み込む時はこの 5 項目を最初に確認するのが安全です。