SysAdmin Tools

SSH Server Hardening Generator

Generate a secure /etc/ssh/sshd_config with CIS benchmark recommendations — disable root login, enforce keys, and restrict access.

Advertisement

Important — Use at Your Own Risk

This tool generates configuration for reference and learning purposes only.

Before applying any generated config to a production server:

  • Test in a staging/development environment first
  • Understand each option before applying
  • Take a full backup of existing configuration
  • Verify compatibility with your OS version
  • Wrong security settings can lock you out of your server

SysAdmin Tools is not responsible for server outages, data loss or security issues caused by applying generated configurations.

1. Basic Settings

Changing the port requires a firewall update

2. Authentication (Hardening)
3. Connection Settings
4. Feature Restrictions
5. Allowed Users / Groups

Space separated usernames

Only these groups can SSH

6. Crypto (Advanced)
Security Score75/100 · Moderate
sshd_config
# sshd_config — generated by SysAdmin Tools
# Validate with: sudo sshd -t   |   Reload with: sudo systemctl reload sshd

# ── Network ──
Port 22
AddressFamily any
ListenAddress 0.0.0.0

# ── Authentication ──
PermitRootLogin prohibit-password        # key-based admin via sudo is recommended
PasswordAuthentication no   # no = SSH keys only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

# ── Connection limits ──
MaxAuthTries 3
MaxSessions 10
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 2

# ── Feature restrictions ──
X11Forwarding no
AllowTcpForwarding no
GatewayPorts no
PermitTunnel no
PrintMotd no

Advertisement

Advertisement

This SSH server hardening generator builds a secure /etc/ssh/sshd_config from a set of toggles, following widely used CIS benchmark recommendations. Disable root login, switch to key-only authentication, limit login attempts, and restrict which users can connect — then copy a fully commented sshd_config to your server.

Note: this is the SSH server configuration (sshd_config), not the SSH client configuration (~/.ssh/config). It controls how the OpenSSH daemon on your Linux server accepts connections. A sshd config generator is handy because the daemon has dozens of directives with security-sensitive defaults, and a single wrong value can either weaken the server or lock you out entirely.

As you toggle options, a live security score out of 100 rates how hardened your configuration is. Everything runs in your browser — nothing is uploaded. Use it to produce a secure sshd config with key only authentication, disabled root login, and optional CIS-recommended ciphers, then apply it safely with sshd -t before reloading.

How to Use the SSH Hardening Generator

  1. 1

    Set the basic listener options

    Choose the SSH port, address family and listen address. If you change the port, remember to update your firewall and any fail2ban jails before reconnecting.

  2. 2

    Harden authentication

    Disable root login (prohibit-password is recommended), turn off password authentication to enforce SSH keys, and lock down empty passwords and challenge-response auth.

  3. 3

    Tune connection limits

    Set MaxAuthTries, MaxSessions, LoginGraceTime and the ClientAlive keepalive values to cut off slow or abusive connections.

  4. 4

    Restrict features and users

    Disable forwarding features you do not use (X11, TCP, tunnels), and optionally limit access to specific AllowUsers or AllowGroups.

  5. 5

    Review the score, copy and apply

    Check the security score, copy the generated sshd_config, back up your existing file, then test with sudo sshd -t and reload with sudo systemctl reload sshd — keeping a second session open in case of mistakes.

Understanding the Generated sshd_config

sshd_config is read by the OpenSSH daemon (sshd) at startup and reload. Each directive is a keyword followed by a value, one per line; later matching directives generally win, and anything not set falls back to OpenSSH's compiled-in default. Hardening is largely about replacing permissive defaults with stricter explicit values. The most impactful settings are in authentication. PermitRootLogin no (or prohibit-password) stops direct root logins; PasswordAuthentication no forces key-based login, which is immune to password brute-forcing; and PermitEmptyPasswords no blocks blank-password accounts. Connection controls like MaxAuthTries, LoginGraceTime and the ClientAlive* pair limit how long and how many times a client can try before being dropped. Feature restrictions reduce attack surface: disable X11Forwarding, AllowTcpForwarding, GatewayPorts and PermitTunnel unless you specifically need them. Finally, AllowUsers/AllowGroups (and their Deny counterparts) restrict SSH to named accounts, and the optional CIS cipher set limits key exchange, ciphers and MACs to modern, strong algorithms. Always validate the file with sshd -t before reloading.
FieldDescription
PortThe TCP port sshd listens on. Changing it requires a matching firewall rule.
PermitRootLoginControls root SSH access. prohibit-password allows key-based root but blocks passwords; no disables it entirely.
PasswordAuthenticationWhen no, only SSH keys are accepted — the single biggest hardening win.
PubkeyAuthenticationEnables public-key authentication; should stay on for key-based logins.
MaxAuthTriesMaximum authentication attempts per connection before the client is disconnected.
LoginGraceTimeSeconds allowed to complete authentication before the connection is dropped.
ClientAliveIntervalSeconds of inactivity before sshd sends a keepalive; with ClientAliveCountMax it closes dead sessions.
AllowUsers / AllowGroupsWhitelists the only users or groups permitted to log in over SSH.
Ciphers / MACs / KexAlgorithmsRestrict the cryptographic algorithms sshd will negotiate; the CIS set uses only strong modern options.

