VPSにSSH接続できないときの原因チェックリスト｜エラー別対処

【PR】この記事にはアフィリエイトリンク（ConoHa VPS）が含まれます。

VPSを契約して、いざターミナルから ssh を叩いたら——Connection timed out のまま固まる。Permission denied (publickey) と即座に蹴られる。昨日までつながっていたのに今日は入れない。

厄介なのは、「つながらない」という症状は同じでも、原因は5つくらいの別々の場所に散らばっていることです。まずは、いま出ているエラーメッセージから当たりを付けてください。

私自身、ConoHa VPS を3年ほど運用していますが、初期設定を締めた直後や、ファイアウォールを触ったあとに自分で自分を締め出したことが何度もあります。鍵を作り直したり、サーバーを再起動したり、思いつく順に試すと余計に迷子になる——というのも、たいてい経験済みです。

この記事では、ターミナルに出ているエラーメッセージを起点に、上から順に潰していくチェックリストの形でまとめました。最後には「どうやってもSSHが通らない＝完全に締め出された」ときの復旧手段まで書いています。ここまで用意しておけば、VPSの設定に対する不安はかなり減るはずです。

なお、動作確認は Ubuntu 24.04 LTS の実機と、26.04（resolute）の openssh-server パッケージの構成（packages.ubuntu.com のファイル一覧）で行っています（2026年8月20日時点）。バージョンによって挙動が変わる箇所は、その都度どの版の話かを明記します。

VPSにSSH接続できないときは、まず ssh -v でエラーを正確に取る

原因を当てにいく前に、手元のターミナルで何が起きているかを詳しく出させます。-v を付けるだけです。

# -v は3つまで重ねられる（-vvv が最も詳しい）
ssh -v -i ~/.ssh/id_ed25519 michi@203.0.113.10

見るべきは「どこまで進んで止まったか」です。

Connecting to 203.0.113.10 port 22. で止まる

TCPの接続すらできていません。ファイアウォールかIP/ポートの問題です（→ timed out / refused の章へ）。

Remote protocol version ... Server host key: ... まで出る

sshd とは会話できています。ここから先で落ちるなら認証の問題です（→ Permission denied の章へ）。

Offering public key: ... の直後に落ちる

鍵は送っているのにサーバーが受け付けていません。authorized_keys かパーミッションが濃厚です。

エラーの文面をそのまま読むだけで、この後に疑う場所は3か所以内に絞れます。私の経験上、「なんとなくつながらない」で作業を始めないことが、結局いちばんの近道です。

VPSにSSH接続できない原因は「5つの関門」のどこかにある

もうひとつ、頭に入れておくと調査が速くなる図があります。手元のPCからサーバーの中に入るまでに、パケットは5つの関門を通ります。エラーメッセージは「どの関門で止まったか」を教えてくれているだけです。

初心者がいちばん引っかかるのは ②と③が二重にあることです。ufw で 22 を開けたのに通らない、という相談の多くは、クラウド側のセキュリティグループが閉じたままです。逆にセキュリティグループを開けても、サーバー内の ufw が塞いでいれば通りません。両方開けて初めて通る、と覚えてください（ConoHa の公式サポートにも「セキュリティグループとは別にサーバー内でポートの開閉設定が必要」と明記されています）。

Connection timed out｜応答が返ってこない

ssh: connect to host 203.0.113.10 port 22: Connection timed out

これは「呼びかけたが誰も返事をしなかった」状態です。パケットがどこかで捨てられています。上の関門でいうと①〜③のどれかです。

手元から「そもそも22番に届くか」を確かめる

まずSSHから離れて、TCPの疎通だけを見ます。

# Windows（PowerShell）
Test-NetConnection -ComputerName 203.0.113.10 -Port 22

# macOS / Linux（Ubuntu の最小構成には nc が無いことがある。その場合は sudo apt install netcat-openbsd）
nc -vz 203.0.113.10 22

• TcpTestSucceeded : True / succeeded! → ポートは開いています。原因は認証側（→ Permission denied の章）
• 無反応のまま失敗 → ①〜③のどこかで遮られています
• 即座に refused → 届いてはいるので次章へ

原因1：クラウド側のセキュリティグループが閉じている

ConoHa VPS にはセキュリティグループ（仮想ファイアウォール）があり、サーバーに届く前の段階で通信を絞れます。ここで22番（またはあなたが変更したポート）が許可されていないと、サーバー内の設定がどれだけ正しくても届きません。

確認するのは2点だけです。

