# single user sshd

## krotuss

Hi, is it possible to run ssh server restricted to single non-privileged user. I don't want to worry if I had configured /etc/ssh/sshd_config right, or about security bugs in sshd. I simply don't want to see /usr/sbin/sshd running as root, but say rdiff-backup instead. Could anybody provide init script & config examples or hints how to achieve this? Thanks.

----------

## pjp

Take a look at 'man 5 sshd_config' and the AllowUsers and PermitRootLogin options.

But you'll still need to make sure you've properly configured any server.

You may also want to look at PasswordAuthentication.

----------

## krotuss

Thanks, but this is what I am trying to avoid. I have found out that recent version of sshd does not support 'UsePrivilegeSeparation no' option. So it seems to be impossible now with ssh. What about dropbear?

----------

## pjp

If you want to secure sshd, why would you desire 'UsePrivilegeSeparation no'?  *source wrote:*   

> This release deprecates the sshd_config UsePrivilegeSeparation
> 
>    option, thereby making privilege separation mandatory. Privilege
> 
>    separation has been on by default for almost 15 years and
> ...

 

----------

## krotuss

Because this option is intended to reduce attack surface for scenarios when sshd is executed with root privileges (most of the time), probably employing 'setuid' or 'seteuid' syscalls that will fail if sshd is not run within root context. My idea is not to run sshd as root and rely on complex config and hardening to limit it to single user, but instead, to run ssh daemon itself in non-privileged user context. This way, regardless of sshd security bug or sshd miss configuration, potential attacker is limited to single non-privileged user. Of course he still can work his way up using privilege escalation exploit, bu that is different story.

----------

## Ant P.

You can trick sshd into running as a limited user via unshare(1) and user namespaces to make it think it's root. Remember to make the ssh server's private keys fully readable by the restricted user, though at that point you may as well skip the overhead and run rsyncd unencrypted.

----------

## Jaglover

I doubt user can open port 22, you need to use non-standard port.

----------

## Ant P.

You can do that as a limited user too, set the net.ipv4.ip_unprivileged_port_start sysctl sufficiently low. Of course, that means anyone can send spam from port 25, hijack port 80/443, run a fake NFS server, and a million other things, but some people just want security theatre...

----------

## krotuss

Running on non standard port is no issue for me.

 *Ant P. wrote:*   

> though at that point you may as well skip the overhead and run rsyncd unencrypted.

 

Could you please elaborate? Only issue that I can see, is that already authenticated user can read server's private key and potentially use it to impersonate server to itself. My intended setup is one server instance per one user at one machine. Also server security is much more important for me than clients. Clients are "toys" while server is my desktop computer containing personal data, whole setup is intended to run on private LAN.

----------

