さくらのVPSにSSH接続できないときは？通信と認証を分けて確認

エラーと現在の接続条件を記録する

まず、表示されたエラーをそのまま控え、失敗した段階を分けましょう。以下は一般的な表示例と、最初に確認する場所の対応です。

表を入口に、失敗した段階から原因を絞りましょう。例えば接続拒否なら、まず宛先の誤りを除外し、その後にSSHの待受や通信を拒否する設定を調べます。

接続先IP、SSHの実ポート、VPSのOS、ログインユーザー、使ったクライアントと、直前に変更した設定を記録してください。問い合わせや共有ログへ、秘密鍵の内容、パスワード、トークンを貼る必要はありません。

接続先と通信到達を確認する

設定を直す前に、いま接続している宛先が対象のVPSかを確認します。ドメイン名を使っているなら、名前解決とIP直接指定を分けると調べやすくなるためです。

1. 権限のあるコントロールパネルで対象VPSを選び、現在のIPと起動状態を照合してください。
2. ドメイン名を使う場合は、手元のPCで名前解決したIPと、対象VPSの現在IPを比べます。
3. SSHポートは、既定値の22番ではなく実際に設定した番号との一致が確認点です。
4. 公式の障害・メンテナンス情報に加え、社内ネットワークやPC側の送信制限も調べましょう。

手元のPCのmacOSやWindowsのWSL2等で、OpenSSHクライアントから鍵認証を使う場合の診断コマンドは次の形です。大文字部分と鍵のパスを、自分の接続条件に置き換えて実行します。

ssh -v -p PORT -i /path/to/PRIVATE_KEY USER@SERVER_IP

PORTは実ポート、USERは接続先ユーザー、SERVER_IPは現在のVPSのIPを表す記号です。-iにはPC内の秘密鍵ファイルを指定し、パスに空白がある場合は全体を引用符で囲んでください。

秘密鍵の指定が不要なら、-i /path/to/PRIVATE_KEYを省きます。ただし、省略しただけでパスワード認証に限定されるわけではありません。サーバーが許可している認証方式と、PC側の設定に従って接続が進みます。

-vは診断表示を増やす指定です。接続先IP・ポート、ホスト鍵の確認、ユーザー認証のどこまで進んだかを追ってください。コマンドには鍵の中身を貼らず、診断ログを第三者へ共有する際は、ユーザー名・IP・ファイルパスなども共有先に応じて伏せましょう。

pingの応答がないことだけで、VPS全体が停止したとは判断しないでください。pingが使う通信とSSHのTCP接続では、許可されている条件が異なることがあります。

接続拒否・タイムアウトならポートとサービスを確認する

正しいIPとポートでも届かない場合は、通信を止める層とSSHの待受状態を分けて確認しましょう。確認場所は、手元のPC、VPSのパケットフィルター、VPS内のOSという順に整理できます。

さくらのVPSのパケットフィルターとOS側のファイアウォールは別の設定です。公式のパケットフィルター仕様では対象がIPv4・NIC1に限られるため、IPv6を使う環境はOS側の制限も別に確認してください。

SSHに入れないときは、コントロールパネルのコンソールからOSへログインして確認します。以下は、管理権限を持つUbuntu 24.04のVPS内で実行する、状態表示用のコマンドです。

sudo systemctl status ssh.service ssh.socket --no-pagersudo ss -ltnp

systemctlではActive:を、ssではLISTEN行のLocal Address:Portとプロセス名を照合してください。さくらの標準Ubuntu 24.04の仕様には、ssh.socketが接続を待ち受けてssh.serviceを起動する方式が示されています。サービスの稼働状態と、実際の待受をセットで見ることがポイントです。

• 対象ポートの待受がなければ、SSHの起動状態とポート設定を調べてください。
• 待受が別ポートなら接続コマンドと許可ルールを合わせ、127.0.0.1や::1だけなら待受アドレスの設定を見直します。
• 外部接続用のアドレスでSSHが待ち受けているのに届かなければ、経路と各層のフィルターが次の確認先です。

