PR

VPSのセキュリティを段階的に高めていく｜apt upgradeでSSH接続不能になったときの原因と復旧手順

apt upgrade後にSSHポート設定がリセットされ接続できなくなったVPSを復旧するイメージイラスト（Port 22から50022へ再設定） VPS・RentalServer
この記事は約12分で読めます。
記事内に広告が含まれています。
スポンサーリンク

この記事は、「VPSのセキュリティを段階的に高めていく」シリーズの続きとなる記事です。

【VPSセキュリティ実践まとめ】Ubuntu Serverを段階的に安全にする設定ガイド
個人運用のVPSを安全に保つためのセキュリティ設定のまとめページです。Ubuntu Serverを対象に、ファイアウォール(ufw)からSSHの安全対策、fail2banによる自動防御まで、初心者が無理なく段階的に進められる実践手順を解説します。
lifework-blog.com
2026/03/08

前回の記事では、SSHの待受ポートをデフォルトの22番からカスタムポートへ変更し、無差別スキャン攻撃を大幅に減らす設定を行いました。

ところが、しばらく運用を続けていたある日、突然ターミナルソフトからVPSへの接続ができなくなりました。

原因は、sudo apt upgrade によるパッケージ更新でした。openssh のアップデートが走り、変更していたSSHポートの設定がリセットされたのです。

この記事では、以下の内容を解説します。

  • 接続不能になったときに最初に確認すべきこと
  • ターミナルが使えない状況での緊急復旧手順（ConoHaコンソール編）
  • なぜ apt upgrade でSSHポート設定がリセットされるのか
  • 同じトラブルを二度と起こさないための確認習慣

前提となる環境
本記事でのトラブルシューティングは、以下の環境を前提としています。

  • OS: Ubuntu 24.04 LTS

※Ubuntu 22.04 LTS以降では、SSHの待ち受け管理に従来の sshd.service ではなく ssh.socket がデフォルトで使用されるようになっています。そのため、本記事の復旧手順は特にこれらの新しいバージョンで有効です。

症状と最初のエラー内容

ターミナルソフト（RLogin）からVPSへの接続を試みたところ、以下のエラーが表示されました。

Server Entry 'example-vps'
Connection 'xxx.xxx.xxx.xxx:50022'
WinSock Have Error #10061

対象のコンピューターによって拒否されたため、接続できませんでした。

接続が切れました。再接続しますか？

          はい(Y)    いいえ(N)

エラーコード #10061 は「接続拒否（Connection Refused）」を意味します。

タイムアウトエラー（#10060）とは異なり、サーバーに通信は届いているが、指定したポートで接続を受け付けていない状態です。

原因の特定：段階的な切り分け

接続できない原因としては、以下の可能性が考えられます。

  1. Fail2ban に自分のIPがBANされた
  2. ssh.socket が停止している
  3. ufw のルールが変わっている
  4. ConoHa のセキュリティグループの問題
  5. SSHサービス自体がカスタムポートで待ち受けていない

まずWindowsのPowerShellから到達確認

自分のPCからサーバーへの通信が届いているかどうかを確認します。

Test-NetConnection -ComputerName サーバーのIPアドレス -Port 50022
PS C:\windows\system32> Test-NetConnection -ComputerName xxx.xxx.xxx.xxx -Port 50022
警告: TCP connect to (xxx.xxx.xxx.xxx : 50022) failed
警告: Ping to xxx.xxx.xxx.xxx failed with status: TimedOut

ComputerName     : xxx.xxx.xxx.xxx
RemoteAddress    : xxx.xxx.xxx.xxx
RemotePort       : 50022
InterfaceAlias   : イーサネット
SourceAddress    : 192.168.xx.xx
PingSucceeded    : False
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False

結果は TcpTestSucceeded: False でした。

これはサーバーへパケットが到達すらしていないことを意味します。つまりOS側の問題ではなく、ネットワーク経路のどこかでブロックされているか、サーバー側でポートが開いていないかのどちらかです。

ConoHaコンソールで内部状態を確認

ターミナルソフトが使えない場合、VPS事業者のコントロールパネルから「コンソール接続（VNC接続）」でサーバーに直接ログインできます。SSH が使えなくても、コンソールからは操作が可能です。

ConoHaのコンソールから以下のコマンドで Fail2ban・ufw・ssh.socket の状態を確認しました。

sudo fail2ban-client status sshd   # 自分のIPがBANされていないか確認
sudo systemctl status ssh.socket   # SSH socketが動作しているか確認
sudo ufw status                    # ファイアウォールルールが変わっていないか確認

それぞれ正常な状態であることを確認できましたが、まだ接続できません。

続いて、実際に50022番ポートが待ち受け状態になっているかを確認します。

sudo ss -tlnp
username@example-server:~$ sudo ss -tlnp
State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
LISTEN  0       80      127.0.0.1:3306        0.0.0.0:*      users:(("mariadbd",...))
LISTEN  0       4096    127.0.0.53%lo:53      0.0.0.0:*      users:(("systemd-resolve",...))
LISTEN  0       511     0.0.0.0:80            0.0.0.0:*      users:(("nginx",...))
LISTEN  0       100     0.0.0.0:25            0.0.0.0:*      users:(("master",...))
LISTEN  0       4096    0.0.0.0:22            0.0.0.0:*      users:(("systemd",...))
LISTEN  0       511     0.0.0.0:443           0.0.0.0:*      users:(("nginx",...))
LISTEN  0       100     [::]:25               [::]:*         users:(("master",...))
LISTEN  0       4096    [::]:22               [::]:*         users:(("systemd",...))

これが原因でした。

0.0.0.0:50022 のエントリが存在せず、代わりに 0.0.0.0:22 が表示されています。

SSHの待受ポートが、変更していた50022番から、デフォルトの22番に戻ってしまっていたのです。

sshd_configの内容を確認

念のため、設定ファイルの内容も確認します。

sudo grep "Port" /etc/ssh/sshd_config

結果には Port 50022 の記述がありませんでした。設定ファイルからカスタムポートの記述が消えていたことが確認できました。

なぜ設定がリセットされたのか

LogWatchのデイリーレポートを確認すると、前日の dpkg status changes セクションに以下の記録がありました。

openssh-server: 9.6p1-3ubuntu13.14 → 9.6p1-3ubuntu13.15
openssh-client: 同上
openssh-sftp-server: 同上

sudo apt upgrade の実行中に、openssh-server パッケージの更新が走っていたのです。

Ubuntuの apt upgrade でパッケージが更新される際、手動で変更を加えた設定ファイル（今回であれば sshd_config）が見つかると、通常はターミナル上に以下のような確認プロンプトが表示されます。

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
    ...

ここで気付かずに「Y（パッケージ提供者の新しいバージョンをインストールし、既存設定を上書きする）」を選択してエンターを押してしまったり、あるいは自動セキュリティ更新（unattended-upgrades）が背後で実行されたりすると、カスタマイズした設定が初期化されてしまいます。（現在の設定を残す場合は「N」を選択するのが正解です）。

今回は openssh-server のアップデートに伴い、この上書きが発生したため、sshd_config の Port 50022 の記述が消え、デフォルトの22番に戻った状態になっていました。

復旧手順：ConoHaコンソールからの緊急対処

ターミナルソフトが使えない状況での復旧作業は、VPS事業者のコンソール機能を使います。

ConoHaのコンソール画面は、通常のターミナルソフトと比べてキーボード入力が不安定なことがあります。私の環境ではクリップボードからの貼り付けも仮想キーボードも使えなかったため、テキスト送信機能を使いながら、短いコマンドを1行ずつ入力して対処しました。

注意 コンソール操作はターミナルソフトより不便です。あらかじめ実行するコマンドを手元のメモ帳等に準備してから作業すると、入力ミスを減らせます。

手順1：sshd_configにPort 50022を追記する

sudo sed -i '$a Port 50022' /etc/ssh/sshd_config

sed コマンドでファイルの末尾に Port 50022 を追記します。nano などのエディタを使わずに1行で完結するため、コンソール環境での作業に適しています。

手順2：systemdの設定を再読み込みする