1. 対象のサーバーに、いまどのセキュリティグループが当たっているか（コントロールパネルの「サーバー」→対象サーバー→「ネットワーク情報」で確認できます） 2. そのグループに、使っているポートの受信許可があるか（通信方向＝IN、プロトコル＝TCP、ポート、接続元IP）

接続元IPを自宅の固定IPだけに絞っていて、回線のIPが変わって入れなくなる——というのも定番の事故です（私はこれで2回やりました）。心当たりがあるなら、コンソールから入って一時的に接続元IPを広げ、入れることを確認してから絞り直します。設定画面の場所と操作手順はVPS初期設定のやることリストに画像付きでまとめてあります。

💡 多くのVPSでは、名称が違うだけで同種の機能が用意されています（パケットフィルタ、ファイアウォール設定など）。コントロールパネル側にもう一段ファイアウォールがあるかもしれないという前提で確認してください。

原因2：OSのファイアウォール（ufw / firewalld）で塞がっている

サーバーに入れているうちに確認しておきたいのがここです。Ubuntu 系（ufw）:

sudo ufw status verbose

Status: active なのに 22/tcp ALLOW IN の行が無ければ、それが原因です。ufw は「SSHを許可してから有効化」するのが鉄則です。

sudo ufw allow 22/tcp      # 先に許可
sudo ufw enable            # それから有効化

⚠️ よく「ufw enable した瞬間に接続が切れる」と言われますが、実際にはすでに確立しているSSHセッションは通常そのまま生き残ります（ufw の before.rules が RELATED,ESTABLISHED を許可しているため）。マニュアルの表現も「既存のssh接続を切断する可能性がある」です。むしろ怖いのは、切れなかったので成功だと思い込み、ターミナルを閉じたり再起動したりして初めて入れなくなるパターンです。許可を入れ忘れていないか、必ず ufw status で確認してください。

AlmaLinux・Rocky Linux などRHEL系は firewalld です。

sudo firewall-cmd --list-all          # 現在の許可状況（ランタイム設定）
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload            # --permanent は reload しないと効かない
sudo firewall-cmd --list-all          # reload 後にもう一度見て、services に ssh があるか確認

--permanent を付けたのに --reload を忘れて「設定したのに反映されない」というのが firewalld のお約束です。打ちっぱなしにせず、reload の後にもう一度 --list-all を見るのが確実です。RHEL系では、このあと出てくる SELinux も絡みます。

原因3：IPアドレス・ポート・ユーザー名の間違い

拍子抜けするようですが、実際に多いです。

• サーバーを作り直してIPが変わっている（コントロールパネルで現在のIPを確認）
• ポートを22から変更したのを忘れている（ssh -p 2222 user@IP）
• IPv6 で解決されている（ドメイン名で接続していて、AAAAレコードの先が生きていない）。ssh -4 user@example.com でIPv4を強制して切り分ける
• サーバーが停止している（コントロールパネルで起動状態を確認。ここを見ずに1時間溶かすことがあります）

最後のパターンは本当にもったいないので、疎通が取れない時点で一度コントロールパネルを開く癖を付けてください。ちなみに、溶かした1時間が自分にとっていくらの損失なのかは、当サイトの適正時給・単価の逆算ツールで出せます。数字にすると、確認を先にやる気になります。

原因4：手元のネットワークが22番を塞いでいる

会社のオフィス、学校、一部の公衆Wi-Fiでは、外向きの22番が塞がれていることがあります。スマホのテザリングに切り替えて試すのがいちばん速い切り分けです。テザリングだと通るなら、原因はサーバーではなくあなたのいる場所のネットワークです。

この場合の実用的な回避策は、SSHの待ち受けポートを443など塞がれにくい番号に追加することですが、ポート変更にはUbuntuのバージョン依存の落とし穴があります（次章）。まずはコンソール接続で急場をしのぐのが安全です。

Connection refused｜即座に拒否される

ssh: connect to host 203.0.113.10 port 22: Connection refused

timed out と違い、サーバーまでは届いています。届いた先で「そのポートでは誰も待っていない」と返されている状態です。疑うのは2つだけです。

原因1：sshd が動いていない（ssh.service が inactive でも正常）

サーバー内（コンソールから入って）で状態を見ます。

sudo systemctl status ssh          # Ubuntu / Debian 系
sudo systemctl status sshd         # AlmaLinux / Rocky など RHEL 系

systemctl status ssh.socket             # active (listening) になっているか
sudo ss -tlnp | grep -E ':22|:2222'     # 実際に待ち受けているポートを確認

