Keep a working session and independent console access. Back up the configuration and included snippets, record the actual SSH port, and identify whether the distribution uses ssh.service, sshd.service or socket activation. Change one policy at a time.

1. Inspect the main configuration, Include directives and drop-in files. OpenSSH option ordering and Match blocks can cause the effective value to differ from the line you just edited.
2. Make the narrow intended change, preserving a recoverable copy of the previous file. Do not replace the entire configuration with an unrelated hardening template.
3. Run sudo sshd -t or the distribution's full sshd path to validate syntax and required files. Resolve every error before touching the running daemon.
4. Use sshd -T and, when relevant, its connection-context option to inspect effective settings for the affected account/address. Check authentication and allow/deny rules together.
5. Reload the actual service through the distribution-supported mechanism. Changes involving a socket-managed listening port may need the documented socket workflow rather than only a daemon reload.
6. Open a completely new SSH connection from the intended network and test authentication plus required sudo access before closing the original session.

Run these as an authorised administrator while keeping your current SSH session and independent console available. Replace the user, client address and server address with the connection you intend to allow. These tests do not reload the running daemon.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T \
  -C user=deploy,host=client.example.com,addr=192.0.2.25,laddr=192.0.2.10,lport=22

Read the result: A successful syntax test normally exits without output. The second command prints the effective configuration for that connection context, including applicable Match conditions. Review authentication methods, port and allow/deny rules together. Use the installed distribution's sshd path if it differs.

Passing these tests does not prove the user owns a working key or that the network allows the connection. After a separately reviewed reload, establish a new session from the intended source and verify required access before closing your original session.

No. It validates configuration syntax and key sanity. User restrictions, credentials, network rules and Match conditions still need a real new-connection test.

Confirm the service remains healthy, the intended listener is present, and the new session uses the approved authentication method. Check logs for rejected legitimate users or unexpected exposure on another address family.

If validation fails, restore the previous snippet and rerun the test. If a new connection fails despite valid syntax, use the original session to inspect effective policy, account state, firewall and logs. Restore the known-good configuration through the console if needed rather than repeatedly restarting SSH.

• Installing an SSH key without losing existing server access
• Recovering from an SSH lockout using the server console
• Finding which process listens on a Linux network port
• Testing a Linux server restore before an emergency

• man.openbsd.org: Sshd
• man.openbsd.org: Sshd Config
• Ubuntu: Openssh Server