On Thu, 2003-02-06 at 08:59, sentinel wrote: > > > You're probably not. PAM is always used to authenticate passwords, > > IIRC. > > Even through SSH?
I was referring specifically to SSH. I don't believe that sshd, when compiled with PAM support, will ever authenticate passwords without PAM. If you don't believe me, try searching for /etc/passwd or /etc/shadow in /usr/sbin/sshd. They're not there. > It wasn't working until I enabled > PAMAuthenticationViaKbdInt. I thought it started working when you added the users' home dir (or pam_mkhomedir). Are you sure about that fix? > The default is off and the man page for sshd > mentions it "specifies whether PAM challenge response authentication is > allowed. This allows the use of most PAM challenge response authentication > modules..." Yeah, challenge/response is not the same as password authentication. > > A quick search suggests that this is probably due to SSH's new privilege > > separation. You may be able to work around the problem by turning off > > privilege separation in sshd_config. > > Problem is I'm requiring it for security reasons. Tough call. 777 to /home > or no priv seperation. I think I'll check out the PAM modules code and see > if there is a work around. I don't know. Are the home directories that are created when you set /home to 777 owned by the correct user, or by sshd? > >> I wonder if setting a bind user/password would resolve the problem. > >> Currently I connect anonymously to the LDAP server (for testing purposes > only) > > > Binding anonymously will be slightly faster/less overhead and probably > more secure. > > More secure? As I understand it, binding anonymously gives the world the > right to query my LDAP server. Binding with a proxyuser/password restricts > who can query the system. I'm not sure I understand. By default, anyone in the world can connect to the LDAP server and read data that's not private. There's nothing insecure about that (except for the binding part, but you should be filtering these connections at your edge firewall). Restricting reads of non-private data to a specific user: * increases the maintenance overhead of the LDAP service. All systems have to be set up with the username/password * complicates your ACI's needlessly * adds overhead to the system, since every connection has to authenticate in addition to the normal bind/search operations. * stores the username/password in plain text on every machine you configure as an LDAP client * sends the username/password over the network, usually in plain text The last two are where anonymous access is actually more secure than forcing authentication for any read access. The data that's readable is not sensitive, so avoiding management logins just means that there's less privilege that's likely to be escalated. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
