😱サーバのOpenSSHをアップデートしたらconnection refused!

最初に結論

サーバのOpenSSHをopenssh 1:9.6p1-3ubuntu13.13へアップデートしたことでそのサーバにSSHで接続できなくなった(connection refused)なら、サーバのsshd関連の設定をいじって¹IPv4とIPv6の両方で接続できるようにするんだ！(…IPv4だけでもいいけど)

ことの起こった環境

• OSはUbuntu 24.04(Noble Numbat)
• SSHdはsystemdによるssh.socket(ソケット起動; socket activation)
• SSHdのポートは22以外で複数のポートを設定(※今回の問題は複数のポートでなくても起こり得る)

具体的な状況

SSHdのポートは22ではなく、2222と22222だったとしよう(仮)。そのためにsshd_configの追加設定として/etc/ssh/sshd_config.d/yockow.confというファイルを作成し、次のような中身だったとする:

# /etc/ssh/sshd_config.d/yockow.conf

ListenAddress ::
Port 2222
Port 22222

PubkeyAuthentication yes
PasswordAuthentication no

そして、systemdによるssh.socketを利用していることも忘れてはいけない。
/etc/systemd/system/ssh.socket.d/yockow.confというファイルも存在していて、次のような中身だったとしよう:

# /etc/systemd/system/ssh.socket.d/yockow.conf

[Socket]
ListenStream=
ListenStream=2222
ListenStream=22222

このような環境でsudo systemctl status ssh.socketとすれば、次のような結果となるはず:

● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; enabled; preset: enabled)
    Drop-In: /run/systemd/generator/ssh.socket.d
             └─addresses.conf
             /etc/systemd/system/ssh.socket.d
             └─yockow.conf
     Active: active (running) since Tue 2025-07-29 12:34:56 JST; 59min ago
   Triggers: ● ssh.service
     Listen: [::]:2222 (Stream)
             [::]:22222 (Stream)
      Tasks: 0 (limit: 4604)
     Memory: 24.0K (peak: 280.0K)
        CPU: 5ms
     CGroup: /system.slice/ssh.socket

Jul 29 12:34:56 example.com systemd[1]: Listening on ssh.socket - OpenBSD Secure Shell server socket.

これまでは、この設定でなんの問題もなくSSH接続できていたのに…！
いつもの調子で何も考えず鼻をほじりながらsudo apt upgradeなんてしたばっかりに…！
openssh 1:9.6p1-3ubuntu13.13になった途端、SSH接続ができなくなってしまった…！

なぜ接続できなくなったか？

openssh 1:9.6p1-3ubuntu13.13のChangelogを読むと、そこにはこんなことが書かれていました:

Explicitly listen on IPv4 by default, with socket-activated sshd

(YOCKOW拙訳) ソケット起動sshdのときはデフォルトで明示的にIPv4をリッスンするぜ

なんか去年報告されたバグを直すためにそうしたらしいけど、うちのSSHが繋がらなくなったんですけど！
…いや、どうやら、うちのsshdの設定が悪かったようだ。

どういうことかというと、上のssh.socketのステータス表示を見てもらうと分かるけど、systemdは[::]:2222と[::]:22222しかlistenしていない。[::]というのはIPv6のアドレスを受け入れるということ。つまり、これまでIPv4/IPv6の両方で接続できていたことがおかしかったのだ。たぶん。²
今回のバグ修正によってsshdが明示的にIPv4をlistenするという動作になって、ssh.socketはIPv6しか受け入れないけど、sshdはIPv4しか受け入れないという矛盾が生じてしまい、結果としてconnection refusedなんて弾かれるようになってしまったよう。たぶん。

では、どうすれば？

要するにssh.socketとsshdの設定を合わせればいいのだ。どちらもIPv4だけ、もしくはIPv6だけを受け入れるとするのもいいけど、当方の事情からIPv4とIPv6の両方を受け入れる設定とした。ここでは、全てのアドレスを受け入れる設定になっているけど、不審なIPアドレスは前段のfirewallで防ぐことになっている(ということで…)。

まずはsshd_configの設定:

# /etc/ssh/sshd_config.d/yockow.conf

AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::
Port 2222
Port 22222

PubkeyAuthentication yes
PasswordAuthentication no

そして、systemd(ssh.socket)の設定:

# /etc/systemd/system/ssh.socket.d/yockow.conf

[Socket]
ListenStream=
ListenStream=0.0.0.0:2222
ListenStream=0.0.0.0:22222
ListenStream=[::]:2222
ListenStream=[::]:22222

2つともファイルを編集したらssh.socketを再起動するぞ！

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

そしてsudo systemctl status ssh.socketを実行して次のようにIPv4もIPv6もlistenしていたら成功だ！

● ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; enabled; preset: enabled)
    Drop-In: /run/systemd/generator/ssh.socket.d
             └─addresses.conf
             /etc/systemd/system/ssh.socket.d
             └─yockow.conf
     Active: active (running) since Tue 2025-07-29 22:33:44 JST; 2s ago
   Triggers: ● ssh.service
     Listen: 0.0.0.0:2222 (Stream)
             0.0.0.0:22222 (Stream)
             [::]:2222 (Stream)
             [::]:22222 (Stream)
      Tasks: 0 (limit: 4604)
     Memory: 24.0K (peak: 280.0K)
        CPU: 4ms
     CGroup: /system.slice/ssh.socket

Jul 29 22:33:44 example.com systemd[1]: Listening on ssh.socket - OpenBSD Secure Shell server socket.

お疲れ様でした

これ、理由が分かれば解決するのは簡単なんですが…、理由が分かるまで足掛け4日ぐらいかかりました…。“お遊びサーバ”のほうで先にこれに引っかかったおかげで、“大事なサーバ”のときは予め対処してからOpenSSHをアップデートできたのが不幸中の幸いか…。

Googleで検索しても同じようなことでconnection refusedになっている人が見つからなかったけど…、うちの設定ってそんなに特殊だったのかな…？

1. 繋がってるSSHのセッションがあったら接続解除にならないよう慎重に！それが無理ならシリアルコンソールとかSSH以外の方法で頑張れ。 ↩

2. IPv4-mappedアドレスでアクセスできていた可能性…？ ↩