[EN] Completely Disabling SSH on Ubuntu Serve

On Ubuntu Server, disabling SSH access may appear to be as simple as stopping the ssh.service. However, on some Ubuntu versions and OpenSSH configurations, the systemd socket activation mechanism may be enabled. In such cases, even if the SSH service is stopped, the system may continue listening on TCP port 22 and automatically start the SSH service again when a new connection request arrives.

Therefore, to fully disable SSH access, it is important to check not only ssh.service but also the ssh.socket unit.

This article explains the difference between ssh.service and ssh.socket, the reason behind common systemd warnings, and how to completely disable SSH access on Ubuntu Server.

The Problem

Suppose we run the following commands to stop and disable SSH:

sudo systemctl stop ssh
sudo systemctl disable ssh.service

After running these commands, we may see a warning similar to:

Stopping 'ssh.service', but its triggering units are still active:
ssh.socket

Similarly, when running:

sudo systemctl stop sshd

the following message may appear:

Stopping 'sshd.service', but its triggering units are still active:
ssh.socket

This message means: The SSH service has been stopped, but ssh.socket, which can trigger and restart the service, is still active. As a result, when a new SSH connection request arrives, systemd may automatically start ssh.service again.

What Is the Difference Between ssh.service and ssh.socket?

To manage SSH correctly, it is important to understand the purpose of these two systemd units.

ssh.service

ssh.service represents the main OpenSSH server service.

You can check its status with:

systemctl status ssh.service

To stop the service:

sudo systemctl stop ssh.service

However, if socket activation is enabled, stopping only ssh.service may not be enough.

ssh.socket

ssh.socket is the systemd socket unit responsible for listening for incoming SSH connections.

You can check its status with:

systemctl status ssh.socket

If you see a status similar to:

Active: active (listening)

the system is still listening for SSH connections. When a new SSH connection arrives, ssh.socket can automatically start ssh.service. For this reason, stopping the SSH service while leaving the socket active does not fully disable SSH access.

Completely Disabling SSH Access

If you want to immediately stop SSH and also prevent systemd from starting it again, the most effective approach is:

sudo systemctl mask --now ssh.socket ssh.service

This command performs two important actions:

• --now immediately stops the active service and socket.
• mask prevents the units from being started again by systemd.

Afterward, verify the status:

systemctl status ssh.socket ssh.service

The expected status should be similar to:

Loaded: masked
Active: inactive (dead)

At this point, SSH has been stopped and prevented from starting again.

Verify That TCP Port 22 Is Closed

After disabling SSH, one of the most important verification steps is confirming that TCP port 22 is no longer listening.

Run:

sudo ss -lntp | grep ':22'

If SSH is completely disabled, this command should return no output.

You can also display all listening TCP ports with:

sudo ss -lntp

If you still see an entry similar to:

LISTEN 0 4096 0.0.0.0:22 0.0.0.0:*

then TCP port 22 is still listening.

In that case, you should investigate which process is using the port.

Existing SSH Sessions May Remain Active

Even after ssh.service and ssh.socket have been disabled, previously established SSH sessions may remain active.

To list running SSH processes:

ps -ef | grep sshd

or, for cleaner output:

pgrep -a sshd

If you also need to terminate existing SSH sessions, you can use:

sudo pkill -KILL sshd

Important Warning

This command immediately terminates active SSH sessions.

If you are currently connected to the server over SSH, your own session will also be disconnected. If you have already masked SSH, you may not be able to reconnect remotely.

For this reason, it is strongly recommended to have an alternative management method available, such as:

• VMware Console
• Hyper-V Console
• Proxmox Console
• iLO
• iDRAC
• IPMI
• Physical console
• Cloud provider console

Recommended Procedure for Fully Disabling SSH

A practical sequence for fully disabling SSH is as follows.

First, mask and stop both the socket and the service:

sudo systemctl mask --now ssh.socket
sudo systemctl mask --now ssh.service

Then verify their status:

systemctl status ssh.socket
systemctl status ssh.service

Next, verify that TCP port 22 is no longer listening:

