sshd_config: baseline for a test stand
SSH access to a test stand often gets opened in a hurry, and then the logs fill with brute-force attempts. A baseline sshd_config that blocks common attack vectors fits into five parameters and twenty minutes.
Why Change Defaults
Distribution-provided sshd ships with permissive settings: root login via password, no user restrictions, three authentication attempts. On a test stand this is tolerable until the logs show:
A local network is not a trusted network. Default configuration means risk and noise in monitoring.
Checking Current Values
Before editing, inspect what’s already set:
Output shows the actual values sshd will use at startup, including parameters from Match blocks.
Four Parameters for a Test Stand
| Parameter | Value | Rationale |
|---|---|---|
PermitRootLogin | no | Root should not log in directly |
AllowUsers | devops admin | Whitelist, everyone else rejected |
PasswordAuthentication | no | Keys only, passwords disabled |
MaxAuthTries | 3 | Block after three failures |
Changes apply after systemctl reload sshd. Make edits via ssh -t user@host "sudo nano /etc/ssh/sshd_config" so you do not lose your session on a mistake.
PermitRootLogin
Direct root login is the first thing attackers brute-force. Disable it:
If you need root access, log in as a regular user and escalate via sudo. This logs your actions to auth.log.
AllowUsers
A whitelist excludes everyone not explicitly added. If a user is not in the list, sshd returns Permission denied before asking for a password.
Specify users space-separated. For groups use AllowGroups. Both parameters support patterns: AllowUsers devops@10.0.0.* restricts login by subnet.
PasswordAuthentication
Keys cannot be brute-forced. Switch the setting:
Before disabling, confirm your public key is in ~/.ssh/authorized_keys on the stand. Otherwise you lock yourself out.
MaxAuthTries
Protection against brute force. After three failed attempts the connection drops:
Setting below one disables the limit. Use 3–5 depending on your network’s reliability.
Validating Configuration
Always validate syntax after editing:
Empty output means sshd will start with the new parameters. Any error prints to the screen.
Then apply:
Common Mistakes
Editing the wrong file. On some distributions sshd_config lives in /etc/ssh/sshd_config.d/. Include files are read in alphabetical order. The default /etc/ssh/sshd_config may be overwritten on package updates — put custom parameters in a .conf file with a meaningful name instead.
Spaces after the parameter. Syntax requires a space between key and value:
Comments instead of parameters. The line #PasswordAuthentication no is a comment, sshd ignores it. Remove the # or add a new line.
Match blocks override global settings. If a Match User root block exists at the end of the file, it may restore PermitRootLogin yes for that user. Check sshd -T output.
Additional
This covers a test stand. Production adds ClientAliveInterval 300, ClientAliveCountMax 2 for keepalive and X11Forwarding no if graphics are not needed. But deploying a minimal baseline takes four parameters and a couple of commands.