RHEL系（AlmaLinux・Rocky）は従来どおり sshd.service が常駐するので、inactive なら本当に停止しています。sudo systemctl start sshd で起動し、sudo journalctl -u sshd -n 50 --no-pager で理由を確認します。

原因2：待ち受けポートが違う（Ubuntu はバージョンで挙動が変わる）

sshd_config の設定ミスで起動に失敗している、あるいは自分でポートを変えたのを忘れている、のどちらかです。まずは文法チェックと、実際に待ち受けているポートを見ます。

sudo sshd -t                            # 設定ファイルの文法チェック（何も出なければOK）
sudo ss -tlnp | grep -E ':22|:2222'     # 実際に待ち受けているポート（★これが正）

ls -l /usr/lib/systemd/system-generators/sshd-socket-generator

echo 'Port 2222' | sudo tee /etc/ssh/sshd_config.d/00-port.conf
sudo sshd -t                            # 文法チェック
sudo systemctl daemon-reload            # ← 生成器を走らせる。これを忘れると反映されない
sudo systemctl restart ssh.socket
sudo ss -tlnp | grep :2222              # 反映確認（★sshd -T ではなくこちら）

sudo systemctl edit ssh.socket
# [Socket]
# ListenStream=          ← いったん空にして既定値を打ち消す
# ListenStream=2222
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -tlnp | grep :2222

もうひとつ、ソケット起動の環境で効かない設定があります。sshd_config の AddressFamily inet（IPv4のみで待ち受ける）は生成器に無視され、IPv6 でも待ち受けたままになる既知の問題があります。IPv4 に限定したいときは、ソケット側（ListenStream）で指定するか、ファイアウォール側で制御してください。「設定したつもりで効いていない」の典型例です。

sshd のログを正しく取る（-u ssh では出ない）

sshd が起動に失敗している、あるいは認証で蹴られているなら、サーバー側のログに理由が書いてあります。ただしログの取り方が新しい OpenSSH では変わっているので、ここは注意してください。

sudo journalctl -t sshd -t sshd-session -t sshd-auth -n 50 --no-pager

OpenSSH は 9.8 で接続ごとの処理が sshd-session に、10.0 で認証処理が sshd-auth に分離されました（Ubuntu 26.04 の openssh-server は 1:10.2p1 系）。つまり Failed publickey for ... のような認証失敗のログは、環境によって sshd でも sshd-session でもなく sshd-auth から出ます。-t は複数指定できるので、上のように3つまとめて指定するのが確実です。

一方、journalctl -u ssh を第一手にするのはおすすめしません。ソケットアクティベーションの環境では ssh.service が動いていないため、空振りすることがあります。ユニットで見たいときはパターン指定にします。

sudo journalctl -u 'ssh*' -n 50 --no-pager   # RHEL系は -u sshd で従来どおり

Permission denied (publickey)｜鍵で蹴られる

michi@203.0.113.10: Permission denied (publickey).

ここまで来たらネットワークもファイアウォールもクリアしているので、原因は認証だけです。私のところに来る相談でも最も多いのがこれで、しかも原因が5つに分かれています。上から順に確認するのが結局いちばん速いです。

① 鍵の指定が間違っている（Too many authentication failures が出る場合）

ssh は手元の鍵を順番に試します。~/.ssh/ にある鍵だけでなく ssh-agent に登録済みの鍵も試されるため、鍵が何本もあるとサーバー側の試行回数上限に達して切られることがあります。

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

この場合は、使う鍵を1本に固定します。

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 michi@203.0.113.10

つながったら ~/.ssh/config に書いておくと以後は ssh myvps だけで済みます。

Host myvps
    HostName 203.0.113.10
    User michi
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

② パーミッション・所有者が正しくない（経験上いちばん多い）

OpenSSH はセキュリティ上の理由でパーミッションが緩いファイルを無視します（StrictModes が既定で有効）。しかも手元のターミナルには理由が出ません。ここが私の経験上、最頻出の原因です。

サーバー側（入れているうちに、またはコンソールから確認）:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

正しい状態はこうです。

ズレていたら直します。コンソールから root で作業している場合は要注意で、~ や $USER は root 自身を指してしまいます。直したいユーザーのパスとユーザー名を必ず明示してください。

# michi ユーザーを直す場合（root / sudo で実行しても安全な書き方）
sudo chmod go-w /home/michi
sudo chmod 700 /home/michi/.ssh
sudo chmod 600 /home/michi/.ssh/authorized_keys
sudo chown -R michi:michi /home/michi/.ssh

