On Wed, 10 Dec 2008, Dan Nelson wrote:
In the last episode (Dec 10), Dan Mahoney, System Admin said:
On Wed, 10 Dec 2008, Dan Nelson wrote:
In the last episode (Dec 10), Dan Mahoney, System Admin said:
I'm noticing that when following the directions given here:
http://www.freebsd.org/doc/en/books/handbook/network-nis.html
For how to disable logins, the recommended action is to set the shell to
/sbin/nologin.
However, this is sloppy as it allows the user to log in, get the
motd, do everything short of getting a shell.
I've tried starring out the password in the +::::::::: entry, (and
putting in a "bad" password, like x), and those don't seem to
work. I am still able to connect via sshd and prove that the
account works.
By default, the passwd field is ignored in an NIS + or - line. It
looks like if you rebuild libc with PW_OVERRIDE_PASSWD=1, you will
get the behaviour you're looking for (see the compat_set_template
function in src/lib/libc/gen/getpwent.c).
Okay, let's look at it from an alternate tack then -- what else renders an
account invalid?
Is there a pam knob to check /etc/shells? Or an sshd option?
There's a pam_exec module which launches a program of your choice. You
could look up the user's shell from there using whatever script you're
comfortable with. Or, if all your NIS users are members of a certain
group, you could use the pam_group module to deny them.
I found these:
http://osdir.com/ml/linux.admin.managers/2003-08/msg00016.html
for a user who had a similar problem, but freebsd doesn't appear to have
the requisite module. This could also be implemented as an option to
pam_unix (which could check either /etc/shells or the NIS equivalent,
since it already has the NIS hooks.)
It looks like our pam_unix module has a "local_pass" option, whch
claims to disallow NIS logins. Have you tried that?
No, I'm using netgroups -- i.e. allow one user (or, rather, allow the
@STAFF group, import the whole map, disallow the rest from logging in.)
Actually, I just found the answer to this...instead of putting "nologin"
in, put in something bogus (I'm using /nonexistent)...and the password
will just loop.
This is something sshd does internally.
Given, there's several solutions to this:
1) The Kluge as above.
2) A pam module to check /etc/group (this is standard login behavior, and
historically supported, and available on other platforms, adding a module,
even to ports, is trivial.
3) A patch to openssh to do /etc/shells checking (I'll note that openSSH
has the "UseLogin" option, which may also do this.
4) An option to pam_unix to check this. Differs from #2 in that it's a
change to an existing module instead of one in ports.
-Dan
--
"The first annual 5th of July party...have you been invited?"
"It's a Jack Party."
"Okay, so Long Island's been invited."
--Cali and Gushi, 6/23/02
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
