How to Troubleshoot sshd Not Starting

This guide helps you diagnose and resolve issues preventing the OpenSSH server daemon (sshd) from starting, ensuring secure remote access to your system.

Difficulty: Intermediate Time: 15-45 minutes Best for: System administrators & advanced users

Steps may vary by device and OS version. Make a backup before major changes.

Quick Answer

If sshd won't start, follow these immediate steps in order.

Check the service status: Run systemctl status sshd or service ssh status for an error message.
Test the configuration file: Run sshd -t to check for syntax errors in /etc/ssh/sshd_config.
Verify the SSH port isn't blocked: Use sudo ss -tulpn | grep :22 to see if another process is using port 22.
Check file permissions: Ensure ~/.ssh directory permissions are 700 and authorized_keys file permissions are 600.
Examine system logs: Look for sshd errors in /var/log/auth.log or journalctl -u sshd.
Restart the sshd service: After a fix, run sudo systemctl restart sshd.

If this didn't work, follow the detailed checklist and symptom guide below.

Before You Start

What You Need

Root or sudo access to the affected server.
Physical console access or an alternative remote access method (e.g., direct console, IPMI).
Basic familiarity with the command line and a text editor (nano, vim).
A backup of your /etc/ssh/sshd_config file.
Knowledge of any recent system changes.

What Not to Do

Do not randomly edit configuration files without understanding the syntax.
Do not disable the firewall entirely without investigating rules first.
Do not change critical file ownership (like /etc/ssh/) to permissive settings.
Avoid restarting the server as a first resort if other access is unavailable.

Fast Checklist

Work through these 15 common checks. A ✅ often resolves the issue.

✅ Check sshd service status with systemctl.
✅ Test sshd_config syntax with sshd -t.
✅ Verify SSH port (default 22) is not already in use.
✅ Ensure the sshd process has correct execute permissions.
✅ Confirm /etc/ssh/sshd_config file permissions are 600.
✅ Check ~/.ssh/ directory permissions are 700.
✅ Validate host keys exist in /etc/ssh/ (ssh_host_*_key).
✅ Look for errors in system logs (journalctl, auth.log).
✅ Restart the sshd service after any change.
✅ Ensure the SSH service is enabled to start at boot.
✅ Check for IP address conflicts or missing network.
✅ Review firewall rules (iptables, firewalld, ufw).
✅ Check for SELinux/AppArmor denials.
✅ Verify system memory and disk space are not exhausted.
✅ Consider a recent system update that might have broken compatibility.

Mind Map: sshd Startup Failure

sshd fails to start
├──→ Configuration Error
│   ├──→ Run `sshd -t`
│   │   ├──→ "Permission denied" → Check file ownership & perms
│   │   └──→ "line X: Bad configuration option" → Fix typo in sshd_config
│   └──→ Invalid setting (e.g., Port, ListenAddress)
│
├──→ Port/Network Issue
│   ├──→ Port 22 already in use → `ss -tulpn`
│   ├──→ Firewall blocking port → Check iptables/firewalld
│   └──→ Network interface down → `ip addr show`
│
├──→ File System & Permissions
│   ├──→ Missing host keys → `/etc/ssh/ssh_host_*_key`
│   ├──→ Wrong ~/.ssh/ permissions (not 700)
│   ├──→ Wrong /etc/ssh/sshd_config permissions (not 600)
│   └──→ Full disk or inode exhaustion → `df -h`
│
├──→ Security Module Block
│   ├──→ SELinux denial → Check `/var/log/audit/audit.log`
│   └──→ AppArmor denial → Check `dmesg | grep apparmor`
│
├──→ Service Manager Problem
│   ├──→ Systemd unit file corrupt → `systemctl daemon-reload`
│   └──→ Service not enabled → `systemctl enable sshd`
│
└──→ Resource Exhaustion
    ├──→ Out of memory → `free -h`
    └──→ Process limit reached → `ulimit -u`

Step-by-Step Guide