所有者が root のままというのも定番です。sudo を付けて authorized_keys を作ると、ファイルの持ち主が root になり、本人が読めても sshd は使ってくれません（ls -l の所有者列を必ず見てください）。

なお、この失敗は手元には出ませんが、サーバー側のログには必ず出ます。

Authentication refused: bad ownership or modes for directory /home/michi/.ssh

前章の journalctl -t sshd -t sshd-session -t sshd-auth でこの行が見えたら、それが答えです。推測で chmod を撃つ前に、まずログを見るのが最短です。

手元（クライアント）側の秘密鍵にもパーミッションがあります。緩いと WARNING: UNPROTECTED PRIVATE KEY FILE! が出て鍵が使われません。

chmod 600 ~/.ssh/id_ed25519

③ authorized_keys の中身が違う

ありがちなのが次の3つです。

• 秘密鍵のほうを貼ってしまった（authorized_keys に入れるのは .pub のほう）
• コピペで改行が入って1本の鍵が2行に割れている（1つの鍵は必ず1行）
• そもそも別の鍵が入っている（手元の鍵と対になっていない）

手元の鍵とサーバーの鍵が同じものかは、フィンガープリントで照合できます。

# 手元で（公開鍵のフィンガープリント）
ssh-keygen -lf ~/.ssh/id_ed25519.pub

# サーバー側で（authorized_keys に入っている鍵のフィンガープリント）
ssh-keygen -lf ~/.ssh/authorized_keys

同じ SHA256:... が並んでいれば鍵は合っています。並んでいなければ、それが答えです。なお authorized_keys の行頭に no-port-forwarding,command="..." などのオプションが付いている場合（クラウドの初期構築で root 用に作られる鍵によくあります）は、この方法で読めないことがあります。そのときは行末の鍵本体だけを別ファイルに切り出して確認してください。

さらに、サーバー側のログには「どの鍵で失敗したか」も残ります。

sudo journalctl -t sshd -t sshd-session -t sshd-auth -n 50 --no-pager | grep -i 'publickey'

Failed publickey for michi from 198.51.100.5 port 51234 ssh2: ED25519 SHA256:xxxxx のように出るので、この SHA256: を手元の ssh-keygen -lf の値と比べれば、「鍵が届いていないのか」「届いているが登録されていないのか」が一発で分かります。ここまで見れば推測は不要です。

④ sshd の設定が意図どおりに効いていない（ドロップインの読み込み順）

初期設定で PasswordAuthentication no（パスワード認証を止める）にした直後から入れなくなった、というパターンです。鍵の登録が終わる前にパスワード認証を閉じると、当然どこからも入れません。

そして、ここにこのカテゴリで何度も書いている落とし穴があります。現行の Ubuntu は /etc/ssh/sshd_config.d/ 配下のドロップイン設定を辞書順（lexical order）に読み、同じ項目は先に読んだ値が勝ちます。

• 00-hardening.conf → 50-cloud-init.conf より先に読まれるので勝つ（設定が効く）
• 99-hardening.conf → 50-cloud-init.conf に先を越されて負ける（設定が無効化される）

つまり 99- を付けていると、「パスワード認証を止めたつもりが止まっていない」という逆方向の事故が起きます。締め出されはしませんが、セキュリティ的にはもっと危険です。

💡 「数字の小さい順」ではなく辞書順なので、100-foo.conf は 50-bar.conf より前に来ます（1 < 5）。桁数を混ぜると事故のもとなので、2桁で揃える運用にしてください。また sshd_config 本体の Include 行より前に書いた設定はドロップインより強くなります（Ubuntu 既定は Include が先頭なので通常は問題ありません）。

反映の確認は、鍵でログインできたかどうかではなく、sshd が最終的に採用した値を見ます。

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|pubkeyauthentication|allowusers'

• pubkeyauthentication yes になっているか（no だと公開鍵認証そのものが無効）
• allowusers が設定されていて、そこに自分のユーザー名が入っていないと、正しい鍵でも蹴られます
• passwordauthentication / permitrootlogin が意図どおりか

sudo sshd -T はドロップインを含めた最終結果を表示します。ただし万能ではありません。

Match ブロックは評価されない

-C で接続条件を与えないと Match User ... の中身は反映されません。Match を使っているなら sudo sshd -T -C user=michi,addr=203.0.113.10,laddr=203.0.113.10,lport=22 のように条件付きで実行します。

port の値は実際の待ち受けではない

