How to block NIS logins via ssh?
Dan Mahoney, System Admin
danm at prime.gushi.org
Wed Dec 10 23:10:25 PST 2008
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:
>>>> For how to disable logins, the recommended action is to set the shell to
>>>> 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:
>> 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.
"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
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
More information about the freebsd-questions