SSH service reload not working in Debian 13 - fatal: Cannot bind any address

Written by Claudio Kuenzler - 0 comments

Published on February 18th 2026 - Listed in Linux Systemd Ansible

---

While running an Ansible playbook against a Debian 13 (Trixie) machine, one specific task "SSH - Reload sshd" failed and caused the playbook run to halt.

TASK [SSH - Reload sshd] ***************************************************************************
[ERROR]: Task failed: Module failed: Unable to reload service ssh.service: Job for ssh.service failed because the control process exited with error code.
See "systemctl status ssh.service" and "journalctl -xeu ssh.service" for details.

Origin: /pub/ansible/playbooks/serversetup.yaml:138:5

136     register: sshdconfigvars
137
138   - name: SSH - Reload sshd
        ^ column 5

fatal: [debian13]: FAILED! => {"changed": false, "msg": "Unable to reload service ssh.service: Job for ssh.service failed because the control process exited with error code.\nSee \"systemctl status ssh.service\" and \"journalctl -xeu ssh.service\" for details.\n"}

This caught me off guard and I was pretty surprised to see this, rather basic, task to fail.

Manually reproducing the error

This Ansible task in question only does one thing: Reload the SSH service using the systemd_service module (state: reloaded).

Running the reload command manually on the target server confirmed the error:

root@debian13:~# systemctl reload ssh
Job for ssh.service failed because the control process exited with error code.
See "systemctl status ssh.service" and "journalctl -xeu ssh.service" for details.

Not only did the SSH service not reload, the listener, previously pointing to sshd, changed, too.

Before running systemctl reload ssh:

root@debian13:~# ss -lntup|grep :22
tcp   LISTEN 0      4096               *:22               *:*    users:(("sshd",pid=195701,fd=3),("systemd",pid=1,fd=97))   

This shows the listener port (default tcp/22) is bound to the sshd process, running here as PID 195701.

After running systemctl reload ssh:

root@debian13:~# ss -lntup|grep :22
tcp   LISTEN 0      4096               *:22               *:*    users:(("systemd",pid=1,fd=97))  

The sshd process seems gone? 

The service itself falls into a failed state:

root@debian13:~# systemctl status ssh
x ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
    Drop-In: /run/systemd/system/service.d
             |-zzz-lxc-service.conf
     Active: failed (Result: exit-code) since Wed 2026-02-18 11:43:12 UTC; 51s ago
[...]

SIGHUP is the reload signal

The Systemd service unit defines what command should be executed in the background, when the service should be "reloaded":

root@debian13:~# cat /usr/lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target nss-user-lookup.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service

Relevant in this situation are the two lines starting with ExecReload. The definition uses the kill command to send a HUP signal (SIGHUP) to the PID of the sshd process.

This can be done manually, too:

root@debian13:~# kill -HUP $(pgrep -x sshd)

Although no error showed up, the same problem can be seen in the ssh service logs:

root@debian13:~# kill -HUP $(pgrep -x sshd)
Feb 18 11:27:44 debian13 sshd[195958]: Received SIGHUP; restarting.
Feb 18 11:27:44 debian13 sshd[195958]: fatal: Cannot bind any address.
Feb 18 11:27:44 debian13 systemd[1]: ssh.service: Main process exited, code=exited, status=255/EXCEPTION
Feb 18 11:27:44 debian13 systemd[1]: ssh.service: Failed with result 'exit-code'. 

A fatal error shows up, hinting that the listener port could not  be bound to any address. This is no surprise, as the SSHD process is already running and listening on tcp/22. But somehow the triggered reload causes another port binding... ?

Ansible task workaround

If it's a bug in Debian 13, then at least it's reported now. Bugs can happen, oh well. But for my Ansible situation I still needed a workaround.

Luckily restarting the ssh service does not cut active SSH sessions. Hence I just changed the state from "reloaded" to "restarted":

  - name: SSH - Reload sshd
    systemd: 
      name: ssh.service
      #state: reloaded # broken in Debian 13
      state: restarted

And at the next Ansible run, the task executed successfully:

TASK [SSH - Reload sshd] ***************************************************************************
changed: [debian13]

Debian Bug report ... and deeper analysis pointing to ssh.socket

As I could not reproduce this problem on another Debian release, this is likely a new bug. I reported the bug as Debian Bug #1128329 using reportbug.

Update 1

One of the maintainers already wrote back and was unable to reproduce this. I tried to reproduce this on a Debian machine, recently upgraded from 12 to 13 but didn't get any errors either. The reload error might only be triggered under specific environments, most likely in LXC containers. 

So far I could see the following difference. 

On the Debian 13 machine running into the reload error: 

root@debian13:~# systemctl status ssh | head -n 5
- ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
    Drop-In: /run/systemd/system/service.d
             |-zzz-lxc-service.conf
     Active: active (running) since Wed 2026-02-18 13:47:58 UTC; 31s ago