ソケットアクティベーションの環境では、sshd -T が返す port は sshd_config 側の値です。実待ち受けは sudo ss -tlnp で確認してください（前章参照）。

⑤ SELinux が authorized_keys を読ませていない（RHEL系）

AlmaLinux・Rocky Linux などRHEL系で、/tmp などからコピーして .ssh を作ったときに起きます。パーミッションも所有者も正しいのに Permission denied (publickey) が出る場合は、SELinux のファイルコンテキストを疑います。

ls -Zd /home/michi/.ssh              # ディレクトリ自身のコンテキスト（ssh_home_t になっているか）
sudo restorecon -Rv /home/michi/.ssh # 既定のコンテキストに戻す（root権限が必要）

ls -Z ~/.ssh だと中身のファイル一覧になるので、ディレクトリ自身を見たいときは -d を付けます。Ubuntu では基本的に発生しません。RHEL系特有の詰まりどころなので、AlmaLinux を使っている方は先にここを見ると早いことがあります。

番外：古いDSA鍵・極端に短いRSA鍵は使えない

「何年も前に作った鍵」が使えないケースもあります。ただし、よく誤解されているので正確に書きます。

• RSA鍵そのものは今も使えます。 OpenSSH 8.8 で既定無効になったのは ssh-rsa（SHA-1署名）という署名方式で、鍵自体ではありません。OpenSSH は 7.2 以降、既存のRSA鍵でも自動的に SHA-2 系の署名（rsa-sha2-256/512）を使います。鍵を作り直す必要は基本的にありません。
• 本当に使えないのは DSA（ssh-dss）鍵です。 OpenSSH 10.0 で DSA のサポートが完全に削除されました。Ubuntu 26.04 世代のサーバーには、古いDSA鍵では接続できません。
• 極端に短いRSA鍵（既定では 1024bit 未満）も RequiredRSASize によって拒否されます。

自分の鍵の種類とビット数は、これで確認できます。

ssh-keygen -lf ~/.ssh/id_rsa.pub
# 3072 SHA256:xxxxx... michi@pc (RSA)   ← 末尾の種類と先頭のビット数を見る

末尾が (DSA) なら、その鍵は諦めて ssh-keygen -t ed25519 で新しく作り直し、コンソールから authorized_keys を差し替えるのが早道です。(RSA) でビット数が 2048 以上あるなら、原因は鍵の種類ではありません。①〜⑤に戻ってください。

Connection reset by peer｜fail2ban などに遮断されていないか

kex_exchange_identification: read: Connection reset by peer

昨日までつながっていたのに突然これが出るようになったら、接続元のIPが何かに遮断された可能性があります。原因の候補は fail2ban だけではありません。

• fail2ban に自分のIPがBANされた（鍵を間違えて何度も試した直後に起きがち。ただし遮断方法が REJECT なら refused、DROP なら timed out になることもあります）
• MaxStartups を超えた（認証前の同時接続が多いと、sshd が新規接続を落とします）
• /etc/hosts.deny や DenyHosts などで拒否されている
• 経路上の機器（会社のファイアウォール等）がRSTを返している

fail2ban を入れているなら、まずここを確認します（入れていなければ command not found になります）。

sudo fail2ban-client status sshd

Banned IP list: に自分のIPが載っていれば当たりです。解除はこれです。

sudo fail2ban-client set sshd unbanip 198.51.100.5

自宅のIPを恒久的に除外したい場合は jail.local の ignoreip に追記する方法もありますが、回線のIPは変わることがあるので、除外に頼りすぎない設計にしておいてください。fail2ban が入っていない、あるいはBANされていないのにこのエラーが続く場合は、サーバー側のログ（journalctl -t sshd -t sshd-session -t sshd-auth）に error: beginning MaxStartups throttling などが出ていないかを見ます。

Host key verification failed｜サーバーを作り直したあとに出る

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

これは接続の失敗というより警告です。手元の ~/.ssh/known_hosts に記録したサーバーの指紋と、いま応答したサーバーの指紋が違う、と言っています。

サーバーを作り直した／OSを再インストールした心当たりがあるなら、古い記録を消すだけです。

ssh-keygen -R 203.0.113.10

# ドメイン名でも接続していたなら、そちらも消す（IPとホスト名は別のエントリ）
ssh-keygen -R example.com

# ポートを変更している場合は角括弧付きで指定する
ssh-keygen -R "[203.0.113.10]:2222"

Windows の場合、known_hosts の場所は C:\Users\<ユーザー名>\.ssh\known_hosts です。ssh-keygen -R は PowerShell からもそのまま使えます。

