Fix SSH Privilege Separation User sshd Does Not Exist (2026)

The SSH daemon (sshd) failed to start because its associated unprivileged user, sshd, which is required for privilege separation, was not found in the system’s user database.

This error, sshd: error: [User sshd does not exist], typically means the sshd process, when trying to drop its root privileges for security, cannot find the dedicated sshd user account it’s supposed to switch to. This user account is a fundamental part of SSH’s security model, ensuring that even if the unprivileged part of sshd is compromised, the attacker doesn’t gain root access.

Here are the most common reasons this happens and how to fix them:

The sshd user was accidentally deleted. This is the most straightforward cause. The user account, along with its associated group, is usually created by the SSH package installation. If it was manually removed or if a system cleanup script was overly aggressive, it will be gone.
- Diagnosis: Check if the user and group exist:
```
grep sshd /etc/passwd
grep sshd /etc/group
```
  If you see no output, the user/group is missing.
- Fix: Recreate the sshd user and group. The exact UID/GID might vary slightly by distribution, but typically they are low numbers. A common and safe approach is to use the useradd command. For Debian/Ubuntu-based systems:
```
sudo groupadd --system sshd
sudo useradd --system -g sshd -d /var/empty -s /usr/sbin/nologin sshd
```
  For RHEL/CentOS/Fedora-based systems:
```
sudo groupadd -r sshd
sudo useradd -r -g sshd -d /var/empty -s /usr/sbin/nologin sshd
```
  The --system or -r flag ensures it’s a system account. /var/empty is a standard, empty directory for such users, and /usr/sbin/nologin prevents interactive logins.
- Why it works: This manually recreates the necessary user and group entries in /etc/passwd and /etc/group, satisfying sshd’s requirement for a user to switch to.
The sshd user’s UID/GID is conflicting or has been changed incorrectly. Sometimes, the user or group exists but has an invalid UID or GID, or it conflicts with another system user/group, causing sshd to fail when it tries to resolve it.
- Diagnosis: Examine the sshd entry in /etc/passwd and /etc/group.
```
grep sshd /etc/passwd
grep sshd /etc/group
```
  Note the UID and GID. Then check for other users/groups with the same UID/GID:
```
grep ":<sshd_uid>:" /etc/passwd
grep ":<sshd_gid>:" /etc/group
```
  (Replace <sshd_uid> and <sshd_gid> with the actual numbers from the previous step.)
- Fix: If there’s a conflict or the entry is malformed, you’ll need to correct it. If the user/group exists but has a bad UID/GID, you can try to reassign it. For example, to change the UID of the sshd user to 65534 and its GID to 65534 (common for unprivileged system users):
```
sudo usermod -u 65534 sshd
sudo groupmod -g 65534 sshd
```
  If the user/group is truly corrupted or missing, refer to fix #1.
- Why it works: This ensures that the sshd user and group have unique, valid identifiers that sshd can reliably use to switch contexts.
Incorrect sshd_config directive for PrivilegeSeparation or User settings. While sshd defaults to using a user named sshd for privilege separation, it’s possible that a misconfiguration in sshd_config is pointing to a non-existent user or has disabled privilege separation incorrectly.
- Diagnosis: Inspect your SSH server configuration file, usually /etc/ssh/sshd_config.
```
sudo grep -E 'PrivilegeSeparation|User' /etc/ssh/sshd_config
```
  Look for lines like PrivilegeSeparation yes (or no) and any User directives that might be interfering. If PrivilegeSeparation is set to yes and there’s no User directive specifying a different unprivileged user, it must find the sshd user.
- Fix: Ensure PrivilegeSeparation is set to yes and that no other User directive is overriding the default sshd user without also defining a valid alternative. If you find a line like User someotheruser, and someotheruser doesn’t exist, either remove the line or create someotheruser. For standard setups, it should look like this:
```
PrivilegeSeparation yes
```
  If you explicitly want to use a different user, e.g., nobody, ensure that user exists and configure it:
```
PrivilegeSeparation yes
User nobody
```
  After modifying /etc/ssh/sshd_config, you must reload or restart sshd:
```
sudo systemctl reload sshd
# or
sudo systemctl restart sshd
```
- Why it works: This ensures the sshd daemon is configured to use privilege separation and that it’s looking for a user that actually exists on the system.
The sshd package is corrupted or incompletely installed. In rare cases, the installation of the openssh-server package might have failed partway, preventing the sshd user from being created or the necessary configuration files from being set up correctly.
- Diagnosis: Check the package manager’s status. For Debian/Ubuntu:
```
dpkg -s openssh-server | grep Status
```
  For RHEL/CentOS/Fedora:
```
rpm -q openssh-server
```
  If the package is listed as "not installed" or has errors, this is the cause.
- Fix: Reinstall the openssh-server package. This will usually recreate the necessary user and configuration. For Debian/Ubuntu:
```
sudo apt-get update
sudo apt-get --reinstall install openssh-server
```
  For RHEL/CentOS/Fedora:
```
sudo yum reinstall openssh-server
# or
sudo dnf reinstall openssh-server
```
  You might need to reapply any custom sshd_config settings after reinstallation.
- Why it works: Reinstalling the package ensures that all components, including the sshd user and default configuration, are properly set up according to the package’s design.
SELinux or AppArmor restrictions preventing user creation/lookup. Security modules like SELinux or AppArmor can sometimes interfere with system processes, including user management or the sshd daemon’s ability to identify its required unprivileged user.
- Diagnosis: Check system logs for SELinux or AppArmor denials related to sshd. For SELinux:
```
sudo ausearch -m avc -ts recent | grep sshd
```
  Or check /var/log/audit/audit.log. For AppArmor:
```
sudo dmesg | grep -i apparmor | grep sshd
```
  Or check /var/log/syslog or /var/log/messages.
- Fix: If you find denials, you’ll need to adjust the security policy. For SELinux, this might involve restoring default contexts or installing specific policy modules. For example, if the sshd user context is wrong, you might try:
```
sudo restorecon -Rv /etc/passwd /etc/group
```
  If SELinux is the persistent issue, temporarily setting it to permissive mode (sudo setenforce 0) can help confirm, but the proper fix is to adjust policies. For AppArmor, you might need to edit the sshd profile in /etc/apparmor.d/. Consult your distribution’s documentation for specific SELinux/AppArmor troubleshooting.
- Why it works: This removes the security policy barriers that prevent sshd from correctly interacting with the system’s user database or the sshd user itself.

After applying any of these fixes, attempt to start or restart the SSH service:

sudo systemctl start sshd
# or
sudo systemctl restart sshd

If the sshd user was the problem, the next error you’ll likely encounter if sshd starts successfully is related to sshd not being able to bind to the network port (e.g., Address family not supported by protocol or Address already in use), which indicates a network configuration issue or another service occupying the port.

More Deep Dives in Ssh