XServerへSSH公開鍵認証で接続する方法

2026年9月1日サーバー・SSH

記事形式：設定・構築更新日：2026年9月1日

最初に接続値をサーバーパネルで固定する

SSH公開鍵認証では、鍵を作る前に「どの契約の、どのhostへ、どのuserとportで接続するか」を固定します。検索記事からhost名を推測したり、別契約の値を流用したりすると、正しい鍵でも接続できません。XServerのサーバーパネルと公式manualを正本にします。

この記事では説明用に、対象planをXServerレンタルサーバーのスタンダード、サーバーIDを sv-example、hostを sv12345.xserver.jp と仮定します。これらは架空値です。公開時点のplan名・機能提供範囲は料金・機能一覧、個別契約はXServerアカウント、接続値は対象サーバーのパネルで2026年8月25日に再確認する前提です。

XServer公式「SSH設定」は、サーバーパネルでSSH設定を有効にし、公開鍵認証を使う手順の確認先です。「サーバー情報」はhost等の個別情報を確認する場所です。XServerのSSH接続portとして公式manualに示される 10022、userとしてサーバーID、hostとしてサーバー情報に表示されるhost名を、作業票へ転記して二者確認します。画面が違う、対象planで機能が見つからない、値を確認できない場合は推測せず停止します。

項目	本例の記入値	信頼する確認箇所	不一致時の扱い
対象service・plan	XServerレンタルサーバー／スタンダード（架空契約）	XServer公式料金・機能一覧とXServerアカウントの契約表示、確認日2026-08-25	plan名・SSH提供範囲が一致するまで鍵登録しない
SSH有効化	対象サーバーの「SSH設定」でON	XServer公式「SSH設定」―SSH設定の変更と公開鍵認証	別server ID、権限不足、設定反映中なら接続試験しない
認証方式	公開鍵認証	同資料―公開鍵認証用鍵ペア／公開鍵登録の手順	password認証へ切り替えて回避しない
HostName	`sv12345.xserver.jp`（架空）	サーバーパネル「サーバー情報」のホスト名	契約通知や別記事の値と混ぜず、panel値を再確認
User	`sv-example`（架空サーバーID）	サーバー情報・対象契約のサーバーID	WordPress user、mail account、XServerアカウントIDを使わない
Port	`10022`	XServer公式「SSH設定」―SSH接続方法	22へ変更して試行せず、公式manualの現行値を確認

XServerの管理account、WordPress user、SSH userは別の識別子です。似た文字列でも役割を混ぜません。作業票には秘密鍵やpassphraseを書かず、接続alias、公開鍵fingerprint、登録者、登録・失効日だけを記録します。

秘密鍵は手元、公開鍵だけをサーバーへ登録する

秘密鍵は本人側に保持し、署名によって所持を証明する材料です。公開鍵は接続先へ登録して照合に使います。.pubが公開鍵、拡張子なしの対応fileが秘密鍵になる一般的なOpenSSH構成でも、file名だけで判断せずssh-keygenでfingerprintを照合します。

秘密鍵をserver panel、ticket、chat、repositoryへ貼りません。XServerへ登録するのは公開鍵一行です。秘密鍵を失うと本人が接続できず、漏えいすると第三者が接続を試せます。passphraseは、秘密鍵fileが盗まれた場合に直ちに利用されにくくする防壁です。空にせず、組織のpassword管理方針に従います。

1. 専用directoryと鍵を作る

次はLinux/macOSのOpenSSH例です。既存fileを上書きしないよう、先に対象を確認します。

install -d -m 0700 "${HOME}/.ssh"
test ! -e "${HOME}/.ssh/xserver_example_ed25519"
test ! -e "${HOME}/.ssh/xserver_example_ed25519.pub"
ssh-keygen -t ed25519 \
  -a 64 \
  -f "${HOME}/.ssh/xserver_example_ed25519" \
  -C "xserver:sv-example:ops-01:2026-08-25"
chmod 0600 "${HOME}/.ssh/xserver_example_ed25519"
chmod 0644 "${HOME}/.ssh/xserver_example_ed25519.pub"
ssh-keygen -lf "${HOME}/.ssh/xserver_example_ed25519.pub" -E sha256

xserver_example_ed25519は本例の専用file名、commentのsv-exampleは架空サーバーID、ops-01は個人を組織台帳で追跡できる鍵owner IDです。実行中に強いpassphraseを設定します。command historyへpassphraseを渡しません。