⚠️ 心当たりが無いのにこの警告が出た場合は、消す前に立ち止まってください。 中間者攻撃や、IPが別の人に払い出された可能性もあります。コントロールパネルでサーバーのホスト鍵の指紋を確認できるなら照合し、分からなければ接続先IPが本当に自分のサーバーかを確認してから対応します。警告を反射的に消す癖は付けないほうが安全です。

Windows から接続している場合のつまずき

Windows は環境が分かれるので、詰まる場所も少し違います。

Tera Term / PuTTY の鍵形式

PuTTY 形式（.ppk）は OpenSSH の ssh コマンドではそのまま使えません。PuTTYgen で OpenSSH 形式にエクスポートするか、逆に OpenSSH の鍵を PuTTY 用に変換します。サーバーの authorized_keys に入れるのは、どの場合も「公開鍵の1行」です。

秘密鍵のパーミッション

ファイルをコピーしてくると権限が継承され、UNPROTECTED PRIVATE KEY FILE で弾かれます。下の icacls で自分だけに絞ります。

改行コード

メモ帳などで公開鍵を編集すると CRLF が混入し、authorized_keys が壊れることがあります。鍵の内容はエディタで加工せず、ssh-copy-id かクリップボード経由で1行のまま貼るのが安全です。

WSL 側の鍵

Windows 側のフォルダ（/mnt/c/...）に置いた鍵は WSL から見ると権限が 777 相当になり、同じ警告で弾かれます。鍵は WSL のホーム（~/.ssh/）にコピーして chmod 600 してください。

OpenSSHクライアントの場所

Windows 10/11 には標準で ssh コマンドが入っています（ssh -V で確認）。PowerShell からそのまま使えるので、まずはこれで -v を付けて試すのが切り分けとしては最短です。

秘密鍵の権限を直すコマンドはこれです。別のPCやアカウントからコピーしてきた鍵は「所有者」も別アカウントのままで、icacls だけでは直りません。先に所有者を自分にします。

takeown /f .\id_ed25519                                        # 所有者を自分にする
icacls .\id_ed25519 /inheritance:r /grant:r "$($env:USERNAME):(R)"

ドメイン参加のPCでは、ユーザー名だけだと権限付与に失敗することがあります。その場合は "$env:USERDOMAIN\$env:USERNAME" のようにドメイン名込みで指定してください。

あわせて読みたい

VPS初期設定のやることリスト｜Ubuntuで最初にやる7つ【2026年版】 VPS 初期設定でまず何をやるかをリスト化。ConoHa VPS＋Ubuntu前提で、更新・作業ユーザー・SSH鍵認証・ufw・自動更新までの全体像を要点で解説します。環境別の通し手順への進み方もわかる2026年版のハブ記事です。

どうやってもVPSにSSH接続できないとき（締め出しからの復旧）

ここまで試してもSSHが通らない、あるいは設定を変えた後にどこからも入れなくなった——このとき残っている手段が、コントロールパネルのコンソールです。SSHを一切使わず、ブラウザからサーバーの画面に直接ログインできます。物理サーバーにディスプレイとキーボードを挿すのと同じ扱いなので、ネットワーク設定を壊していても入れることが多く、ほとんどのケースは自力で戻せます。

ConoHa VPS で SSH 接続できないときの確認順

ConoHa VPS を使っている場合の、実際の確認順はこうなります。

1. コントロールパネルでサーバーが起動しているかを見る（「サーバー」→対象サーバー） 2. コンソールを開く（メニューから「サーバー」を選び、サーバー一覧から対象のサーバー名をクリック、サーバー詳細ページで「コンソール」をクリックすると別ウィンドウで起動します） 3. コンソールでログインして、sudo ss -tlnp | grep -E ':22|:2222'（sshd が待っているか）と sudo ufw status verbose（OS側のFW）を確認 4. サーバー内が正常なら、セキュリティグループ（「ネットワーク情報」）で該当ポートの受信許可と接続元IPを確認 5. 直したら、コンソールを開いたまま別のターミナルからSSHで再接続して成功を確認

私自身、ufw の設定順を間違えて自分を締め出したときも、sshd_config の書き間違いで sshd が起動しなくなったときも、最終的にはここから入り直して直しました。「コンソールから戻せる」と分かっているかどうかで、初期設定を試すときの心理的な負担がまるで違います。VPSを初めて触る人ほど、この機能に慣れているかどうかは効いてきます。

【PR】以下は ConoHa VPS の広告リンクです。機能・料金の詳細は公式サイトでご確認ください。

なお、コンソール機能や仮想ファイアウォールの呼び方・操作は会社ごとに違います。各社の機能や料金の違いはVPS比較2026｜個人向けおすすめ4社に横並びでまとめてあるので、これから選ぶ人はそちらを参照してください。

二度と締め出されないための3つの習慣

復旧できたら、同じことを繰り返さない工夫をしておきます。難しいことは何もなく、順番の問題です。

習慣1：作業中のSSHセッションは絶対に閉じない

SSHまわりの設定を変えるときの鉄則です。いま入っている接続はそのままにして、別のターミナルをもう1枚開いて新規接続を試します。新しい接続が成功したことを確認してから、元のセッションを閉じます。

前述のとおり、ufw の有効化やsshdの再起動をしてもいまの接続はしばらく生き残ります。だからこそ「切れなかった＝成功」と誤解しやすく、締め出し事故のほとんどは変更して満足してセッションを閉じたことで起きています。確認するのは「いまの窓が生きているか」ではなく「新しい窓が開けるか」です。

習慣2：許可してから有効化する（ufw の順番）

sudo ufw enable を先に打つと、新規の接続がその時点で遮断されます。allow が先、enable が後。ポートを変更する場合も同じで、新しいポートを ufw とセキュリティグループの両方で許可してから sshd 側を変更します。片方だけ開けて切り替えると、そこで終わりです。

習慣3：変更前に確認コマンドをセットで用意する

「設定した」と「効いている」は別物です。SSH まわりでは、この3つを必ずセットで実行してください。

sudo sshd -t                       # ① 文法エラーが無いか（再起動前に必ず）
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|pubkeyauthentication'
                                   # ② sshd が採用した設定値（Match ブロックは -C が必要）
sudo ss -tlnp | grep -E ':22|:2222'
                                   # ③ 実際に待ち受けているポート（ポートはこちらが正）

sshd -t を打たずに再起動して、文法エラーで sshd が上がらず締め出される——これも定番です。再起動の前に文法チェック、再起動の後に反映確認。この3行を癖にするだけで、SSHの事故はかなり減ります。

次に読む記事

この記事は「エラーが出ている今」を解決するトラブルシュート専用です。前後の内容は別記事が担当しています。

• 最初にやることの全体像（作業用ユーザー・SSH鍵認証・ufw の7ステップ） → VPS初期設定のやることリスト
• Ubuntu 26.04 のコマンド通し手順 → Ubuntu 26.04 LTSのインストールと初期設定
• OSをどれにするか迷っている → VPSのOSはどれを選ぶ？
• そもそもVPSが自分に必要か迷っている → VPSとレンタルサーバーの違いを図解で比較
• どの会社で契約するか（料金・コンソール機能の比較） → VPS比較2026｜個人向けおすすめ4社

サーバーが復旧したら本業に戻りましょう。ちなみにVPSの利用料は事業の経費として扱えます（勘定科目の扱いはサーバー代・レンタルサーバー代の勘定科目と経費計上にまとめています）。経費を増やしたときに手取りがどう変わるかは、当サイトの手取り・税金シミュレーターで試算できます。

まとめ

SSHのトラブルは、原因が分かってしまえば直すのは数分です。時間を溶かすのは当てずっぽうで触る時間のほうです。エラーメッセージを起点に、上から順に潰してください。

そして、コンソールで入り直せる環境なら（ConoHa VPS を含め主要各社が備えています）、設定を壊しても多くの場合はそこから戻せます。むしろ壊して直した回数だけ、サーバーは怖くなくなります。私も最初の数か月は締め出しの常連でした。

【PR】以下は ConoHa VPS の広告リンクです。

パスワード認証を止めたあと鍵でも入れなくなりました。もう手遅れですか？

コントロールパネルのコンソールから入れるので手遅れではありません。コンソールでログインし、sudo sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication' で現在の設定を確認したうえで、/etc/ssh/sshd_config.d/ のドロップイン設定を修正します。鍵の登録が終わっていないなら、いったんパスワード認証を戻して鍵を登録し直し、鍵でログインできることを別のターミナルで確認してから再度閉じてください。設定変更の前に sudo sshd -t で文法チェックをするのも忘れずに。

ufw を有効にしたら接続が切れました。どうすればいいですか？

