View previous topic :: View next topic |
Author |
Message |
krotuss Apprentice
Joined: 01 Aug 2008 Posts: 218
|
Posted: Sat Oct 28, 2017 10:15 pm Post subject: single user sshd |
|
|
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. |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Sat Oct 28, 2017 11:19 pm Post subject: |
|
|
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. _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
krotuss Apprentice
Joined: 01 Aug 2008 Posts: 218
|
Posted: Mon Oct 30, 2017 9:48 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20067
|
Posted: Tue Oct 31, 2017 1:23 am Post subject: |
|
|
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
sandboxing has been on by default for almost the last five. |
_________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
krotuss Apprentice
Joined: 01 Aug 2008 Posts: 218
|
Posted: Tue Oct 31, 2017 11:01 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Tue Oct 31, 2017 11:49 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Nov 01, 2017 12:20 am Post subject: |
|
|
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... |
|
Back to top |
|
|
krotuss Apprentice
Joined: 01 Aug 2008 Posts: 218
|
Posted: Wed Nov 01, 2017 8:50 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|