Step 1: Check Service Status and Logs

What to do: Use your init system to check the sshd service status and recent logs.

Why it helps: This provides the first concrete error message, pointing you towards the root cause.

What you should see: A clear status like "active (running)" or a specific error (e.g., "Invalid configuration," "Address already in use").

Note: For systemd (most modern Linux), use systemctl status sshd and journalctl -u sshd -xe --no-pager. For older systems, check /var/log/auth.log or /var/log/secure.

Step 2: Validate Configuration Syntax

What to do: Run the configuration test command: sudo sshd -t

Why it helps: sshd -t checks your /etc/ssh/sshd_config for syntax errors without starting the server, preventing silent failures.

What you should see: No output means the syntax is OK. Any output is an error message describing the problem and line number.

Step 3: Investigate Port Conflicts and Firewalls

What to do: Check if port 22 (or your configured SSH port) is already in use and verify firewall rules.

Why it helps: Another service might be binding to the SSH port, or the firewall might be preventing sshd from binding to it.

What you should see: The port should be free, or the output should show sshd listening. Firewall rules should allow inbound connections on the SSH port.

Commands: sudo ss -tulpn | grep :22, sudo iptables -L -n or sudo firewall-cmd --list-all.

Step 4: Verify Critical File Permissions and Existence

What to do: Check permissions for key files and directories, and ensure host keys exist.

Why it helps: sshd is security-sensitive and will refuse to start if key files are writable by unauthorized users or are missing.

What you should see: Host key files present in /etc/ssh/. sshd_config permissions should be 600 (rw-------). User ~/.ssh directories should be 700 (drwx------).

Step 5: Apply Fix and Restart Service

What to do: After applying a corrective action, reload the systemd daemon (if you edited a unit file) and restart sshd.

Why it helps: Changes to configuration or service files do not take effect until the service is restarted.

What you should see: A successful restart command and a "active (running)" status from systemctl status sshd.

Standard commands: sudo systemctl daemon-reload (if needed), then sudo systemctl restart sshd.

