You have edited `/etc/ssh/sshd_config` on a remote Linux server you can only reach over SSH. What do you do before and after restarting sshd so a mistake in that file does not lock you out?

## The failure this protects against A typo in `sshd_config`, or a directive that is valid but wrong, can leave sshd refusing to start or refusing *you* specifically. On a machine whose only access path is SSH, that is a trip to the console — or, on hardware without one, a physical trip. The whole procedure exists because the tool you are changing is the tool you are holding. ## Before: validate the file ``` sshd -t ``` The extended-test flag parses the configuration and checks the host keys, printing the file and line number of the first problem and exiting non-zero if there is one. It is cheap and it catches the whole class of typo errors. On most distributions `sshd` is not on a normal `PATH`, so run it as `/usr/sbin/sshd -t`. ``` sshd -T | grep -i clientalive ``` The uppercase form dumps the **effective** configuration — every directive with the value actually in force, defaults included. This is how you answer "did my edit take effect, or is it being overridden by an earlier directive or a drop-in file?" without restarting anything. OpenSSH takes the *first* value seen for most keywords, so a duplicate earlier in the file silently wins; `-T` is what makes that visible. Note that conditional blocks are only evaluated when you supply connection details, so read the dump with that in mind. Take a backup before editing at all — `cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak` — because your rollback plan needs something to roll back to. ## Applying it: reload rather than restart For a configuration change, `systemctl reload` is the right verb: the unit's reload action sends `SIGHUP` to the main daemon, which re-executes itself and re-reads the file. The unit name differs by distribution — `ssh.service` on Debian and Ubuntu, `sshd.service` on RHEL and its derivatives — and getting that wrong is its own small trap. The reassuring part, and the thing interviewers like to hear you know: **your existing session survives**. Each accepted connection is handled by a forked child process, and the shipped unit file stops only the main daemon rather than every process in its control group, so restarting the listener does not evict logged-in users. What a restart *does* do is close the door behind it — if the new configuration is broken and the daemon fails to come back, no new connection can be made, and you are down to the session you already hold. Which is exactly why you do not close it. ## After: prove it from a new connection Open a second terminal and connect fresh. If that succeeds, the change is safe and you can let the original go. If it fails, you still have a live root-capable shell to restore the backup and reload again. This ordering — hold, change, verify in a new session, release — is the single most valuable habit in the answer, and it generalises to firewall rules and network configuration on remote hosts. Check the daemon's own view too: ``` systemctl status ssh journalctl -u ssh --since '5 min ago' ``` A daemon that failed to start says so plainly in its log, usually naming the directive it did not like. ## The safety net for genuinely risky edits When you are changing something that could plausibly refuse your own login — authentication methods, the listening address, access lists — arm an automatic rollback before you apply it: ``` systemd-run --on-active=5m /bin/sh -c \ 'cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && systemctl reload ssh' ``` That schedules a one-shot timer five minutes out. If your new session works, cancel the timer; if it does not, the machine repairs itself while you wait. It is the remote-hands equivalent of a dead-man's switch, and it is the difference between a five-minute inconvenience and a data-centre ticket. Beyond that, know your out-of-band path before you need it: an IPMI or iDRAC console, a cloud provider's serial console, or a hypervisor console. On a fleet, that access should be tested periodically, because discovering that the console credentials are wrong at the moment you are locked out is a bad time to find out. ## What a weak answer looks like "Just restart it and see" — with no validation, no held session, and no console. It works most of the time, which is precisely why the habit never forms, and then one afternoon it does not.