How to Configure and Secure the SSH Server (sshd) with Examples

Secure Shell (SSH) is a cornerstone of remote server management. Its server component, sshd, offers powerful configuration options for both casual users and enterprise administrators. This guide walks through how to configure and secure sshd, with practical examples to help you understand and implement best practices.

How Configuration Files Interact

The primary configuration file for the SSH daemon is /etc/ssh/sshd_config. This file determines how the server behaves when it accepts SSH connections.

In contrast, client settings live in /etc/ssh/ssh_config or the user's ~/.ssh/config file. However, sshd_config is where administrators control authentication methods, access rules, and session behavior.

When the SSH daemon starts or reloads, it reads sshd_config in top-down order. If a directive is repeated, the last valid occurrence usually takes effect. After making changes, run:

sudo systemctl restart sshd

Or on some systems:

sudo service ssh restart

To test the config before restarting:

sshd -t

Typical Settings for Personal SSH Use

If you're managing a personal VPS or home lab, you can improve security and convenience with a few simple adjustments:

Port 2222 
PermitRootLogin no 
PasswordAuthentication no 
AllowUsers alice

These settings change the default SSH port, disable root logins, require key-based authentication, and restrict access to specific users. Always back up the original file before making changes.

Common SSH Config Adjustments for Organizations

In enterprise environments, SSH configuration must balance usability, compliance, and security. Below are essential settings that organizations often adjust in sshd_config.

Encryption Policy Settings

Set strong, modern encryption algorithms to protect data in transit. Use the Ciphers, MACs, and KexAlgorithms directives:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com 
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com 
KexAlgorithms curve25519-sha256,ecdh-sha2-nistp521

These settings remove outdated algorithms and enforce cryptographic best practices.

Enabling Detailed Logging

For auditing and debugging purposes, increase logging verbosity:

LogLevel VERBOSE

This provides more granular information about user activity and authentication attempts, which is useful for security monitoring.

Setting the Path for AuthorizedKeysFile

To centralize or customize where public keys are read from:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

This example stores each user’s public key under a shared directory, replacing %u with the username.

Controlling Root Access

Root login should be tightly controlled or disabled entirely:

PermitRootLogin prohibit-password

This allows root login only via key-based authentication. To disable root access altogether:

PermitRootLogin no

Displaying a Login Banner

To meet compliance standards or display a legal warning, configure a login banner:

Banner /etc/issue.net

Populate /etc/issue.net with the desired message, such as:

Unauthorized access to this system is prohibited. 
All activity is monitored and logged.

Managing Port Forwarding Settings

Restrict or enable port forwarding depending on internal policy:

AllowTcpForwarding no 
PermitTunnel no 
X11Forwarding no

For users who need secure tunneling, these can be selectively enabled.

Using Certificate-Based Authentication

For environments managing large numbers of users, SSH certificates offer scalable access control. Generate a CA key and sign user public keys:

ssh-keygen -s ca_key -I user_id user_key.pub
In sshd_config, specify the trusted CA:
TrustedUserCAKeys /etc/ssh/ca.pub

This allows any key signed by the specified CA to authenticate, simplifying user management.

sshd_config Syntax and Structure Explained

The syntax of sshd_config is simple: one directive per line, followed by its value(s). Comments begin with #. 

# This is a comment 
Port 22 
PermitRootLogin no

Directives are case-insensitive but should follow conventional formatting for readability. Common mistakes include:

• Trailing spaces
• Invalid parameter values
• Repeating conflicting directives

To apply changes:

sudo systemctl reload sshd

Or use sshd -t before restarting to ensure the syntax is valid.