test ! -eが失敗したら既存鍵を上書きせず、台帳でownerと用途を確認します。ssh-keygen -lfが表示するSHA-256 fingerprintを登録票へ保存します。公開鍵本文を公開記事や広いlogへ残す必要はありません。Ed25519が対象環境・組織方針で利用できない場合は、XServer公式の対応方式と組織の暗号方針を確認し、勝手に弱い方式へ変更しません。

2. 公開鍵の形式を検査して登録する

ssh-keygen -y -f "${HOME}/.ssh/xserver_example_ed25519" \
  > "${HOME}/.ssh/xserver_example_ed25519.derived.pub"
ssh-keygen -lf "${HOME}/.ssh/xserver_example_ed25519.pub" -E sha256
ssh-keygen -lf "${HOME}/.ssh/xserver_example_ed25519.derived.pub" -E sha256
cmp "${HOME}/.ssh/xserver_example_ed25519.pub" \
    "${HOME}/.ssh/xserver_example_ed25519.derived.pub"
rm "${HOME}/.ssh/xserver_example_ed25519.derived.pub"

秘密鍵から導出した公開鍵と登録予定の.pubが一致することを確認します。comment差でcmpが違う場合がある運用では、fingerprintの一致を正本にします。不一致なら別鍵の公開鍵を登録しようとしているため停止します。

XServerの対象サーバーパネルで「SSH設定」を開き、サーバーIDを再確認してSSHを有効化します。公開鍵登録欄へ.pubの一行だけを登録します。panelが秘密鍵を生成・downloadする方式を選ぶ場合も、download fileの保管、permission、fingerprint、passphrase、失効手順を同じ台帳で管理し、記事例と混在させません。

登録後、panelの登録済み鍵の識別情報と手元fingerprintを記録します。反映待ちの案内があれば完了前に連続試行しません。対象server ID、登録者、fingerprint、時刻が一致しなければ接続へ進みません。

ssh_configで鍵・host key・非対話試験を固定する

~/.ssh/configへ次の完全なentryを置く例です。既存configがある場合は上書きせず、重複Hostや先行するwildcard設定をssh -Gで確認します。

Host xserver-example
    HostName sv12345.xserver.jp
    User sv-example
    Port 10022
    IdentityFile ~/.ssh/xserver_example_ed25519
    IdentitiesOnly yes
    BatchMode yes
    PreferredAuthentications publickey
    PasswordAuthentication no
    KbdInteractiveAuthentication no
    StrictHostKeyChecking yes
    UserKnownHostsFile ~/.ssh/known_hosts_xserver_example
    ServerAliveInterval 30
    ServerAliveCountMax 3
    LogLevel INFO

Host xserver-exampleは人が使うalias、HostName、User、Portはpanelと公式manualで確認した値です。IdentityFileは専用秘密鍵、IdentitiesOnly yesはagent内の別鍵を次々提示せず指定鍵へ限定します。鍵を多く試してserver側の試行上限へ達する問題も避けやすくなります。

BatchMode yesは非対話の接続試験でpassword等のprompt待ちを避けます。日常の対話sessionでpassphraseを安全に入力する運用では、agentへ事前登録するか試験時だけ-o BatchMode=noを承認して使います。記事例では自動処理が別認証へfallbackしないことを優先します。

StrictHostKeyChecking yesは未知・変更されたhost keyを自動受入れしません。UserKnownHostsFileはこの契約専用にし、他hostのrecordと混ぜません。PasswordAuthentication noとKbdInteractiveAuthentication noは公開鍵以外へのfallbackを止めます。

file permissionを確認します。

chmod 0700 "${HOME}/.ssh"
chmod 0600 "${HOME}/.ssh/config"
chmod 0600 "${HOME}/.ssh/xserver_example_ed25519"
touch "${HOME}/.ssh/known_hosts_xserver_example"
chmod 0600 "${HOME}/.ssh/known_hosts_xserver_example"
ssh -G xserver-example \
  | awk '/^(hostname|user|port|identityfile|identitiesonly|batchmode|stricthostkeychecking|userknownhostsfile) /'

期待はhost、user、port、IdentityFile、yesの各制御、専用known_hostsが設定例と一致することです。別Host entryやIncludeで値が変わっていれば接続しません。ssh -Gは有効設定の確認で、network接続は行いません。

host keyは初回接続より前に別経路で照合する