sudo ufw enable をSSHの許可前に実行すると、新規の接続が遮断されます（すでに確立している接続はしばらく残ることが多いので、気付くのが遅れがちです）。コンソールからログインし、sudo ufw status verbose で状況を確認して sudo ufw allow 22/tcp（ポートを変更しているならその番号）を追加してください。次回からは許可してから有効化の順番にします。ConoHa VPS などクラウド側のセキュリティグループがある場合は、そちらでも同じポートを許可する必要があります。

Permission denied (publickey) で、鍵は合っているはずなのに入れません。

私の経験上、高い確率でパーミッションか所有者です。サーバー側で ls -ld ~ ~/.ssh ~/.ssh/authorized_keys を実行し、~/.ssh が 700、authorized_keys が 600、所有者が本人（rootではない）、ホームディレクトリが他人から書き込み可能になっていないことを確認してください。原因はサーバー側のログに Authentication refused: bad ownership or modes ... として残るので、sudo journalctl -t sshd -t sshd-session -t sshd-auth -n 50 --no-pager を見るのが最短です。RHEL系（AlmaLinux など）では SELinux のコンテキストが原因のこともあり、sudo restorecon -Rv /home/ユーザー名/.ssh で直る場合があります。

秘密鍵のパスフレーズを忘れました。復旧できますか？

パスフレーズを解析して取り戻す方法はありません（そのための暗号化です）。新しい鍵を ssh-keygen -t ed25519 で作り直し、コントロールパネルのコンソールからサーバーにログインして、authorized_keys に新しい公開鍵を登録し直してください。登録後はコンソールを閉じる前に、別のターミナルから新しい鍵でログインできることを確認します。他のサーバーにも同じ鍵を使っていた場合は、そちらの authorized_keys も差し替えが必要です。

—

出典

• ConoHa VPS サポート「コンソールを使う」（コンソールの開き方・コピー＆ペースト不可・テキスト送信）：https://support.conoha.jp/v/console/ （2026年8月20日確認）
• ConoHa VPS サポート「セキュリティグループ」（通信方向・プロトコル・ポート・接続元IPの指定／サーバー内の開閉設定も別途必要）：https://support.conoha.jp/v/v3-security-securitygroup/ （2026年8月20日確認）
• ConoHa VPS サポート「SSH接続でVPSにログインする」：https://support.conoha.jp/v/vps_ssh/ （2026年8月20日確認）
• Ubuntu Discourse「sshd now uses socket-based activation (Ubuntu 22.10 and later)」（ソケットアクティベーションの導入と、24.04 以降は sshd_config の Port を宣言すれば足りる旨）：https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189 （2026年8月20日確認）
• Ubuntu パッケージ一覧 openssh-server（resolute＝26.04。sshd-socket-generator の同梱を確認）：https://packages.ubuntu.com/resolute/amd64/openssh-server/filelist （2026年8月20日確認）
• Ubuntu マニュアル sshd_config(5)（resolute。ドロップインの辞書順・先勝ち／StrictModes／RequiredRSASize）：https://manpages.ubuntu.com/manpages/resolute/en/man5/sshd_config.5.html （2026年8月20日確認）
• Ubuntu マニュアル sshd(8)（resolute。-t / -T と -C による Match の評価）：https://manpages.ubuntu.com/manpages/resolute/en/man8/sshd.8.html （2026年8月20日確認）
• Ubuntu マニュアル ufw(8)（resolute。有効化が既存のssh接続を切断する「可能性がある」旨）：https://manpages.ubuntu.com/manpages/resolute/en/man8/ufw.8.html （2026年8月20日確認）
• OpenSSH 8.8 リリースノート（SHA-1 の ssh-rsa 署名を既定無効化。ただし既存のRSA鍵の置き換えは不要と明記）：https://www.openssh.com/txt/release-8.8 （2026年8月20日確認）
• OpenSSH 9.8 リリースノート（sshd-session への分離とログのタグ変更）：https://www.openssh.com/txt/release-9.8 （2026年8月20日確認）
• OpenSSH 10.0 リリースノート（DSA の完全削除／認証処理の sshd-auth 分離とログの出どころ）：https://www.openssh.com/txt/release-10.0 （2026年8月20日確認）
• fail2ban 公式ドキュメント（fail2ban-client の操作）：https://fail2ban.readthedocs.io/ （2026年8月20日確認）

※コントロールパネルの画面構成・機能名は変更されることがあります。操作手順は各社公式のサポートページで最新をご確認ください。ソフトウェアの挙動はバージョンによって変わるため、コマンドの結果は必ずご自身の環境で確認してください。

更新日：2026年8月20日