NIS users suddenly can't login to SSHssh via public key authentication for users administered with NISBasic NIS questionsPasswordless ssh with NFS+NISNIS user not being added to NIS groupHow to have logs about users logins/logouts in a NIS server?One of my NIS users can't login - why?NIS netgroup map empty for nis clientNIS - Proper Format for Multiple Hostsnobody user/group with NIS/NFSShare NIS login using Active Directory
Does knowing the surface area of all faces uniquely determine a tetrahedron?
How useful is the GRE Exam?
Got a new frameset, don't know why I need this split ring collar?
I have found ports on my Samsung smart tv running a display service. What can I do with it?
Common Marsupials and Rare Antelopes
Why was New Asgard established at this place?
How can I detect if I'm in a subshell?
How to write a nice frame challenge?
Root User Cannot Reset Another Users Password
How to avoid offending original culture when making conculture inspired from original
Print the new site header
How did the European Union reach the figure of 3% as a maximum allowed deficit?
Should I email my professor to clear up a (possibly very irrelevant) awkward misunderstanding?
Who was the youngest Executive Producer?
How to prevent cables getting intertwined
How much steel armor can you wear and still be able to swim?
How "fast" do astronomical events occur?
Is swap gate equivalent to just exchanging the wire of the two qubits?
What is this plant I saw for sale at a Romanian farmer's market?
Does anyone recognize these rockets, and their location?
Does cooling a potato change the nature of its carbohydrates?
Is it a bad idea to have a pen name with only an initial for a surname?
Using roof rails to set up hammock
I'm yearning in grey
NIS users suddenly can't login to SSH
ssh via public key authentication for users administered with NISBasic NIS questionsPasswordless ssh with NFS+NISNIS user not being added to NIS groupHow to have logs about users logins/logouts in a NIS server?One of my NIS users can't login - why?NIS netgroup map empty for nis clientNIS - Proper Format for Multiple Hostsnobody user/group with NIS/NFSShare NIS login using Active Directory
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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
nis
|
show 2 more comments
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
nis
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 runypcaton thepasswd.bynameandpasswd.byuidmaps. 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 ayptestcommand, 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 1 '14 at 8:38
|
show 2 more comments
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
nis
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
nis
nis
edited Sep 10 '14 at 7:25
dtech
asked Aug 31 '14 at 15:26
dtechdtech
3961524
3961524
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 runypcaton thepasswd.bynameandpasswd.byuidmaps. 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 ayptestcommand, 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 1 '14 at 8:38
|
show 2 more comments
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 runypcaton thepasswd.bynameandpasswd.byuidmaps. 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 ayptestcommand, 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 1 '14 at 8:38
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
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
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
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
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
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
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 1 '14 at 8:38
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 1 '14 at 8:38
|
show 2 more comments
2 Answers
2
active
oldest
votes
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
add a comment |
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"
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 at 18:43
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f625326%2fnis-users-suddenly-cant-login-to-ssh%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
add a comment |
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
add a comment |
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
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
edited Sep 1 '14 at 8:42
answered Sep 1 '14 at 8:27
dtechdtech
3961524
3961524
add a comment |
add a comment |
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"
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 at 18:43
add a comment |
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"
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 at 18:43
add a comment |
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"
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"
answered May 31 at 18:40
BonaparteBonaparte
1112
1112
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 at 18:43
add a comment |
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 at 18:43
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 at 18:43
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 at 18:43
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f625326%2fnis-users-suddenly-cant-login-to-ssh%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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
ypcaton thepasswd.bynameandpasswd.byuidmaps. 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
yptestcommand, 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 1 '14 at 8:38