sudo ss -lntp | grep ':22'

If existing SSH sessions must also be terminated:

sudo pkill -KILL sshd

Finally, verify the port again:

sudo ss -lntp | grep ':22'

If the command returns no output, there is no SSH service listening on TCP port 22.

Difference Between stop, disable, and mask

One of the most commonly misunderstood aspects of systemd is the difference between stop, disable, and mask.

systemctl stop

sudo systemctl stop ssh.service

This command stops the service immediately. However, it does not prevent the service from being started again manually or automatically by another systemd unit. For example if ssh.socket remains active, SSH may be started again when a new connection arrives.

systemctl disable

sudo systemctl disable ssh.service

This prevents the SSH service from starting automatically during a normal system boot.

However, the service can still be started manually or triggered by another systemd unit.

Therefore:

systemctl disable ssh.service

alone is not sufficient to completely disable SSH access.

systemctl mask

sudo systemctl mask ssh.service

mask is a stronger mechanism that prevents the service from being started through systemd.

A masked service normally cannot be started even with:

sudo systemctl start ssh.service

For this reason, mask is more appropriate when a service must be fully disabled for security or operational reasons.

Why Did the ssh.services Command Fail?

If the following command is used:

sudo systemctl disable ssh.services

systemd may return:

Failed to disable unit: Unit ssh.services.service does not exist

The problem is simply an incorrect service name.

The correct unit name is:

ssh.service

Therefore, the correct command is:

sudo systemctl disable ssh.service

Systemd uses the .service suffix in the singular form. There is normally no unit named ssh.services.

Re-enabling SSH

If SSH access is required again later, you must first remove the mask:

sudo systemctl unmask ssh.service ssh.socket

Then you can enable and start the SSH service:

sudo systemctl enable --now ssh.service

Verify the service:

systemctl status ssh.service

Then verify TCP port 22:

sudo ss -lntp | grep ':22'

If SSH is listening again, you may see output similar to:

LISTEN 0 4096 0.0.0.0:22 0.0.0.0:*

How to Check Whether SSH Socket Activation Is Enabled

To display SSH-related systemd units:

systemctl list-units --all | grep -E 'ssh|sshd'

To check socket units specifically:

systemctl list-sockets | grep ssh

If the output contains:

ssh.socket

then SSH socket activation is available or active on the system.

Security Considerations

If SSH access is not required on a server, completely disabling the service can help reduce the system’s attack surface. However, completely disabling SSH is not always necessary. In many environments, a better approach may be to restrict SSH access to specific management networks. For example, to allow SSH access only from the 10.10.10.0/24 management network using UFW:

sudo ufw allow from 10.10.10.0/24 to any port 22 proto tcp

In this scenario, the SSH service remains active, but only systems from the authorized network can connect. The appropriate method should therefore be selected according to the organization’s security policy and the purpose of the server.

Requirement	Recommended Method
Temporarily stop SSH	systemctl stop ssh.service
Prevent SSH from starting at boot	systemctl disable ssh.service
Prevent SSH from being started entirely	systemctl mask ssh.service
Disable socket activation	systemctl mask ssh.socket
Completely disable SSH	systemctl mask --now ssh.socket ssh.service
Allow SSH only from specific networks	Firewall rules
Terminate existing SSH sessions	pkill -KILL sshd

When completely disabling SSH access on Ubuntu Server, running only:

sudo systemctl stop ssh

may not always be sufficient.

The main reason is that ssh.socket may remain active and automatically restart the SSH service when a new connection request arrives.

To stop SSH and prevent it from being started again, the most direct approach is:

sudo systemctl mask --now ssh.socket ssh.service

After applying the change, always verify that TCP port 22 is no longer listening:

sudo ss -lntp | grep ':22'

If the command returns no output, SSH is no longer listening on TCP port 22.

This verification is particularly important during CIS hardening, security hardening, attack surface reduction, and unused service remediation activities. Rather than checking only whether the service is stopped, administrators should also verify related socket units and confirm that the corresponding network port is no longer listening.