Change sshd configuration safely

Editing sshd_config is the one server task where a typo can cost you the server. If the daemon rejects your new configuration, or accepts it and then refuses your key, you have no way back in except the provider console.

So there is one sequence, and I follow it every time, even for a one-line change. Keep the session you have. Validate. Reload, never restart. Open a second session and prove it works. Only then close the first.

Where the settings live

On Ubuntu, /etc/ssh/sshd_config starts with Include /etc/ssh/sshd_config.d/*.conf. Put your changes in a drop-in file instead of editing the main one:

sudo nano /etc/ssh/sshd_config.d/10-notes.conf

For a harmless first change, add a login banner:

Banner /etc/issue.net

Included files are read where the Include line sits, and for most options the first value wins. So a drop-in usually beats the main file, which is what you want.

Validate

Before touching the running daemon, ask it to check the syntax:

sudo sshd -t

No output means the syntax is fine. Now see the effective value, after all includes and defaults are merged:

sudo sshd -T | grep -i banner

banner /etc/issue.net

sshd -T is the server-side twin of ssh -G. If the value you expect is not there, another file is winning, and you found out before reloading.

Reload, in the session you already have

sudo systemctl reload ssh

A reload tells sshd to re-read its configuration. Existing sessions, including yours, stay connected. A restart kills the listener and starts a new one, and if the new one fails to start you are locked out. Reload is enough for almost everything.

Prove a new login works

From your laptop, in a fresh terminal, with the first session still open:

ssh notes-server 'echo ok'

Ubuntu 24.04 LTS
ok

The banner shows up and the command runs. Now, and only now, you can close the first session.

Watch it fail safely

Break the drop-in on purpose. Write Bannerr /etc/issue.net and run sshd -t again:

/etc/ssh/sshd_config.d/10-notes.conf: line 1: Bad configuration option: Bannerr
/etc/ssh/sshd_config.d/10-notes.conf: terminating, 1 bad configuration options

The check caught it. Had you skipped -t and restarted, sshd would have refused to start and your only path in would be the console. Fix the typo and validate again.

Syntax is not the only trap. A valid AllowUsers marco that forgets your own account passes sshd -t perfectly and locks you out on the next login. That is why the second-session test is not optional.

Write the rollback first

Before every change I note the way back:

sudo rm /etc/ssh/sshd_config.d/10-notes.conf && sudo systemctl reload ssh

If the new session fails, you run that in the session you kept open and you are back where you started. One more Ubuntu detail: since 22.10, sshd is started through ssh.socket, so changing Port in the config is not enough there. The port lives in the socket unit too.