1

I've recently added a new (client) server to my NIS. For a month or so this worked fine, but since today I suddenly can't login through SSH anymore. Some other services (e.g. IMAP) on the same server work fine. The other NIS client seems to work fine.

The SSH session is terminated immediately after successful login:

some.nis.user@nismaster:~$ ssh faultyserv
some.nis.usern@faultyserv's password:
Connection to faultyserv closed by remote host.
Connection to faultyserv closed.

/etc/log/auth.log contains:

Aug 31 12:42:22 faultyserv sshd[27909]: pam_unix(sshd:session): session opened for user some.nis.user by (uid=0)
Aug 31 12:42:22 faultyserv sshd[27909]: fatal: login_get_lastlog: Cannot find account for uid 1234

If I set UseLogin yes in /etc/ssh/sshd_config I can login, but get a weird shell:

I have no name!@faultyserv:~$ pwd
/home/s/some.nis.user
I have no name!@faultyserv:~$ sudo echo
sudo: unknown uid 1234: who are you?
I have no name!@faultyserv:~$ id some.nis.user
uid=1234 gid=1975(some.nis.user) groups=4294967295,2177(somegroup),/*snip a long grouplist*/

I think there is something wrong with the NIS, but have no idea how to fix this, does anyone have an idea?

My /etc/nsswitch.conf contains (among more entries without nis):

passwd:         files nis
group:          files nis
shadow:         files nis
netgroup:       nis
dtech
  • 633
  • When I started learning *nix in 1997 (and IMAP didn't exist), NIS was more visible, but clearly it was then an obsolete system on it's way out. As such I put no effort into it, so I can't answer your question except to say that maybe you should look at alternatives? – mc0e Aug 31 '14 at 15:55
  • 1
    The only real alternative is LDAP, which is more advanced, but also more complicated. However it is irrelevant to the question. – dtech Aug 31 '14 at 17:23
  • 2
    Your first port of call should be to run ypcat on the passwd.byname and passwd.byuid maps. If either of them fails, or if they contain incorrect or inconsistent data, then you have a place to start debugging. – aecolley Aug 31 '14 at 21:58
  • If you have a yptest command, use it. – aecolley Aug 31 '14 at 22:08
  • NIS is still very useful under the right conditions. It persists because when correctly set up, it generally just works. LDAP is nearly-criminally tetchy. – MadHatter Sep 01 '14 at 08:38
  • @aecolley Thanks, that showed me that the passwd.byuid map only contained users local to faultyserv, leading me to the solution posted below. – dtech Sep 01 '14 at 08:41
  • LDAP is the usual recommendation. I haven't gone down this route, but I've seen freeipa/kerberos recommended. – mc0e Sep 01 '14 at 11:10

2 Answers2

2

The problem was that the passwd.byuid map wasn't transferred.

Running yppush passwd.byuid on nismaster gave a timeout error and generated the following in faultyserv's /var/log/syslog:

Sep  1 09:51:37 faultyserv ypserv[2038]: refuse to transfer passwd.byuid from <ip>, master is faultyserv.mydomain.com)

The slave server had the incorrect master server specified:

# ypwhich -m
services.byservicename nismaster
group.bygid nismaster
group.byname nismaster
protocols.bynumber nismaster
services.byname nismaster
hosts.byname nismaster
netgroup.byhost nismaster
rpc.bynumber nismaster
passwd.byuid faultyserv.mydomain.com
netgroup nismaster
ypservers nismaster
shadow.byname faultyserv.mydomain.com
passwd.byname nismaster
hosts.byaddr nismaster
protocols.byname nismaster
rpc.byname nismaster
netgroup.byuser nismaster
netid.byname faultyserv.mydomain.com

Re-running /usr/lib/yp/ypinit -s nismaster on faultyserv fixed the problem

dtech
  • 633
0

This can sometimes happen on Debian systems because of the use of 

# shadowconfig on

Which puts sensitive password hashes in the shadow files and rewrites the passwd and group file with identical bland 'x' entries.

Before you rebuild the passwd and group files, you must do this on the NIS master

# shadowconfig off

On Debian that is

# cd /var/lib/yp
# make all

Don't forget the special entries you have to add to passwd and group on the clients, here is the passwd entry, (after the postgres one).

postgres:x:115:124:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
+::::::

Here is the group one, after the sambashare.

sambashare:x:125:
+:::

As well as the /etc/nsswitch.conf mentions for "nis"

Bonaparte
  • 121
  • The password hashes will be distributed around your network with NIS. This is known to be insecure. For small clusters on a single physically secure site, this might not be an issue.

    Distributed across multiple sites, I would recommend you take on LDAP because there is a PAM LDAP module.

     – Bonaparte May 31 '19 at 18:43