Advertisement

Common SSH Hardening Use Cases

Enforce key-only authentication

Disable PasswordAuthentication and keep PubkeyAuthentication on so the server only accepts SSH keys. This removes password brute-forcing as an attack vector entirely.

Disable direct root login

Set PermitRootLogin to no or prohibit-password so administrators log in as a normal user and escalate with sudo, leaving a clearer audit trail.

Meet CIS benchmark requirements

Apply the CIS-recommended ciphers, MACs and key-exchange algorithms plus strict login limits to satisfy common compliance and audit baselines.

Restrict access to a few accounts

Use AllowUsers or AllowGroups to permit SSH only for named deploy and admin accounts, blocking logins to every other system user.

SSH Server Hardening — Frequently Asked Questions

What is SSH server hardening?
SSH server hardening is the process of changing the OpenSSH daemon's configuration (sshd_config) from its default, permissive settings to stricter ones that reduce the risk of unauthorised access. Typical steps include disabling root login, enforcing key-based authentication, limiting login attempts, restricting which users can connect, and allowing only strong cryptographic algorithms. The goal is to shrink the attack surface of one of the most commonly targeted services on any server.
How to disable root login in SSH?
Set PermitRootLogin no in /etc/ssh/sshd_config to block all direct root logins, or PermitRootLogin prohibit-password to allow root only with an SSH key (never a password). After editing, validate with sudo sshd -t and reload with sudo systemctl reload sshd. Make sure you have a non-root account with sudo access and a working key first, so you are not locked out.
How to disable password authentication in SSH?
Set PasswordAuthentication no (and usually ChallengeResponseAuthentication no / KbdInteractiveAuthentication no) in sshd_config, keeping PubkeyAuthentication yes. This forces all logins to use SSH keys, which cannot be brute-forced like passwords. Before applying, confirm your public key is in ~/.ssh/authorized_keys on the server and that you can log in with it, then reload sshd.
What port should SSH use for security?
SSH defaults to port 22. Moving it to a non-standard high port (for example 2222) reduces automated scanner noise, but it is "security through obscurity" — not a real control, since a determined attacker can find the port. The meaningful protections are key-only authentication, fail2ban, and firewall rules. If you do change the port, update your firewall, SELinux (semanage port), and any fail2ban jails to match.
What are CIS benchmark SSH requirements?
The CIS (Center for Internet Security) benchmark for SSH recommends a hardened baseline: disable root login and empty passwords, enforce strong Ciphers, MACs and KexAlgorithms, set MaxAuthTries to a low value, configure LoginGraceTime and idle timeouts, disable unused forwarding, and restrict access to authorised users. This generator can emit the CIS-recommended cryptographic algorithm lists when you enable the CIS ciphers option.
How to restrict SSH access to specific users?
Use AllowUsers followed by a space-separated list of usernames (for example AllowUsers admin deploy), or AllowGroups with group names. Once set, only those users or members of those groups may log in over SSH; everyone else is denied even with valid credentials. You can also use DenyUsers / DenyGroups to block specific accounts while allowing the rest.
What is SSH key-based authentication?
Key-based authentication uses a cryptographic key pair instead of a password. You keep a private key on your client and place the matching public key in ~/.ssh/authorized_keys on the server. At login, the server challenges the client to prove it holds the private key, without the key ever crossing the network. It is far more secure than passwords because keys are long, random, and immune to brute-force guessing.
How to limit SSH login attempts?
Set MaxAuthTries to a low number such as 3 in sshd_config to cap authentication attempts per connection, and LoginGraceTime (e.g. 60) to limit how long an unauthenticated session can stay open. Combine this with fail2ban, which bans an IP at the firewall after repeated failures across connections, for layered protection against brute-force attacks.
How to check if sshd config is valid?
Run sudo sshd -t (test mode) to parse the configuration and report syntax errors without restarting the service, or sudo sshd -T to print the fully resolved effective configuration. Always run sshd -t after editing sshd_config and before reloading, so a typo does not take the SSH daemon down and lock you out.
How to apply sshd_config changes safely?
Back up the current file (sudo cp /etc/ssh/sshd_config{,.bak}), make your edits, then validate with sudo sshd -t. Reload with sudo systemctl reload sshd rather than restart where possible. Crucially, keep your current SSH session open and open a second new session to confirm you can still log in before closing the first — that way a mistake is recoverable instead of locking you out.
Is this the same as the ~/.ssh/config SSH client tool?
No. This generator produces the SSH server configuration, /etc/ssh/sshd_config, which controls how the OpenSSH daemon accepts incoming connections. The separate SSH Config Generator builds ~/.ssh/config, the client-side file that defines connection aliases, keys and options for servers you connect to. Server hardening and client config are two different files for two different sides of the connection.

Related Tools

Fail2ban Generator

Add an SSH jail to ban brute-force IPs on top of a hardened sshd_config.

SSH Config Generator

Build the client-side ~/.ssh/config to connect to your hardened server.

Port Checker

Verify your (possibly changed) SSH port is reachable from outside.

Security Headers

Harden the web layer once your SSH access is locked down.