SUMMARY: disabling server access

From: Labor. of Medical Physics WU (
Date: Wed Dec 07 1994 - 22:56:52 CST


This was the problem:

> This may be a standard question but...
> I have a SS5 server + 16 clasics as clients, all running Solaris 2.3,
> i am running nis+. I want to disable network logins for most of the users
> (but not ALL of them) on the serwer. The obvious answer is to
> check uids in the /etc/login (or whatever) system-wide script and
> logout unwanted users. This seems rather ugly, any other ideas ?
> Please send e-mail to: thank you

Following people contributed:
        Lenny Turetsky <>
        Dave Fetrow <> (Carl Hughey)
        Christian Gresser <>
        C.M. Fung <>
        Pamela Pledger <>
        Bill Maggio <>
        james mularadelis <>
        Ashish Desai <>
        Pom Bajar <>
        Richard Pieri <>
        Tom Mornini <>
        Robert Tag (

Great thanks to all of you !

the following solutions were proposed:

1) duplicate nis+ accounts in passwd/shadow files and provide /bin/false
(or a special script) shell to users we don't want on the server

Carl Hughey writes:
> In the passwd file you can change their shell from "/bin/csh" to
> "/bin/false" or a homegrown message script. Unfortunately this breaks
> ftp access as well since it wants to see a standard shell.
> If ftp's not a problem though, when the user tries to login, they'll be
> immediately logged off. I've used my own programs in the past to display
> some message like "This account has been disabled. Contact your
> system administrator..." then bump them off.

The disadvantages of this were summarized by Christian Gresser :
> - you need a different passwd-file on the server and the clients
> (perhaps don't use NIS+ on the server)
> - this disables all logins, not only network logins

2) split up the nis+ domains: nice, but a lot of work and sometimes
i want the server in the same domain !

3) make the server use only passwd & shadow files (not nis+) for passwords
 - has the disadvantage of maintaining separate accounts for
  the admins and priviliged people.

4) take away the execute permisions from the shells,
james mularadelis <> writes:
> YOu could take away permissions to the shells,
> /bin/csh or in our case /opt/bin/tcsh and give it to only root and a
> group called say servgroup and this group will have permissions on it
> also. But nobody else will.. Put the people you want ot log into your
> server in this group.

5) This solution is the best in my opinion:
Lenny Turetsky writes:

> 1) create a netgroup containing the users who *can* login to the server
> 2) put the following in the server's /etc/passwd:
> +@netgroup
> +::::::/usr/local/bin/not_here_sh
> What this does is over-ride the shells of all users (other than those in
> the netgroup) with /usr/local/bin/not_here_sh, which should be a
> program/shell script that tells the user that he can't login on this
> machine, and (optionally) makes a record of the attempt a/o e-mails the
> sysadmin about it (please note that if you go the e-mail route, you have
> to watch out for user's who have ~/.mailrc files -- that little gotcha
> had me stumped for hours!).

I tried 5) and discovered that i have to change the nsswitch.conf file
passwd entry from the standard:
        passwd: files nisplus
        passwd: compat
        passwd_compat: nisplus
in order for the '+' mechanism to work properly

 - don't forget to update the `netgroup' nis+ map :-)
 - this also breaks ftp access, but in my case that doesn't matter.

Finaly, there was an idea of using .rhosts file but: 1) this would solve
only rlogin problems 2) if .rhosts verification fails, rlogin
(unlike rsh and rcp !) uses standard prompting
for user's password, so I don't see an easy way of doing it in this


I would like to thank WU Labor. of Med. Phys. for providing me
with access to netnews.

Grzegorz Blinowski +
Institute of Computer Science ---------------+
Warsaw University of Technology ---------------------+
Nowowiejska 15/19, 00-665 Warsaw, POLAND --------------------------+

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:16 CDT