sshd — the SSH server

Q: Permission denied (publickey)

Permissions on the server: ~/.ssh=700, authorized_keys=600, owner is the user itself. journalctl -u ssh → often "Authentication refused: bad ownership or modes". See ssh-keys.

Q: Connection refused

The server isn't listening on the port: ss -tlnp | grep :22, systemctl status ssh. Or the port is closed by the firewall — allow 22/tcp (see firewall).

Q: Locked yourself out with a config change

Get in through the hypervisor console/serial and roll back sshd_config (or sshd -t would have shown the error before reload — always check).

5 min Ubuntu 24.04 · OpenSSH 9.6

The OpenSSH server; edit the config with a second session open — a mistake in PermitRootLogin locks you out immediately.

Cheat sheet

5 commands Printable version

sudo sshd -t check config syntax
sudo sshd -T | grep -i permitroot the effective value of a parameter
sudo systemctl reload ssh apply without dropping sessions
ss -tlnp | grep :22 is the port listening
journalctl -u ssh -f connection logs in real time

Overview

sshd is the OpenSSH server, accepting remote connections (port 22 by default). Managed by systemd (the unit is called ssh on Ubuntu). Authentication is by keys (recommended) or by password.

Key-based login: the client's public key is placed in ~/.ssh/authorized_keys on the server (see ssh-keys).

bash

systemctl status ssh
ss -tlnp | grep :22               # is the port listening (see ss)

Configuration

The main config is /etc/ssh/sshd_config (plus snippets in /etc/ssh/sshd_config.d/). A safe baseline:

PermitRootLogin no
PasswordAuthentication no         # keys only
PubkeyAuthentication yes
Port 22

Apply changes safely (without dropping the current session):

bash

sudo sshd -t                      # check the config syntax
sudo sshd -T | grep -i permitroot # show the EFFECTIVE values (important!)
sudo systemctl reload ssh         # apply (the ssh unit)

Important. When editing the SSH config remotely, keep a second session open — that way a mistake won't lock you out of the server. A safety net with an auto-rollback timer: sudo sh -c 'sleep 300 && systemctl restart ssh' &.

Recipes

Hardening

Parameter	Why
`PermitRootLogin no`	don't allow root to log in directly
`PasswordAuthentication no`	keys only (the main defense against brute force)
`MaxAuthTries 3`	fewer attempts per connection
`AllowUsers alice bob`	a user whitelist
`AllowGroups sshusers`	a group whitelist
`AllowTcpForwarding no`	disable tunnels (if not needed)
`X11Forwarding no`	disable X forwarding
`ClientAliveInterval 300`	disconnect dead sessions

Fine-grained control through Match (by group/address):

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Commands

bash

systemctl status ssh              # server state
sshd -t                           # check sshd_config (syntax)
sudo sshd -T                      # effective configuration (all parameters)
ss -tlnp | grep :22               # is the port listening
journalctl -u ssh -f              # connection/rejection logs
journalctl -u ssh | grep -i fail  # failed logins (brute force? see fail2ban)
ssh -v user@host                  # connection debugging from the client

Troubleshooting

Permission denied (publickey)

Permissions on the server: ~/.ssh=700, authorized_keys=600, owner is the user itself. journalctl -u ssh → often "Authentication refused: bad ownership or modes". See ssh-keys.

Connection refused

The server isn't listening on the port: ss -tlnp | grep :22, systemctl status ssh. Or the port is closed by the firewall — allow 22/tcp (see firewall).

Connection timed out

A network/firewall-level issue (never reached sshd): route, security group, nftables. Check with nc -zv host 22.

Changed the port — can't connect

SELinux/the port isn't allowed, the firewall is still on the old port, or the client is connecting to 22. Open the new port in firewall, check sshd -T | grep -i port.

Locked yourself out with a config change

Get in through the hypervisor console/serial and roll back sshd_config (or sshd -t would have shown the error before reload — always check).

Danger zone

reload/restart apply the new config to every subsequent connection immediately; a mistake in PermitRootLogin, AllowUsers, or PasswordAuthentication can lock out everyone, including you. Edit the config only with a second session open, and check sshd -t before restarting, not after. Disabling PasswordAuthentication without a tested key already installed leaves the server with no working way to log in at all.

Overview

Configuration

Recipes

Hardening

Commands

Troubleshooting

Permission denied (publickey)

Connection refused

Connection timed out

Changed the port — can't connect

Locked yourself out with a config change

Danger zone

See also