Description of problem: NIS users cannot log in via ssh. Version-Release number of selected component (if applicable): openssh-3.5p1-6 How reproducible: Always. Steps to Reproduce: 1. Set up NIS. 2. Log in successfully on console. 3. Attempt to log in via ssh -v. Actual results: debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is publickey debug1: userauth_pubkey_agent: testing agent key /home/devel/rth/.ssh/id_dsa debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: try privkey: /home/rth/.ssh/id_rsa debug1: try pubkey: /home/rth/.ssh/id_dsa debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is keyboard-interactive debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is password rth@frothingslosh's password: In /var/log/secure: Feb 18 13:11:47 frothingslosh sshd[2462]: Illegal user rth from 172.16.50.18
What are the contents of the user's passwd (and shadow, if defined) entries in NIS?
[frothingslosh:~] ypcat passwd | grep '^rth:' rth:*K*:2509:2515:Richard Henderson,Engineering,1-408-542-9670:/home/devel/rth:/bin/bash There is no yp shadow map.
After you enabled NIS, was sshd restarted so that it would re-read /etc/nsswitch.conf?
I thought I'd rebooted since then, but apparently not. Perhaps authconfig should be modified to take care of this?
I'm not sure I understand the question. While authconfig starts or stops ypbind and nscd as appropriate, it can't possibly know which currently-running daemons have read /etc/nsswitch.conf since they were first started (and which therefore need to be restarted), and how to restart them.
Clearly a wontfix.