Table of Contents
Understanding the SSH Server
Secure Shell, or SSH, provides encrypted remote access to a Linux system. On most Linux distributions the SSH server program is sshd, usually managed as a systemd service. Client commands like ssh, scp, and sftp talk to this server.
When you configure the SSH server, you mainly edit its configuration file, then reload or restart the service so your changes take effect. The standard configuration file is /etc/ssh/sshd_config. The client configuration is a different file and is not the focus here.
Any change to /etc/ssh/sshd_config that locks out remote logins can cut off your access entirely. Always test configuration changes in a separate SSH session before closing your existing one.
Managing the SSH Service
On a system that uses systemd you control the SSH server with systemctl. The name of the service is usually sshd or ssh depending on the distribution. You must use sudo or be root to manage it.
Start the SSH server with:
sudo systemctl start sshdEnable it to start at boot with:
sudo systemctl enable sshdCheck the status with:
sudo systemctl status sshdAfter editing the configuration file, reload it without dropping existing connections:
sudo systemctl reload sshd
If reload is not available or you want a full restart:
sudo systemctl restart sshd
On some Debian based systems the unit is called ssh rather than sshd. In that case substitute ssh in all of the commands above.
The sshd Configuration File
The main server configuration file is /etc/ssh/sshd_config. It is a text file that you edit with a regular text editor. Each line is a directive followed by a value. Comments begin with # and blank lines are ignored.
Directives are usually written in the form:
Keyword value
For example:
Port 22
is one directive, and
PermitRootLogin no
is another. Keywords are case insensitive, but values often are not, so it is good practice to match the examples in the manual.
When you want to see which options are available and what they mean, read the manual page:
man sshd_configThat page documents every directive. For a new server you usually care about ports, addresses, authentication methods, and access control.
Never assume a directive is valid just because it looks reasonable. A typo in /etc/ssh/sshd_config can prevent sshd from starting. Use sshd -t to test the configuration syntax before reloading or restarting the service.
Test the syntax with:
sudo sshd -tIf this prints nothing, the configuration is syntactically valid.
Basic Network Settings
The SSH server listens on TCP ports. The standard port is 22. You can change this with the Port directive.
To use the default port:
Port 22
To move SSH to a nonstandard port, for example port 2222:
Port 2222
You can specify multiple ports by repeating the directive:
Port 22
Port 2222
Moving to a different port does not replace proper security, but it can reduce noise from automated scans.
You can also restrict which local network addresses sshd listens on. By default it listens on all addresses. To limit it, use ListenAddress. For example, to listen only on a specific IPv4 address:
ListenAddress 192.0.2.10
To listen only on IPv6:
ListenAddress ::1
You can use several ListenAddress lines to cover multiple addresses.
After making these changes, test and reload:
sudo sshd -t
sudo systemctl reload sshd
If you change the port, remember that clients must connect with ssh -p PORT user@host.
Host Keys and Key Algorithms
The SSH server identifies itself to clients using host keys. These are private keys stored on the server, typically in /etc/ssh/. Files like /etc/ssh/ssh_host_ed25519_key or /etc/ssh/ssh_host_rsa_key are host keys. Clients remember the server host key and use it to detect impersonation.
The HostKey directives in sshd_config tell the server which host key files to use. For example:
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
If these files do not exist, system tools like ssh-keygen or distribution specific scripts create them. To generate a specific host key manually, for example an Ed25519 key:
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ''
The -N '' argument sets an empty passphrase, which is correct for host keys because the server must start without user input.
You can control which key types and algorithms are allowed with directives such as HostKeyAlgorithms, PubkeyAcceptedAlgorithms, and KexAlgorithms. The exact defaults change over time. On a modern system you typically prefer ed25519 and recent ECDSA types, and you avoid old algorithms like DSA.
Authentication Configuration
SSH supports several authentication methods. On the server you control which ones are allowed using directives in sshd_config. The main choices are password based authentication and public key based authentication.
You enable or disable password authentication with:
PasswordAuthentication yes
or
PasswordAuthentication no
If you set this to no then users cannot log in by typing their account password. In that case they must use another method like public key authentication.
Public key authentication is controlled by:
PubkeyAuthentication yes
which is usually enabled by default. With this method the server checks the public keys listed in the user file ~/.ssh/authorized_keys.
There are other methods, such as keyboard interactive or specific pluggable authentication modules, but the common combination is to allow public key authentication and disable direct password authentication for better security.
If you change any of these settings, you must ensure that at least one viable authentication method is left available, or you will lock yourself out.
Root Login and User Access Controls
The PermitRootLogin directive controls whether the root account can log in directly over SSH. Typical values include yes, no, and prohibit-password which allows only key based login for root. A more restrictive form is:
PermitRootLogin no
With this, the root user cannot log in over SSH at all. Administrators log in with an unprivileged user account and then use sudo for administrative tasks.
You can limit which users and groups may log in using AllowUsers, AllowGroups, DenyUsers, and DenyGroups. For example, to allow SSH access only for two specific users:
AllowUsers alice bob
To allow any user that belongs to a particular group:
AllowGroups sshusers
If both allow and deny directives appear, the order and exact rules are important. The manual page for sshd_config describes the evaluation order in detail. As a general approach, use either a simple allow list or a simple deny list, not both, until you understand the interactions.
When you introduce AllowUsers or AllowGroups, verify that the account you are using is included. If it is not, your next login attempt will fail and you may lose remote access.
Public Key Authentication Layout
For public key authentication, each user has a directory ~/.ssh in their home directory, and inside that directory, an authorized_keys file. The ~ symbol means the user home directory, so for a user named alice this is /home/alice/.ssh/authorized_keys.
The authorized_keys file contains one public key per line. You normally create a key pair on the client with ssh-keygen, then copy the public part to the server into this file.
Server side, the SSH daemon expects secure permissions on the home directory, the .ssh directory, and the authorized_keys file. A typical permission setup is:
Home directory not world writable, .ssh directory with permission 700, and authorized_keys with permission 600. If the permissions are too open, the server may refuse to use the keys.
Common errors, such as if key based authentication does not seem to work, are often caused by wrong paths or insecure file permissions. In that situation server logs are very helpful.
Logging and Troubleshooting sshd
When you have problems with SSH server configuration, logs and verbose modes help you understand what is happening. The server writes log entries to the system logging facility. On systemd systems, you can inspect them with journalctl.
To see recent messages from sshd:
sudo journalctl -u sshd
If the unit is named ssh, adjust the command accordingly.
When sshd refuses to start, test the configuration file syntax with:
sudo sshd -tIf there is an error, this command prints a message that points to the line number and directive that failed. Fix that and test again.
On the client side, you can run ssh with verbose flags such as -v, -vv, or -vvv to see more detailed output about connection attempts. This is especially useful when diagnosing authentication failures or mismatched algorithms. The server logs and the client verbose output together usually reveal misconfigurations.
Timeouts and Idle Sessions
SSH server configuration can control how long connections remain open and how idle sessions are handled. Two directives are often used together: ClientAliveInterval and ClientAliveCountMax.
ClientAliveInterval specifies how often the server sends a message to the client if no data is received. The value is in seconds. For example:
ClientAliveInterval 300
sends a keepalive message every 300 seconds when idle. The directive ClientAliveCountMax decides how many unanswered messages the server tolerates before disconnecting the client. For example:
ClientAliveCountMax 3
combined with the interval above disconnects an unresponsive client after roughly 300 × 3 = 900 seconds, which is 15 minutes, of inactivity at the TCP level.
These settings can keep sessions alive through some firewalls or help you close idle sessions automatically, depending on your needs.
Chroot and Subsystems
Advanced SSH setups may restrict users to a limited view of the filesystem or enable specific subsystems like SFTP.
The Subsystem directive maps a service name to a program. A common example is the SFTP server:
Subsystem sftp /usr/lib/ssh/sftp-server
or in some newer setups:
Subsystem sftp internal-sftp
When you use internal-sftp, the SFTP subsystem is provided by the SSH daemon itself without starting an external binary.
You can combine this with ChrootDirectory in match blocks to restrict certain users or groups to a specific directory tree so they cannot see the full filesystem. The detailed design of chroot environments and match blocks includes multiple directives and would be covered separately. At this point, it is enough to know that sshd_config supports per user and per group conditional configuration sections that begin with a Match line and apply until Match all or end of file.
Example Configuration Snippet
As an illustration, here is a small sshd_config snippet that captures common settings for a hardened but still practical SSH server:
Port 22
ListenAddress 0.0.0.0
ListenAddress ::
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers alice bob adminIn this example, the server listens on the default port for both IPv4 and IPv6, prefers modern host keys, disables root and password logins, allows only public key authentication, sets a keepalive interval, and limits access to specific user accounts.
After you place such settings in /etc/ssh/sshd_config, always test the file with sshd -t, reload sshd, and then verify that you can still connect from a new terminal before closing your existing session.