The SmartOS LDAP client is up and running and is communicating with the FreeIPA directory server, but ssh doesn't seem to take into account the public keys that are stored in the directory server.

In order to facilitate this, you have to make sure that the ssh daemon is able to obtain these keys from the directory server. In comparison, the two lines of importance in the /etc/ssh/sshd_config file on a CentOS FreeIPA client installation are:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

The AuthorizedKeysCommand parameter refers to the command that obtains the public keys from the directory server. Unfortunately there is no equivalent binary on SmartOS because it lacks the sssd software on the client side.

Luckily, it is not much of an issue because it is rather easy for an LDAP client to obtain this information from the directory server. While there are certainly a variety of solutions available on the Internet, at first sight I found them often too sophisticated for what I needed. So, I decided to limit the solution to a bash script file that encapsulates a ldapsearch command which will fetch the public keys from the directory server.

These few lines here below are enough to fetch the keys and to make sed print only the information needed: the user's public keys.


/opt/local/bin/ldapsearch -LLL -x -u \
-o ldif-wrap=no \
-h \
-D "uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com" \
-w "strongPassword" \
-b "dc=example,dc=com" \
'(&(objectClass=posixAccount)(uid='"$1"'))' \
ipaSshPubKey | sed -n 's/^[ \t]*ipaSshPubKey:[ \t]*\(.*\)/\1/p'

We use the uid=solaris,cn=sysaccounts,cn=etc account with the strongPassword (literally) to avoid that we have to expose any user account's credentials in the script file.

This script takes one argument, which is the "user" who makes the ssh login. As we will see later on, the sshd_config file allows to refer to the user via %u. Make sure the script has the execution bits set and give it a try with a user name defined in the directory server. This command should list the public keys of user1:

/opt/local/bin/  user1

Once the script provides the public keys as expected, we can integrate it in the sshd_config file. Find the line with AuthorizedKeysCommand or add following lines to /etc/ssh/sshd_config:

AuthorizedKeysCommand /opt/local/bin/  %u
AuthorizedKeysCommandUser nobody

To take this configuration change into account we have to restart the ssh daemon with the command:

sudo svcadm restart ssh

While making the first connection attempts via ssh, it might be valuable to keep an eye on the log file on the ssh target system for more information in case of connection failures.

sudo tail -f /var/log/authlog

Make sure the user has its home directory available on the target system. That's all it takes to ssh login without password and without any local ~/.ssh/authorized_keys file.

Beware, locally provided public keys in ~/.ssh/authorized_keys will still allow the user to ssh-login. This procedure is facilitating ssh-login based on public keys stored in the directory server, but it is not limiting access to these public keys. Other sshd_config changes are needed to enforce this.