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;








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









share|improve this question
























  • 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 1 '14 at 8:38

















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









share|improve this question
























  • 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 1 '14 at 8:38













1












1








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









share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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 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






  • 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 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










2 Answers
2






active

oldest

votes


















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






share|improve this answer
































    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"






    share|improve this answer























    • 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











    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
    );



    );













    draft saved

    draft discarded


















    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









    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






    share|improve this answer





























      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






      share|improve this answer



























        2












        2








        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






        share|improve this answer















        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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Sep 1 '14 at 8:42

























        answered Sep 1 '14 at 8:27









        dtechdtech

        3961524




        3961524























            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"






            share|improve this answer























            • 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















            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"






            share|improve this answer























            • 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













            0












            0








            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"






            share|improve this answer













            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"







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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

















            • 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

















            draft saved

            draft discarded
















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            How to write a 12-bar blues melodyI-IV-V blues progressionHow to play the bridges in a standard blues progressionHow does Gdim7 fit in C# minor?question on a certain chord progressionMusicology of Melody12 bar blues, spread rhythm: alternative to 6th chord to avoid finger stretchChord progressions/ Root key/ MelodiesHow to put chords (POP-EDM) under a given lead vocal melody (starting from a good knowledge in music theory)Are there “rules” for improvising with the minor pentatonic scale over 12-bar shuffle?Confusion about blues scale and chords

            What if the end-user didn't have the required library?What is setup.py?What is a clean, pythonic way to have multiple constructors in Python?What does Ruby have that Python doesn't, and vice versa?What is the reason for having '//' in Python?How do I create a namespace package in Python?How to package shared objects that python modules depend on?setuptools vs. distutils: why is distutils still a thing?Navigation in Windows 10 vs code not going to virtualenv library when the same library is installed at user levelPython create package for local usePackaging a project that uses multiple python versionsWhy is permission denied on pip install except for when “--user” is included at end of command?

            Esgonzo ibérico Índice Descrición Distribución Hábitat Ameazas Notas Véxase tamén "Acerca dos nomes dos anfibios e réptiles galegos""Chalcides bedriagai"Chalcides bedriagai en Carrascal, L. M. Salvador, A. (Eds). Enciclopedia virtual de los vertebrados españoles. Museo Nacional de Ciencias Naturales, Madrid. España.Fotos