How to block NIS logins via ssh?

[Dan Nelson]

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?
 
> I'll make a separate post to -hackers requesting this.
> 
> it's probably pretty trivial to port, but I'm leery to do so
> not-being a c-coder.

-- 
	Dan Nelson
	dnelson at allantgroup.com