On another Debian 13 machine not running into the reload error:

root@anotherdebian13:~# systemctl status ssh | head -n 5
- ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-02-18 14:20:19 CET; 29min ago
 Invocation: fe7353a3a5a1496498ae5ca2917bd016
       Docs: man:sshd(8)

Could the drop-in config cause the problem? I'm digging into this... 

Update 2

The LXC difference is actually not the reason and neither is the Drop-In config (zzz-lxc-service.conf). But there is one major difference.

On LXC containers, that were upgraded from Debian 12 to Debian 13, the SSH service unit looks like this:

root@debian13upgraded:~# systemctl status ssh
o ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-02-18 15:20:59 CET; 1h 30min ago
 Invocation: bba7bd32e29d45199235a58c6790ebc2
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 25288 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 25291 (sshd)
[...]

On LXC containers there were created with Debian 13 from scratch, the SSH service unit looks like this:

root@debian13new:~# systemctl status ssh
o ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
    Drop-In: /run/systemd/system/service.d
             |-zzz-lxc-service.conf
     Active: active (running) since Wed 2026-02-18 11:30:53 CET; 5h 28min ago
 Invocation: 3d886177bbb043c48620833d63c798a5
TriggeredBy: o ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 197540 (sshd)
[...]

Note the "TriggeredBy" line, which indicates that ssh.service is triggered by ssh.socket.

On the upgraded Debian 13 container, the ssh.socket is disabled:

root@debian13upgraded:~# systemctl status ssh.socket
o ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: enabled)
     Active: inactive (dead)
   Triggers: o ssh.service
     Listen: [::]:22 (Stream)

But on the newly installed Debian 13 container, ssh.socket is active:

root@debian13new:~# systemctl status ssh.socket
o ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; enabled; preset: enabled)
     Active: active (listening) since Wed 2026-02-18 14:23:30 UTC; 1h 28min ago
 Invocation: 9615c912c29d45319a6124517c0f74f7
   Triggers: o ssh.service
     Listen: [::]:22 (Stream)
      Tasks: 0 (limit: 76096)
     Memory: 8K (peak: 256K)
        CPU: 328us
     CGroup: /system.slice/ssh.socket

Feb 18 14:23:30 debian13 systemd[1]: Listening on ssh.socket - OpenBSD Secure Shell server socket.

Now if I disable ssh.socket on the newly installed Debian 13 container, what will happen?

root@debian13new:~# systemctl disable --now ssh.socket
Removed '/etc/systemd/system/sockets.target.wants/ssh.socket'.

root@debian13new:~# systemctl status ssh.socket
o ssh.socket - OpenBSD Secure Shell server socket
     Loaded: loaded (/usr/lib/systemd/system/ssh.socket; disabled; preset: enabled)
     Active: inactive (dead)
   Triggers: o ssh.service
     Listen: [::]:22 (Stream)

Feb 18 14:23:30 debian13 systemd[1]: Listening on ssh.socket - OpenBSD Secure Shell server socket.
Feb 18 15:53:31 debian13 systemd[1]: ssh.socket: Deactivated successfully.
Feb 18 15:53:31 debian13 systemd[1]: Closed ssh.socket - OpenBSD Secure Shell server socket.

root@debian13new:~# systemctl reload ssh

root@debian13new:~# journalctl -u ssh -n 10
Feb 18 15:55:22 debian13 systemd[1]: Reloading ssh.service - OpenBSD Secure Shell server...
Feb 18 15:55:22 debian13 sshd[3438]: debug1: Received SIGHUP; waiting for children
Feb 18 15:55:22 debian13 sshd[3438]: Received SIGHUP; restarting.
Feb 18 15:55:22 debian13 systemd[1]: Reloaded ssh.service - OpenBSD Secure Shell server.
Feb 18 15:55:22 debian13 sshd[3438]: debug1: ssh_systemd_notify: socket "/run/systemd/notify" notified RELOADING=1\nM>
Feb 18 15:55:22 debian13 sshd[3438]: debug1: Set /proc/self/oom_score_adj to 0
Feb 18 15:55:22 debian13 sshd[3438]: debug1: Set /proc/self/oom_score_adj from 0 to -1000
Feb 18 15:55:22 debian13 sshd[3438]: debug1: Bind to port 22 on 0.0.0.0.
Feb 18 15:55:22 debian13 sshd[3438]: Server listening on 0.0.0.0 port 22.
Feb 18 15:55:22 debian13 sshd[3438]: debug1: ssh_systemd_notify: socket "/run/systemd/notify" notified READY=1

No more errors on reload!

This means that ssh.socket somehow fumbles in between and causes the errors in the ssh.service. 

LXC description	systemctl reload ssh	ssh.socket enabled
Debian 13 new install	runs into error (fatal: Cannot bind any address)	yes
Debian 13 upgraded from Debian 12	no errors	no

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.