公開鍵認証はclientの本人性をserverへ示しますが、接続先serverが正しいことはhost keyで確認します。初回に表示されたfingerprintを、その同じ接続画面だけで信頼すると、中間者の値でも受け入れてしまいます。

信頼できる確認元は、XServerが対象契約のサーバーパネル、契約者向け公式案内、または本人確認を伴う公式support経路で示すhost key fingerprintです。一般blog、検索snippet、別server IDのfingerprint、接続時promptだけを正本にしません。公式公開ページに一律fingerprintが見つからない場合、serverごとの値を公式supportへ対象server ID付きで確認し、回答IDと時刻を記録します。

取得したfingerprintとhost・portを作業票へ登録し、network担当または別担当が二者確認します。その後にscan結果を比較します。

HOST="sv12345.xserver.jp"
PORT="10022"
EXPECTED_SHA256="<official-host-key-sha256>"
SCAN_FILE="$(mktemp)"
ssh-keyscan -p "${PORT}" -t ed25519 "${HOST}" > "${SCAN_FILE}"
ssh-keygen -lf "${SCAN_FILE}" -E sha256
printf 'Expected: SHA256:%s\n' "${EXPECTED_SHA256}"

ssh-keyscanは接続先が提示する鍵を取得するだけで、それ自体は相手を認証しません。出力fingerprintを<official-host-key-sha256>と人が比較し、鍵type、host、portも一致した場合だけ専用known_hostsへ登録します。

cat "${SCAN_FILE}" >> "${HOME}/.ssh/known_hosts_xserver_example"
chmod 0600 "${HOME}/.ssh/known_hosts_xserver_example"
rm "${SCAN_FILE}"
ssh-keygen -F "[sv12345.xserver.jp]:10022" \
  -f "${HOME}/.ssh/known_hosts_xserver_example"

fingerprintが不一致、公式値を取得できない、鍵typeが違う場合は接続を停止します。StrictHostKeyChecking no、UserKnownHostsFile /dev/nullで警告を消しません。ssh-keygen -Rで既存recordを安易に削除もしません。host移行や鍵rotationの公式告知、対象server、変更時刻を確認し、旧recordを証跡として保存して承認後に置換します。

接続試験は副作用のないcommandから始める

host key登録後、最初はremote shellを開かず、身份・home・current directoryだけを表示します。

ssh xserver-example 'id; printf "HOME=%s\n" "$HOME"; pwd; umask'

期待はuserが架空のsv-example、homeが対象account、current directoryが想定内、umaskが組織基準と矛盾しないことです。root、別サーバーID、想定外directoryなら以後のcommandを送りません。接続成功をもってWordPress pathや書込み権限まで正しいとは判断しません。

非対話試験は次です。

ssh -o BatchMode=yes xserver-example 'printf "ssh-publickey-ok\n"'

期待結果はssh-publickey-okと終了code 0で、password・keyboard-interactive promptが出ないことです。passphraseをagentへ未登録ならBatchModeで失敗し得るため、その場合は秘密鍵の漏えいと決めつけず、local agent状態を確認します。自動化でpassphraseを平文fileやcommand lineへ書きません。

Permission deniedを四つの分岐で診断する

失敗時はssh -vvvのdebugをaccess制御した一時記録へ出し、秘密や個人情報を広く共有しません。debug全文をsupportへ送る前に内容を確認します。

症状・分岐	読取りで確認すること	修正	停止条件
`Permission denied (publickey)`	`ssh -G`のhost/user/port/identityfile、`ssh-keygen -lf`、panelの登録fingerprint、SSH有効状態	正しい公開鍵を正しいserver IDへ登録し直す。旧鍵は状態確定後に失効	別userやpasswordを推測して連続試行しない
鍵形式・読込error	`ssh-keygen -y -f <private-key>`が成功するか、OpenSSH version、改行・file破損	承認済みbackupから鍵を戻すか新鍵を作り公開鍵を交換	秘密鍵を変換siteへuploadしない。原本不明なら旧鍵失効へ
port・host到達不能	panelのhost、公式port 10022、DNS、公式障害・maintenance、local firewall	正しい値とnetwork経路を管理者が確認	22等を総当たりしない。障害中にserver設定を変更しない
file mode・owner不良	`ls -ld ~/.ssh`、`ls -l`、`namei -l`、秘密鍵・config・known_hostsのowner/mode	自分の管理fileだけを0700/0600へ。server側はpanel手順を使う	rootで一括`chown -R`しない。対象外pathやownerなら停止

