Is there any risk in running ssh daemon with no root privilege using this method: how-can-i-make-this-daemon-init-run-as-a-non-root-user?

Debian Developer's Best Practices for OS Security says the same thing:

• Starts the daemon dropping privileges: if the software does not do the setuid(2) or seteuid(2) call itself, you can use the --chuid call of start-stop-daemon.


It's easy and gave a good layer of protection, but I can't find any info about applying this method to sshd, and it seems that nobody do this!, why? is there any risk to use this with ssh daemons? does sshd need root for something? I tested in my environment and I had no problem at all! why nobody talk in there guides about this gem?

I already know that I can t bind with ports less than 1024 without root, and I don't need to, I m the only admin of this VPS so the only one who will run the sshd. What's the worst that could happen?


1 Answer 1


The sshd is commonly installed on a system to let users log into this system from remote. To be able to do this at least parts of it would need to run with elevated permissions because otherwise it would not be able to check users against a local password database, access the key information (like authorized_keys file in OpenSSH) for key based authentication and finally being able to login as the specific user.

But, if all you need is to have a sshd running in order to be able to login as a single specific user with key based authentication these problems should not matter. But what matters in this case is that everything is run as the same user account in this situation and thus bugs in any component of the sshd can fully affect this single user. If you compare this with the privilege separation architecture of the OpenSSH server then you will see that it runs critical parts with very low privileges and sandboxed so that a bug in these components have only a low impact. This kind of privilege separation is weakened if everything is run as the same user which means that this setup might provide less security compared to the common setup.

  • 2
    @BadrElmers It uses privilege separation regardless of whether or not it runs as root. Privilege separation on Linux involves using the seccomp syscall filtering system, which does not require root. On OpenBSD, it uses a similar system called pledge, which also does not require root.
    – forest
    Commented Feb 26, 2018 at 2:19
  • 2
    @forest: privilege separation also includes running the non-privileged process with another user id which it cannot do if it is not running as root in the first place. Commented Feb 26, 2018 at 4:31
  • 1
    @SteffenUllrich My point was just that the setting still works, even if not all the security features are functional (e.g. chroot).
    – forest
    Commented Feb 26, 2018 at 4:32
  • 1
    @BadrElmers: again, I don't think that a sshd started as non-privileged user can provide the security of a sshd started as root in the first place. Insofar I don't think it is useful to follow this path in the name of security. If you want to try it anyway (despite better security) you could try at serverfault.com because this is then not a security question anymore. Commented Feb 27, 2018 at 8:28
  • 2
    Note that OpenSSH will already drop to an unprivileged user, keeping only the isolated parent under root. You don't have to worry about a root process exposing itself to the network.
    – forest
    Commented Feb 27, 2018 at 9:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .