SSH Security and Server Access Controls

An SSH configuration mistake can lock out the administrator along with unwanted clients. Keep the current session open, test the provider console, and back up the working configuration. Change one part at a time and verify each change with a new connection.

Prove that key authentication works first

On the client, generate an Ed25519 key if it fits your organization's algorithm policy. Stop if the command offers to overwrite an existing key file; do not replace a key you already use. Protect the private key with a strong passphrase and transfer only the public key to the server.

ssh-keygen -t ed25519 -C "admin-workstation"
ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@server.example
ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no admin@server.example

The host and account are examples. Add the appropriate -p option if the actual SSH port is not 22. Verify the server host-key fingerprint through an independent trusted channel, such as its console. Disabling host verification or deleting a changed-key warning without investigating it is not a repair.

Run the final connection command in a second terminal. After logging in, test the required administrative capability, for example sudo -v for an authorized account. Copying a key does not by itself demonstrate successful authentication or working administrative access.

Inspect effective configuration

sudo sshd -t
sudo sshd -T
sudo sshd -T -C user=admin,host=client.example,addr=192.0.2.10

The first command checks configuration syntax and key sanity; -T displays effective settings. Replace the sample connection details in the final command to evaluate relevant Match conditions. Use the daemon's full path if it is not in PATH. Include files and conditional blocks can make the effective value differ from the line you just edited.

Choose the authentication policy before disabling passwords

This fragment is for a public-key-only policy. Do not apply it unchanged to a deployment that requires password or keyboard-interactive MFA. Disable root login only after another account has proven administrative access.

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Do not blindly append the fragment to the end of the file. Review existing settings and the distribution's drop-in arrangement. Repeat sshd -t and sshd -T -C ... for the intended connection after editing. Resolve any unexpected effective value before applying the configuration.

Reload, then establish another session

Identify the actual service name. Many Debian/Ubuntu installations use ssh, while other distributions use sshd. These are alternatives, not two commands to run consecutively:

sudo systemctl reload ssh
# On a system whose service is named sshd, use this instead:
sudo systemctl reload sshd

Do not close the original session just because the reload succeeded. Test key authentication and an administrative action in a new terminal. If the test fails, use the existing session or console to reverse only your configuration change, validate syntax, and reload the correct service again.

Know what port changes and keepalives do

A different port may reduce noise from basic automated scans; it does not strengthen authentication. If changing it, prepare both cloud and host firewall access first, verify the listener, and test the new connection before removing the old route. With Fail2ban, inspect the actual log source, jail status, and port configuration. Installing its package does not demonstrate active protection.

ClientAliveInterval and ClientAliveCountMax detect an unresponsive client. They do not measure how long a person has left the keyboard idle. If human inactivity requires a session timeout, design that as a separate policy. See the OpenSSH server configuration reference.