debugでOffering public keyがなくても、すぐserver側を変更しません。clientが異なるconfigを読み、agentの鍵だけを使っている可能性があります。ssh -GとIdentityFileの存在・fingerprintを先に確認します。

Offering public keyの後に拒否されるなら、登録先server、user、public key、SSH有効状態を照合します。鍵を再生成する前に、手元private keyとpanel登録public keyのfingerprintが同じか確認します。原因不明の鍵を増やすと失効対象が分からなくなります。

timeoutやconnection refusedは認証以前の問題です。host、port、network、公式障害情報を調べます。認証errorと混ぜず、server panelのSSH設定をon/off反復しません。

紛失・漏えい時は追加より先に旧鍵を失効する

laptop紛失、秘密鍵を誤ってrepositoryへcommit、第三者へ送信、fingerprint不明のcopy発見は鍵incidentです。passphraseがあっても安全と断定せず、対象accountへの接続を止め、incident責任者へ連絡します。

旧鍵fingerprint、owner、対象server ID、発覚時刻、最後の正当利用を台帳から特定する。
XServerサーバーパネルの登録鍵から、対象fingerprintの公開鍵を失効・削除する。別担当の鍵を消さない。
access log、login履歴、変更履歴など利用可能な証跡を対象期間で確認する。調査前にlogを消さない。
安全な端末で新しい専用鍵とpassphraseを作り、新fingerprintを二者確認して登録する。
ssh_configのIdentityFile、agent、backup、automation参照を新鍵へ更新する。旧秘密鍵を通常削除する前にincident証跡と対象を確定する。
専用known_hostsはserver host key用であり、client鍵交換を理由に削除しない。host keyとuser keyを混同しない。
非対話接続試験とremoteidを実施し、新鍵成功・旧鍵失敗を別々に確認する。

旧鍵失敗試験は、削除前の秘密鍵を無秩序に配布せず、incident担当が隔離された環境で一回行います。期待はPermission denied (publickey)であり、password fallbackを無効にします。新鍵成功だけでは、旧鍵が無効になった証明になりません。

repositoryへ秘密鍵が入った場合、fileを最新commitから削除するだけで漏えいを解消したことにはなりません。まず鍵を失効し、repositoryの公開範囲とcopy先をincident担当が評価します。履歴処理は組織の承認済み手順で行い、この記事の一般commandで実施しません。

退職・役割変更でも同じ失効手順を期限付きで行います。共用鍵なら一人だけを失効できないため、利用者全員の鍵交換が必要です。最初から個人・端末・用途別に鍵を分け、台帳にownerと期限を持たせる方が影響を小さくします。

四半期ごとに接続できることと失効できることを試す

四半期には、対象plan・server ID・host・user・port、SSH有効状態、登録鍵owner、fingerprint、最終使用、端末、失効期限を確認します。不要鍵を削除し、接続試験とlog確認を行います。鍵fileがあるだけで利用可能とは扱いません。

年1回または担当交代時には、test用鍵を登録し、接続、失効、旧鍵拒否までを訓練します。本番の唯一の管理鍵を訓練で消さず、回復経路と複数の正当管理者を確認します。公式supportへ問い合わせる場合に必要な契約・server情報も、秘密を含めず準備します。

SSH鍵管理の完成条件は「一度つながった」ではありません。接続値を公式情報から再現でき、指定鍵だけを提示し、host keyを別経路で照合し、漏えい時に対象鍵だけを止め、新旧の成否を確認できることです。まず作業票、専用鍵、専用Host entry、fingerprint二者確認から始めてください。

お問い合わせ

XServerへSSH公開鍵認証で接続する方法

最初に接続値をサーバーパネルで固定する

秘密鍵は手元、公開鍵だけをサーバーへ登録する

1. 専用directoryと鍵を作る

2. 公開鍵の形式を検査して登録する

ssh_configで鍵・host key・非対話試験を固定する

host keyは初回接続より前に別経路で照合する

接続試験は副作用のないcommandから始める

Permission deniedを四つの分岐で診断する

紛失・漏えい時は追加より先に旧鍵を失効する

四半期ごとに接続できることと失効できることを試す

関連記事

柳川市のコワーキング・インキュベーションスペース

ソーシャルスクールの商標権について

大川未来塾様で講演をさせていただきました

NPO法人日本ソーシャルスクール協会のHP閉鎖について

生成AIを導入しても業務改善につながらない理由｜見直す7つの条件