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

--------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
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to