Restarting SSH on Ubuntu is sudo systemctl restart ssh (or sshd - both work because of a symlink). For config changes, sudo systemctl reload ssh re-reads sshd_config without dropping existing sessions. The team that validates with sudo sshd -t before the restart avoids the worst-case scenario: a bad config that prevents the daemon from starting, locking everyone out.
Table of contents
- The systemd command
- The status check
- The reload form
- The config validation
- The test connection
- The pitfall: restarting over SSH
- The legacy SysV init command
- FAQ
The systemd command
On Ubuntu 22.04+ (and 20.04, 18.04 with systemd):
sudo systemctl restart sshOr equivalently:
sudo systemctl restart sshdUbuntu’s openssh-server package installs a systemd unit called ssh.service. The sshd name is a symlink that points to the same unit. Both names work.
The team that types service ssh restart (the legacy SysV init command) also works on systemd-managed systems because systemd provides a compatibility shim. But systemctl is the right answer for modern Ubuntu.
The status check
After the restart, check that the daemon is up:
sudo systemctl status sshExpected output: a green active (running) line, the main PID, and recent log lines. The team that sees active (running) has a working SSH daemon. The team that sees failed or inactive (dead) has a config error that prevented the restart.
The reload form
For most config changes, a reload is enough (no connection drop):
sudo systemctl reload sshThe reload re-reads /etc/ssh/sshd_config without dropping existing connections. The team that changes Port, ListenAddress, or other listen-time settings needs a full restart, not a reload - those changes only take effect on a new process.
The rule: if the change is in how the daemon accepts connections, restart. If the change is in how the daemon handles existing connections, reload.
The config validation
Before restarting, validate the config:
sudo sshd -tIf the config has a syntax error or a bad value, this command prints the error. Exit code 0 means the config is valid.
The team that runs sshd -t before the restart catches the typo that would have prevented the daemon from starting. The team that restarts without checking gets a daemon that fails to start and an SSH session that drops - the worst possible outcome if you made the change over SSH.
The test connection
After the restart, open a new SSH session from another terminal and verify it works:
# From another terminal / machine
ssh user@serverThe team that tests before closing the original session has a fallback - the original session is still alive if the new one fails. The team that restarts and immediately closes the original session has no fallback if the new connection fails.
The pitfall: restarting over SSH
The single most common SSH mistake: making a config change, restarting, and getting locked out.
The right pattern:
- Edit
sshd_config. sudo sshd -tto validate.- Open a second SSH session and verify it works.
sudo systemctl reload sshin the original session.- Verify the second session still works.
- Close the second session.
The team that follows this pattern has zero lockouts. The team that does not has at least one memorable incident in their career.
The legacy SysV init command
On older Ubuntu (16.04 and earlier without systemd):
sudo service ssh restartThat still works on systemd systems as a compatibility shim. The team that has a modern Ubuntu is using systemctl for everything else - the SSH command should match.
FAQ
What is the right command to restart SSH on Ubuntu?
sudo systemctl restart ssh (or sshd - both work). The team that uses the older service ssh restart is missing out on systemd features but the command still works.
Will restarting SSH drop my current session?
No, not on modern systemd. The systemd unit uses KillMode=process which kills only the main process, not the per-connection children. Your session continues. The team that uses kill -9 on the sshd PID does drop sessions; the team that uses systemctl restart does not.
How do I check if SSH is running?
sudo systemctl status ssh. Green active (running) is what you want.
Why is my restart failing?
Run sudo sshd -t to see the config error. Common causes: typo in sshd_config, bad permission on a key file (must be 600), invalid Port value. The team that reads the error message has a 30-second fix. The team that does not has a 30-minute debug session.
Can I reload instead of restart?
Yes, for most changes. sudo systemctl reload ssh re-reads the config without dropping connections. The team that needs to change the Port, ListenAddress, or other listen-time settings needs a full restart, not a reload.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: