Why SSH Can Ignore a New Port When systemd Owns the Socket

adding another Port line to the SSH server configuration may not open that port when systemd socket activation owns the network listener.

In that setup, the SSH configuration can be valid while the server still listens only on the original port. The fix is to update the socket unit, reload systemd, and test the new port before closing the current session.

Why it happens

Normally, the SSH daemon opens its own listening ports. With socket activation, systemd opens the ports first and passes incoming connections to SSH.

A useful clue appears in the listener output: if both sshd and systemd are associated with the SSH port, the socket unit may be controlling the listener.

How to diagnose it

1. Validate the SSH configuration:

   sudo sshd -t

   No output usually means the syntax is valid.

2. Inspect the active listeners:

   sudo ss -ltnp | grep sshd

3. Check whether socket activation is enabled:

   systemctl status ssh.socket

If the configuration contains both ports but only the original port is listening, the socket unit is the likely cause.

How to add the second port safely

1. Keep the current SSH session open.

2. Create a socket-unit override:

   sudo systemctl edit ssh.socket

   Add:

   [Socket]
   ListenStream=
   ListenStream=22
   ListenStream=2222

   The empty ListenStream= resets the inherited list before the two desired ports are added.

3. Reload the unit configuration and restart the socket:

   sudo systemctl daemon-reload
   sudo systemctl restart ssh.socket

4. Allow the new TCP port in the host firewall and any provider firewall.

5. Verify the listeners, then test from a second terminal:

   sudo ss -ltnp | grep sshd
   ssh -p 2222 user@example-server

Common mistakes

• Cause: only the SSH service was reloaded. Fix: restart ssh.socket when it owns the listener.

• Cause: the inherited socket list was not reset. Fix: include the empty ListenStream= line first.

• Cause: the host firewall is open but the provider firewall is not. Fix: check both layers.

• Cause: the original session was closed too early. Fix: keep it open until a second connection succeeds.

• Cause: a custom port is treated as the main security control. Fix: continue using SSH keys and disable password login where appropriate.

Check the active unit before editing

Unit names and generated socket configuration vary by distribution. Inspect systemctl cat ssh.socket and systemctl status ssh.service before using the example. A running SSH service can retain an old listening socket; follow the distribution’s documented restart sequence if restarting the socket alone does not change the listeners. Keep a working session and recovery console available.

When a valid SSH port setting has no effect, check who owns the listening socket. The next action is simple: inspect ssh.socket before changing the SSH configuration again.

Reference: systemd socket documentation.