passwordless authentication for Solaris 9 native ldap client
I have a directory server 6 and a solaris 9 native ldap client all set up. They both are solaris 9 systems. Right now I want to configure the ldap client to be able to do passwordless authentication. As a test, I create a authorized_keys file in /home/testuser/.ssh directory, ensure that all the permissions are right. But when I try to ssh on that host, I still got prompted for password. For example,
bash-2.05$ ssh ldapc hostname
testuser@ldapc's password:
bash-2.05$ cd /home/testuser/.ssh
bash-2.05$ ls -l
total 8
-rwx1 testuser staff444 May 15 09:40 authorized_keys
-rw-1 testuser staff887 May 15 09:26 id_rsa
-rw-r--r--1 testuser staff223 May 15 09:26 id_rsa.pub
-rw-r--r--1 testuser staff688 May 15 09:39 known_hosts
I am using the same host for testing passwordless ssh, i.e., the public key is stored in authorized_keys file, while the private key is in id_rsa. It can work if the account is managed by passwd/shadow, but does not work with LDAP.
Since I am using sun ssh, which is "SSH Version Sun_SSH_1.0, protocol versions 1.5/2.0.", there is no 'UsePAM yes' option in /etc/ssh/sshd-config file. How do I configure to use passwordless authentication for ssh with LDAP?
Thanks,
--xinhuan
[1290 byte] By [
CBDa] at [2007-11-27 4:27:18]
# 1
(Sorry, this is 75% SSH and 25% LDAP so it's a bit off topic)
I assume that you're using the Solaris 9 supplied Secure SSH and not added-on version of OpenSSH (which the Sun implementation is derived from) or the commercial version from ssh.com. But the Sun SSH and OpenSSH are almost identical if compiled & configured with similar options.
It's NOT ldapclient that is providing you with "passwordless" authentication (you really would not want that). It's the authorized_keys (user public/private keys) feature of sshd. By the time you're handling the authorized_keys file nsswitch and that usage of the ldapclient have done their job.I think there are still opportunities for PAM and it's usage of ldapclient to kick in but I don't know the exact sequencing. But authorized_keys handling is done within sshd, not PAM.
-> One thing which is often missed with authorized keys is that no part of the path from the root to the authorized_keys file may be writable by anyone other than root or the user being logged in as. That includes: '/', '/home/', '/home/testuser/', '/home/testuser/.ssh/' and '/home/testuser/.ssh/authorized_keys'. Since it won't tell the client of a potential security hole this becomes a common but difficult one to find. If you can track down where your sshd logs go that can be a help.
-> Next, I notice that although you're using the same host for testing the authorized_keys file your authorized_keys and id_rsa.pub are different sizes. This is fine under normal circumstances, but the easiest way to test a specific key is to copy that ida_rsa.pub file to be authorized_keys for testing. Is this because you've added another key, placed options in front of the key, or used a different public key format?
-> You're logging in from testuser@ldapc to testuser@ldapc? But this doesn't work when using passwd: files ldap (& shadow)? When you're using ldapclient are you able to login to testuser on ldapc? Does a "getent passwd testuser" display the same results when using files or ldap?
Lastly, I strongly encourage you to learn about the ssh-agent and Pagent (for PuTTY users), then about agent forwarding. Using that you can protect your private key with a strong passphrase but still only have to enter your passhrase once a day. But that's going pretty far afield from this forum
*** A Private Key without a good passphrase is dangerous -- VERY dangerous if left on a network drive or unsecure system ***
# 2
> I assume that you're using the Solaris 9 supplied
> Secure SSH and not added-on version of OpenSSH
Yes.
>
> It's NOT ldapclient that is providing you with
> "passwordless" authentication (you really would not
> want that). It's the authorized_keys (user
> public/private keys) feature of sshd. By the time
> you're handling the authorized_keys file nsswitch and
> that usage of the ldapclient have done their job.I
> think there are still opportunities for PAM and it's
> usage of ldapclient to kick in but I don't know the
> exact sequencing. But authorized_keys handling is
> done within sshd, not PAM.
>
PAM plays a role in authentication, right? Some forum said when using LDAP for passwordless authentication, you have to set 'UsePAM yes', but that's for openssh. Sun ssh has no such an option.
> -> One thing which is often missed with authorized
> keys is that no part of the path from the root to the
> authorized_keys file may be writable by anyone other
> than root or the user being logged in as. That
> includes: '/', '/home/', '/home/testuser/',
> '/home/testuser/.ssh/' and
> '/home/testuser/.ssh/authorized_keys'. Since it
> won't tell the client of a potential security hole
> this becomes a common but difficult one to find. If
> you can track down where your sshd logs go that can
> be a help.
I tracked down all the permissions, they all look fine. Also, same permissions setup on another host which is using files and sshd passwordless is working.
>
> -> Next, I notice that although you're using the same
> host for testing the authorized_keys file your
> authorized_keys and id_rsa.pub are different sizes.
> This is fine under normal circumstances, but the
> easiest way to test a specific key is to copy that
> ida_rsa.pub file to be authorized_keys for testing.
> Is this because you've added another key, placed
> options in front of the key, or used a different
> public key format?
>
authorized_keys file contains another host public key, as well as the ldapc public key for user testuser.
> -> You're logging in from testuser@ldapc to
> testuser@ldapc? But this doesn't work when using
> passwd: files ldap (& shadow)? When you're using
> ldapclient are you able to login to testuser on
> ldapc? Does a "getent passwd testuser" display the
> same results when using files or ldap?
>
Yes, 'getent passwd testuser' is working. testuser can login to ldapclient
--xinhuan
CBDa at 2007-7-12 9:35:54 >
# 3
Yes, PAM is used for authentication, but the program calling PAM (sshd in this case) can make it's own additional decisions before or after calling PAM. This is the case for authorized_keys in Solaris 9. I think the Sun SSH always checks PAM (I haven't see any documentation which contradicts that).
I don't have a easy answer at this point. The next steps I would follow are:
(1) Try running ssh with the "-v" option. That produces loads of debugging output revealing alot about the protocol and exposing many issues. However, many server side issues which could expose security holes won't show up here. Here's what a successful private key login looked like from OpenSSH (cleansed a bit where upper case):
debug1: Next authentication method: publickey
debug1: Trying private key: /HOMEDIR/.ssh/identity
debug1: Offering public key: /HOMEDIR/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/HOMEDIR/.ssh/id_rsa':
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
(2) You can enable debugging on the sshd side. Check the /etc/ssh/sshd_config for:
SyslogFacility auth
LogLevel info
Try LogLevel verbose, or if that doesn't work try debug (but be aware that diag may expose private information according to the man page). Don't forget to kill -HUP sshd's pid to get it to reread the configuration file.
You may need to update /etc/syslog.conf to catch auth.debug messages (in a file only readable by root). Make sure any files you specific exist and then you'll need to kill -HUP syslogd too. Don't forget to turn everything back to normal when you're done.
Between all of that information it may help you isolate the problem.
# 4
According to sun doc, if the account is authenticated by LDAP, users must supply their password when doing ssh.
Note ?After you enable pam_ldap account management, all users must provide a password any time they log in to the system. A login password is required for authentication. Therefore, nonpassword-based logins using tools such as rsh,rlogin, or ssh will fail.
My question is: Does it mean that 'ssh passwordless authentication using public/private key' won't work if the user account is authenticated by LDAP?
Thanks,
--xinhuan
xhza at 2007-7-12 9:35:54 >
# 5
While I had not been thinking about the LDAP bind, I did some research and discovered that this has apparently already been identified as a bug, fixed, and patched (which I have not tested myself yet).
You need to be running at DS 5.2 pl4 (I would hope that pl5 also works).
The main bugid is: 4909247 (more details in 6338769). This is now fixed.
However there is a separate Bug ID (6365986) on the documentation, which doesn't say it's fixed.
Here are the patches:
Solaris 8, SPARC: 108993 (libc patch), -67 is current, -54 might be fixed
Solaris 8, x86: 108994 (libc patch), -67 is current, -54 might be fixed
Solaris 9, SPARC: 112960 (ldap library patch), -49 is current, -36 might be fixed
Solaris 9, x86: 114242 (ldap library patch), -35 is current, -23 might be fixed
Solaris 10, SPARC: 118833 (kernel patch), -36 is current and rolls up 120036-07,
Originally fixed in libldap patch 120036-04
Soalris 10, x86:120037 (libldap patch), -13 is current, -04 might be fixed
These forum discussions were at least somewhat relevant:
http://www.opensolaris.org/jive/thread.jspa?threadID=614&tstart=0
https://www.opensolaris.org/jive/thread.jspa?messageID=15536
# 6
I have the most recent patch installed on the LDAP client side (112960-49). I tested out ssh without password from solaris LDAP client to linux LDAP client. That works!!!. But the ssh from linux LDAP client to solaris LDAP client does NOT!. The Linux client I am using is Fedora Core 5. Solaris and Linux they both use the Directory Server 6 as LDAP server.
Anyway, thanks for your information.
--xinhuan
xhza at 2007-7-12 9:35:54 >
# 7
Some checklists, no sure if they would help:
- $HOME, in your case /home/testuser, should NOT be mode 775, should be 755 or lesser, same for $HOME/.ssh.
- If the SUN SSH is using SSH protocol 2 only (check sshd_config), add the public key to authorized_keys2.
- Make sure the loginShell (in LDAP) points to an valid file, eg: loginShell in LDAP is /bin/bash but does not exist, then there may be a need to add a symbolic link /bin/bash pointing to the existing BASH.
- In older version (pre-3.6.1) of OpenSSH Server (may SUN SSH is 3.6.1 or older), instead of 揢sePAM yes? the parameter is:
PAMAuthenticationViaKbdInt yes
- You should have these objectClasses in user LDAP entry:
objectClass: posixAccount
objectClass: shadowAccount
Gary