sudo systemctl daemon-reload

手順3：ssh.socketを再起動する

sudo systemctl restart ssh.socket

手順4：50022番ポートが開いたか確認する

sudo ss -tlnp | grep 50022
username@example-server:~$ sudo sed -i '$a Port 50022' /etc/ssh/sshd_config
username@example-server:~$ sudo systemctl daemon-reload
username@example-server:~$ sudo systemctl restart ssh.socket
username@example-server:~$ sudo ss -tlnp|grep 50022
LISTEN  0  4096  0.0.0.0:50022  0.0.0.0:*  users:(("systemd",...))
LISTEN  0  4096     [::]:50022     [::]:*  users:(("systemd",...))
username@example-server:~$

0.0.0.0:50022 と [::]:50022 が表示されれば、ポートが正常に開いています。

この後、ターミナルソフトから50022番ポートへの接続を試みると、無事にログインできることが確認できました。

復旧後の確認：22番ポートの状態チェック

接続が回復した後、念のため22番ポートが意図せず外部に開放されていないかを確認します。

22番ポートが待ち受け状態になっていないか確認

sudo ss -tlnp | grep :22

何も表示されなければ、22番は閉じています。

sshd_configにPort 22の記述が残っていないか確認

sudo grep "Port" /etc/ssh/sshd_config

以下のような出力であれば正常な状態です。

#Port 22        ← コメントアウトされている
Port 50022      ← カスタムポートのみ

ufwで22番が許可されていないか確認

sudo ufw status | grep 22

50022/tcp のみが表示され、22/tcp の ALLOW IN がなければ安全です。

今後の再発防止：apt upgrade後の確認を習慣にする

今回のトラブルを踏まえ、sudo apt upgrade を実行した後は以下の確認を習慣にしています。

アップデート後の確認コマンド（1行）

sudo grep "Port" /etc/ssh/sshd_config

Port 50022 が表示されれば安全です。表示されない場合は、接続を切る前に復旧手順を実施してください。

特に、アップデートの出力に以下のような表示が出た場合は要注意のサインです。

Setting up openssh-server ...

openssh 関連パッケージが更新されたことを示します。この表示を見たら、SSH接続を維持したまま必ずポートの確認を行ってください。

また、設定ファイルのバックアップを手元に保持しておくことも有効です。

sudo cp /etc/ssh/sshd_config ~/sshd_config.bak

バックアップがあれば、設定ファイルが初期化されても内容をすぐに確認できます。

なお、System restart required の表示が出た場合は再起動が必要なパッケージが更新されています。再起動前に必ずポートの状態を確認し、再起動後も接続できることを確認してから作業を終えるようにしてください。

まとめ

今回のトラブルの流れを振り返ります。

  1. sudo apt upgrade で openssh-server が更新された
  2. sshd_config の Port 50022 の記述がリセットされた
  3. ssh.socket が22番ポートでの待ち受けに戻った
  4. ターミナルソフトからの接続が不能になった
  5. ConoHaのコンソールから sshd_config に1行追記して復旧した

セキュリティ設定を丁寧に行っていても、日常的なメンテナンス作業（パッケージ更新）が原因でその設定が無効になることがあります。

今回、原因の特定に役立ったのが LogWatch のデイリーレポートでした。前日の dpkg status changes に openssh-server の更新が記録されていたため、「アップデートが原因では」と仮説を立てることができました。ログを日常的に読む習慣が、トラブルシューティングのスピードを上げてくれると実感しています。

設定を入れたら終わりではなく、更新のたびに設定が生きているかを確認するという運用の習慣が、安定したサーバー管理には欠かせないと改めて実感しました。

【VPSセキュリティ実践まとめ】Ubuntu Serverを段階的に安全にする設定ガイド
個人運用のVPSを安全に保つためのセキュリティ設定のまとめページです。Ubuntu Serverを対象に、ファイアウォール(ufw)からSSHの安全対策、fail2banによる自動防御まで、初心者が無理なく段階的に進められる実践手順を解説します。
lifework-blog.com
2026/03/08
スポンサーリンク

コメント

タイトルとURLをコピーしました