Re: openssh sshd user vs. group ???

["nate" <debian-user@aphroland.org>]

<quote who="Michael D. Schleif">

> From README.privsep:
>
> ``When privsep is enabled, during the pre-authentication phase sshd will
> chroot(2) to "/var/empty" and change its privileges to the "sshd" user
> and its primary group.  sshd is a pseudo-account that should not be used
> by other daemons, and must be locked and should contain a "nologin" or
> invalid shell.''
>
> The apt-get install process created that same sshd user; but, there is
> *NO* /home/sshd directory.
>
> So, how can the ``pre-authentication'' process chroot to a non-existing
> directory?
>
> Why did the debian maintainer elect to not follow that readme?
>
> What am I missing?


you seem to be thinking the documented way is 1) the only way
and/or 2) the best way

finger the sshd user and you can see what the home directory is set to,
it does not have to be in /home. to me it is good practice to NOT
put system accounts in /home, it just adds clutter(IMO). see the first
10 or so lines of /etc/passwd, none of those accounts have home
directories in /home

as for the user, sshd could probably chroot as any user, user nobody,
user joeblow, user sshd. and as any group, it doesn't really matter,
the idea is to give a non-root non-privledged account. what that
account/group is named is not important.

that said i have removed the updated ssh's from my systems, since
they are not fully tested yet and debian was not vulnerable to those
bugs in the first place.

just because the docs say something doesn't mean its the best way
to go about doing it, another example would be something like openldap,
which has a flag to drop root privledges, well on my installs i go
one further, and have my init scripts su to user slapd(non root)
and run openldap from there, since some programs have a tendency
to not COMPLETELY drop ALL root privledges when configured to do so.
then i use the kernel's transparent proxy function to redirect the
ports below 1024 to ports above 1024, and everything is fine.
i have not seen anything remotely to what i do documented, just
another way of doing things(it may be better or worse..)


nate





-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org