Linux · critical · Networking, DNS & SSH

sshd will not start, or refuses connections after a configuration change

A configuration error stops sshd starting, or a hardening change locks out the accounts that were being used.

What you see

systemctl start sshd fails, or existing sessions keep working while new ones are refused — which is the state that gives you exactly one chance to fix it.

What is actually wrong

A typo or a deprecated option in sshd_config, a directive placed after a Match block where it no longer applies globally, missing host keys after a rebuild, or wrong permissions on the key files.

Codes and articles

sshd: no hostkeys availableBad configuration optionsshd_config linePermission denied (publickey,password)Connection closed by remote host

Fixes (3)

Use the session you still have properly

The existing SSH session15 minuteslow riskreversible

You have one working session left. Do not close it, and do not restart sshd yet.

Do not close this session. An open connection survives an sshd restart; a closed one cannot be re-established if the configuration is wrong.
Test the configuration before applying it.
Shell
```
sudo sshd -t
```
This validates the file and prints the offending line number without touching the running service. It takes one second and prevents the entire class of lockout.
Start a second sshd on another port as a lifeline before restarting the main one.
Shell
```
sudo /usr/sbin/sshd -p 2222 -o PidFile=/run/sshd-test.pid
```
Open a new connection on port 2222 from another terminal and confirm it works before restarting the main service.
Shell
```
ssh -p 2222 user@server
```
Now restart the main service, verify a new connection on port 22, then stop the lifeline.
Shell
```
sudo systemctl restart sshdsudo kill $(cat /run/sshd-test.pid)
```

Confirm it workedA brand new connection on the normal port succeeds before the lifeline is removed.

If you need to undo itThe lifeline on 2222 remains available until you stop it.

Fix the configuration sshd is rejecting

Console or recovery access20 minutesmedium riskreversible

sshd will not start at all.

Read the exact complaint.

Shell

sudo sshd -tsudo journalctl -u sshd -n 40 --no-pager

Check for host keys — a rebuilt or cloned machine may have none, and sshd will not start without them.
Shell
```
ls -l /etc/ssh/ssh_host_*sudo ssh-keygen -A
```
ssh-keygen -A generates any missing host key types with the correct permissions. Note that new host keys will make every client warn about a changed key, which is expected here and not an attack.
Check permissions, which sshd enforces strictly and refuses to start without.
Shell
```
sudo chmod 600 /etc/ssh/ssh_host_*_keysudo chmod 644 /etc/ssh/ssh_host_*_key.pub
```
Watch for directives placed after a Match block. Everything following a Match applies only to that match until the next one or the end of the file.
Shell
```
sudo grep -n -E '^\s*(Match|PermitRootLogin|PasswordAuthentication|AllowUsers)' /etc/ssh/sshd_config
```
This catches the most confusing sshd fault there is: a setting that is present in the file, spelled correctly, and simply not applying because of where it sits.

Also check the drop-in directory, which overrides the main file on modern distributions.

Shell

ls -l /etc/ssh/sshd_config.d/sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'

Confirm it workedsshd -t is silent and sshd -T shows the effective settings you intended.

Shell

sudo sshd -t && sudo sshd -T | grep -E 'port|permitrootlogin|passwordauthentication'

If you need to undo itKeep a copy: sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak before editing.

Work out why the login is being refused

Both ends25 minuteslow riskreversible

sshd is running and the connection is refused or closed.

Get the client's view of what was offered and rejected.
Shell
```
ssh -vvv user@server 2>&1 | tail -40
```
Get the server's view, which states the actual reason.
Shell
```
sudo journalctl -u sshd -f
```
Check the effective settings rather than reading the file.
Shell
```
sudo sshd -T | grep -E 'allowusers|allowgroups|denyusers|permitrootlogin|pubkeyauthentication|passwordauthentication|authorizedkeysfile'
```
sshd -T prints what the daemon has actually resolved from every file, drop-in and default. Reading sshd_config tells you what someone intended; this tells you what is in force.
Check the permissions on the home directory and authorized_keys — sshd silently ignores keys in a group-writable home.
Shell
```
ls -ld ~ ~/.sshls -l ~/.ssh/authorized_keyschmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys
```
On a system with SELinux, check the context on authorized_keys, which is a common cause after copying files in from elsewhere.
Shell
```
ls -Z ~/.ssh/authorized_keysrestorecon -Rv ~/.ssh
```

Confirm it workedA new session connects with the intended authentication method.

Shell

ssh -o BatchMode=yes user@server 'echo ok'

If you need to undo itPermission changes above are the correct values; nothing needs reverting.

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.