Restarting SSH on Ubuntu is a simple command. The problem is that it often affects the very service that allows you to access the server.
On a local machine, the risk is low. On a VPS or remote server, I prefer to check a couple of things before pressing Enter. A bad configuration, a forgotten port in the firewall, or confusion between ssh And sshdand you might find yourself looking for a backup console.
The command to restart SSH on Ubuntu
On Ubuntu and Debian, the server-side OpenSSH service is usually called sshThe most direct command is therefore:
sudo systemctl restart sshImmediately afterwards, verify that the service has returned to an active state:
sudo systemctl status ssh --no-pagerYou can also perform a shorter check, which is convenient in a script or a quick session:
systemctl is-active sshIf the answer is activeThe service is running. If you get failed, inactive or a unit not found error, do not close your current session before you understand why.
Test the configuration before shutting down the service.
If you modified /etc/ssh/sshd_configFirst, test the configuration. This is a check I always perform before a remote SSH reboot:
sudo /usr/sbin/sshd -tIf the command returns nothing, that’s a good sign. If it displays an error, correct the file before restarting SSH. For an explicit test on the main file:
sudo /usr/sbin/sshd -t -f /etc/ssh/sshd_configThis test doesn’t guarantee that your firewall or cloud provider supports the SSH port, but it does prevent you from restarting a daemon with an invalid configuration. It’s simple, quick, and can save you from having to intervene via the command line.
Restart or reload: which to choose?
To apply an SSH configuration change, you don’t always need a full reboot. When the service allows it, a reload is less disruptive:
sudo systemctl reload sshIn practice, I use reload for a clean configuration change, after a sshd -t Validated. I use restart when the service is blocked, after an OpenSSH update, or when I want to start again from a clean state.
To see what systemd knows about your machine, this command is useful:
systemctl list-unit-files 'ssh*'At some facilities, you might also encounter ssh.socketIn this case, check its condition before touching anything:
sudo systemctl status ssh.socket --no-pagerTo understand systemd commands without confusing service, reload, and restart, you can also reread our guide on useful systemctl commands before a random reboot.
Verify that the SSH port is still listening
The service may be active, but SSH might be listening on a different port than the one you’re using. On a typical Ubuntu system, the port is often the twenty-two, but this is not an absolute rule.
To check which ports are listening:
sudo ss -ltnp | grep ':22'If you have changed the port in the SSH configuration, ask OpenSSH what it is actually applying:
sudo /usr/sbin/sshd -T | grep '^port'To delve deeper into this topic, see the article on netstat, ss and open ports under Linux provides a more comprehensive method.
Also consider your local firewall. With UFW, verification is immediate:
sudo ufw status verboseIf SSH is listening on port 2222, but the firewall only allows port 22, the service can be fully operational yet inaccessible from the outside. The same applies if your hosting provider imposes a firewall or security group upstream.
Check the logs if the restart fails
If systemctl status ssh indicates an error; start by checking the service logs:
sudo journalctl -u ssh -b --no-pager | size -50You can also follow the live messages during a retry:
sudo journalctl -u ssh -fThe most frequent errors are quite obvious: unknown option in sshd_config, port already in use, missing host key, incorrect file permission, or directive placed in the wrong place.
If you need to expand your network coverage after a network change or server restart, the guide on journalctl and the logs of the last Linux boot will help you sort through errors without reading the entire system log.
Precautions to take on a remote server
If you are connected via SSH to the machine you are going to modify, keep your session open. Even open a second session before the service restarts:
ssh user@server-addressAfter restarting, try a new connection from another terminal. If the new connection works, you can close the old one. If it fails, the old session might still be able to save you.
On a production server, also verify that you have a backup console with your hosting provider. This is particularly important if you are simultaneously modifying the SSH port, UFW, a static IP address, or the network configuration. For the latter, see the article on the fixed IP address under Debian gives the same cautious reflexes on the network side.
When to reinstall OpenSSH rather than reboot
A restart is sufficient if the service is installed, the configuration is valid, and the problem is temporary. However, if the unit ssh.service does not exist, if the OpenSSH Server package is missing, or if the server has been cleaned a little too thoroughly, you have to start the installation again.
In this case, do not force restarts in a loop. First, check the package:
dpkg -l | grep openssh-serverIf nothing is reported, repeat the dedicated procedure: reinstall SSH cleanly on UbuntuRestarting a service that is not running will not solve anything.
My quick method before validating
When I need to use SSH on Ubuntu, I keep it simple: configuration test, reload if possible, restart if necessary, then check the port, the firewall and a new connection.
sudo /usr/sbin/sshd -t
sudo systemctl reload ssh
sudo systemctl status ssh --no-pager
sudo ss -ltnp | grep ':22'
sudo ufw status verboseIf you’re working remotely, don’t close the active session until a new SSH connection has been tested. This is probably the least dramatic tip in the article, but it’s the one that prevents the most unpleasant surprises.
The official Ubuntu pages on OpenSSHServer, documentation systemctlthe man pages sshd And sshd_config, as well as the documentation UFWThese are good starting points if you need to document a server procedure.