起動に失敗している場合は、systemctl status末尾のエラーと、対象時刻のsystemdジャーナルを調べましょう。Ubuntu以外ではサービス名やログの保存先が異なるため、/var/log/secureなど他OSの例をそのまま当てはめないでください。具体的な確認箇所は公式のポート通信トラブル案内にまとまっています。

設定を変更できる接続が残っている場合は、その接続を閉じる前に別の接続でログインできるか確認してください。ポート変更と複数の防御設定を一度に行わず、一つずつ結果を確かめましょう。

認証とホスト鍵の失敗を分ける

Permission deniedなら、接続の許可ではなくログインの条件を確認する段階です。ホスト鍵の警告はサーバーの識別に関わるため、ユーザー認証の失敗とは別に扱います。

ユーザーと鍵の組合せを確認する

さくらの標準Ubuntuの初期管理ユーザーはubuntuです。ただし独自OSやユーザーを変更した環境では、実際の設定に合わせてください。

• 公開鍵を登録したユーザーと、接続時のユーザー名
• その公開鍵に対応する秘密鍵のファイル
• 鍵認証・パスワード認証など、サーバーが受け付ける方式
• 鍵ファイルや登録先の所有者・権限に関するエラー

ssh -vの表示では、どの鍵を提示したか、どの認証方式を試したかを追えます。鍵の提示がなければPC側のファイル指定、提示した鍵が拒否されたならVPS側の登録先や権限が主な確認先です。

鍵の組合せは、手元のPCで次のコマンドを使い、秘密鍵から対応する公開鍵を表示して確かめられます。パスは自分の秘密鍵ファイルに置き換えてください。

ssh-keygen -y -f /path/to/PRIVATE_KEY

照合相手は、接続先ユーザーのauthorized_keysに登録された公開鍵です。管理できるコンソール等で確認し、出力された鍵の種類と鍵データを比べます。ファイルの場所を変更している環境では、その設定先を確認してください。

秘密鍵の権限エラーには、PCのOSとクライアントに合う保護設定で対処します。誰でも読み書きできるよう権限を広げる方法は避けましょう。パスワード認証を使う場合は、入力値だけでなく、そのユーザーにパスワード認証が許可されているかも確かめてください。

ホスト鍵が変わった警告は指紋を照合する

ホスト鍵は、ユーザーの秘密鍵とは別に、接続先サーバーを識別する鍵です。初回接続でも、表示された指紋を管理経路などで取得した値と照合してから接続を許可してください。

以前と鍵が違う警告が出たら、対象IPとOS再インストール等の変更履歴を確認します。続いて、信頼できるコンソールからVPS内の指紋を取得し、接続画面の値と比べましょう。次はED25519ホスト鍵を照合する場合の例です。

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

接続画面にRSAやECDSAと表示される場合は、VPS側も同じ種類のホスト公開鍵を指定してください。鍵の種類とSHA256:から始まる指紋を合わせて照合します。取得場所と比較方法は、公式のホスト鍵確認手順を参照してください。

再確認するか、必要な記録を添えて相談する

変更後は、同じ対象のIP・ポート・ユーザーで再接続し、エラーが消えた段階を確認します。認証後に対象VPSのホスト名やユーザーを確認できれば、SSHログインまでの切り分けは一区切りです。

解決しない場合は、接続日時、対象OS、クライアント、エラー全文、直前の変更、ここまで確認した結果を整理しましょう。コンソール自体が開かない場合は公式サポート、開くもののOSへログインできない場合は公式のログイン復旧案内が次の確認先です。

OS内の設定修正が難しければ、管理を担当する人へその記録を渡してください。相談時には秘密鍵・パスワード・トークンを添付せず、調査に必要な接続情報だけを共有します。

SSHが成功すれば、Dockerの導入やn8nの処理エラーの調査など、アプリ側の作業へ進める状態です。ログインできた時点の記録を残してから進めましょう。

確認手順の詳細は、さくらのVPSのSSH接続トラブル案内と接続診断の公式案内で照合できます。