Common Causes (Explain Like I'm Busy)

Cause	Typical Symptom / Clue
Syntax error in `sshd_config`	`sshd -t` outputs a specific error line.
Port 22 already in use	"Failed to listen on port 22" or "Address already in use" in logs.
Missing host keys	"Cannot load host key" messages in system logs.
Incorrect file permissions	"Permissions too open" or "Unsafe permissions" warnings.
Firewall blocking the port	Service starts but connections timeout or are refused remotely.
SELinux/AppArmor denial	Service starts but fails immediately; denials in `/var/log/audit/audit.log`.
SSH service not enabled	Works after manual start but fails on system reboot.
Out of memory or disk space	Generic "Failed to start" or fork errors; check system resources.

Diagnostics (Safe, Text-First)

Linux (systemd)

Service Status: systemctl status sshd --no-pager -l
Full Logs: journalctl -u sshd -xe --since "1 hour ago"
Config Test: sudo sshd -t
Port Check: sudo ss -tulpn | grep :22
SELinux: sudo ausearch -m avc -ts recent | grep sshd

macOS / Older Linux (sysvinit)

Service Status: service ssh status or /etc/init.d/sshd status
Log Location: Check /var/log/auth.log or /var/log/secure
Launchd (macOS): sudo launchctl list | grep ssh
Process Check: ps aux | grep sshd
Manual Start Test: sudo /usr/sbin/sshd -d (debug mode, run in foreground).

Running sshd in Debug Mode

Run sudo /usr/sbin/sshd -d -p 2222. This starts sshd in the foreground on port 2222 with debug output, showing exactly what happens during startup. Connect from another terminal with ssh -p 2222 user@localhost to trigger the full process. Press Ctrl+C to stop the debug daemon.

Analyzing SELinux/AppArmor Denials in Depth

For SELinux, use sealert -a /var/log/audit/audit.log to generate a human-readable analysis. For AppArmor, check sudo aa-status and profiles in /etc/apparmor.d/. The logs will suggest commands like audit2allow to generate policy modules, but proceed with caution.

Investigating Systemd Unit File Problems

Check the unit file location: systemctl cat sshd.service. Look for overrides in /etc/systemd/system/sshd.service.d/. A corrupted unit can be fixed by reinstalling the openssh-server package or comparing with a default from /usr/lib/systemd/system/.

Troubleshooting PAM Authentication Issues

If sshd starts but authentication fails, check PAM configuration: /etc/pam.d/sshd. A misconfigured PAM module (like pam_limits.so) can prevent logins. Test with ssh -v to see where the connection fails.

Handling IPv4 vs IPv6 Binding Issues

If you have ListenAddress 0.0.0.0 (IPv4) and IPv6 is disabled or misconfigured, sshd may start fine. But if you specify ListenAddress :: (IPv6) and the system lacks IPv6, it may fail. Check your sshd_config ListenAddress directives and network stack.

Prevention & Best Practices

Always run sshd -t before restarting the sshd service after a config change.
Keep a backup copy of your working sshd_config (e.g., sshd_config.bak).
Use version control (like git) for critical configuration files in /etc/.
Implement configuration management (Ansible, Puppet, Chef) to enforce correct settings.
Regularly update your OpenSSH packages to receive security and bug fixes.
Use a non-standard port for SSH to reduce noise from automated attacks, but don't rely on it for security.
Monitor system logs (e.g., with logwatch or fail2ban) for authentication and service errors.
Ensure host keys are backed up and can be restored after a system rebuild.
Keep firewall rules documented and versioned; changes should be tested during maintenance windows.
Test SSH service startup after major system updates or reboots.
Avoid running sshd as a non-root user unless you fully understand the implications and setup.
Periodically audit file permissions in /etc/ssh/ and user ~/.ssh/ directories.

Frequently Asked Questions

Q: I get "sshd: no hostkeys available" — what does this mean?

This means the host key files in /etc/ssh/ are missing or unreadable. Run sudo ssh-keygen -A to regenerate all default host key types (RSA, ECDSA, Ed25519).

Q: Can I run two sshd instances on different ports?

Yes. You can run a second instance with a separate config file using sshd -f /path/to/another_config. Ensure the second config uses a different Port and PidFile.

Q: Why does sshd start but I get "connection refused"?

Most likely a host-based firewall (iptables, firewalld) is blocking the port, or sshd is binding to a specific ListenAddress (like 127.0.0.1) that's not your public IP.

Q: How do I revert to a default sshd_config?

Reinstall the openssh-server package (e.g., sudo apt install --reinstall openssh-server on Debian/Ubuntu). Back up your current config first.

Q: What does "Privilege separation user sshd does not exist" mean?

The system user sshd (or _sshd on some systems) is missing. Reinstalling the openssh-server package should recreate it. Check /etc/passwd.

Q: Does changing the SSH port require a firewall update?

Yes. If a firewall is active, you must add a rule to allow traffic on the new port (e.g., port 2222) and possibly remove the old rule for port 22.

Q: When should I stop and ask a professional?

If you've lost all remote access and lack physical/console access to the server, if system integrity is compromised (suspected hack), or if changes break other critical services, seek help immediately. Don't guess on production systems without a rollback plan.

Q: Can low disk space cause sshd to fail?

Yes. If the disk containing /var/run/, /, or /tmp is full, sshd may fail to create its PID file or start child processes. Check with df -h and df -i (for inodes).

References / Sources

OpenSSH Official Documentation and man pages (sshd, sshd_config)
systemd documentation (systemctl, journalctl)
Linux distribution-specific documentation (Ubuntu, Debian, Red Hat, Arch Wiki)
SELinux and AppArmor administration guides
NIST Special Publication 800-123 (Guide to General Server Security)
IEEE POSIX specifications for security and file permissions

Menu

How to troubleshoot sshd not starting

AI Assistant

Was this tool helpful?