Hi Stefan,
Thank you for your response.
I created similar system accounts that you have:
*"uid=solaris,cn=sysaccounts,cn=etc,dc=grcph,dc=local"*
Running both simplified commands return outputs:
*# ldapsearch -LLL -x -h ipatest.grcph.local -D
"uid=solaris,cn=sysaccounts,cn=etc,dc=grcph,dc=local" -w strongPassword -b
'dc=grcph,dc=local' 'objectclass=*' | grep -i sshpubkey*
*ipaSshPubKey: ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIHv6vdDkzl+JF2YY3qQvXTU9yxuV*
*ipaSshPubKey: ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy*
*ipaSshPubKey: ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCiQYhNu8UrZcpAlA6jUMwWljzu*
*ipaSshPubKey: ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAICaMtq18PA0jUzHQVZYUgmdgZR0N*
*ipaSshPubKey: ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCnAFVVbhcVj3kaHDLOdn3zWFxU*
*ipaSshPubKey: ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy*
*ipaSshPubKey: ssh-dss
AAAAB3NzaC1kc3MAAACBAOHvtRgHcvflvYXie/P2wVYb00ZCKB6OJhxD*
*ipaSshPubKey: ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEA7OD3d6rz9INmxscYGvk81dk8/x9T*
*# ldapsearch -LLL -x -h **ipatest**.grcph.local -D
"uid=admin,cn=users,cn=accounts,dc=grcph,dc=local" -w strongPassword -b
'dc=grcph,dc=local' 'objectclass=*' | grep -i sshpubkey*
*ipaSshPubKey: ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAIHv6vdDkzl+JF2YY3qQvXTU9yxuV*
*ipaSshPubKey: ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy*
*ipaSshPubKey: ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCiQYhNu8UrZcpAlA6jUMwWljzu*
*ipaPermDefaultAttr: ipasshpubkey*
*ipaPermDefaultAttr: ipasshpubkey*
*ipaPermDefaultAttr: ipasshpubkey*
*ipaPermDefaultAttr: ipasshpubkey*
*ipaPermDefaultAttr: ipasshpubkey*
*ipaSshPubKey: ssh-ed25519
AAAAC3NzaC1lZDI1NTE5AAAAICaMtq18PA0jUzHQVZYUgmdgZR0N*
*ipaSshPubKey: ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCnAFVVbhcVj3kaHDLOdn3zWFxU*
*ipaSshPubKey: ecdsa-sha2-nistp256
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAy*
*ipaSshPubKey: ssh-dss
AAAAB3NzaC1kc3MAAACBAOHvtRgHcvflvYXie/P2wVYb00ZCKB6OJhxD*
*ipaSshPubKey: ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEA7OD3d6rz9INmxscYGvk81dk8/x9T*
I tried to use *uid=admin,cn=users,cn=accounts,dc=grcph,dc=local* on the
script that you provide but still the same, no output:
[image: Inline image 1]
[image: Inline image 2]
Also tried to use *uid=solaris,cn=sysaccounts,cn=etc,dc=grcph,dc=local *but
same output:
*[image: Inline image 3]*
*[image: Inline image 4]*
*ldapclient list* output on my side:
*# ldapclient list*
*NS_LDAP_FILE_VERSION= 2.0*
*NS_LDAP_BINDDN= uid=solaris,cn=sysaccounts,cn=etc,dc=grcph,dc=local*
*NS_LDAP_BINDPASSWD= {NS1}c589488685b73567a5a52ca1bd18*
*NS_LDAP_SERVERS= ipatest.grcph.local*
*NS_LDAP_SEARCH_BASEDN= dc=grcph,dc=local*
*NS_LDAP_AUTH= none*
*NS_LDAP_SEARCH_REF= TRUE*
*NS_LDAP_SEARCH_TIME= 15*
*NS_LDAP_PROFILE= default*
*NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=grcph,dc=local*
*NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=grcph,dc=local*
*NS_LDAP_BIND_TIME= 5*
*NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount*
I'm thinking in script if need to adjust the ff:
*'(&(objectclass=posixAccount)(uid='"$1"'))' \*
*ipaSshPubKey | sed -n 's/^[ \t]*ipaSshPubKey:[ \t]*\(.*\)/\1/p'*
Since running the simplified commands got return output.
Thanks and Regards,
Joven D.
On Sun, Nov 5, 2017 at 5:26 AM, Stefan Eestermans <[email protected]> wrote:
> Hello Joven,
>
> Does the admin account effectively exist under
> cn=sysaccounts,cn=etc,dc=grcph,dc=local"
> ?
>
> I think you should either use:
> (admin under cn=users,cn=accounts)
>
> -D "uid=admin,cn=users,cn=accounts,dc=grcph,dc=local" \
> -w "password" \
>
> where "password" has to be your FreeIPA admin password
>
> OR:
>
> -D "uid=solaris,cn=sysaccounts,cn=etc,dc=grcph,dc=local" \
> -w "strongPassword" \
>
>
> According to your modifications, I believe the script should be:
>
> ::::::::::::::
> /opt/local/bin/ssh-ldap-pubkey-wrapper.sh
> ::::::::::::::
> #!/bin/bash
>
> /opt/local/bin/ldapsearch -LLL -x -u \
> -o ldif-wrap=no \
> -h ipatest.grcph.local \
> -D "uid=solaris,cn=sysaccounts,cn=etc,dc=grcph,dc=local" \
> -w "strongPassword" \
> -b "dc=grcph,dc=local" \
> '(&(objectClass=posixAccount)(uid='"$1"'))' \
> ipaSshPubKey | sed -n 's/^[ \t]*ipaSshPubKey:[ \t]*\(.*\)/\1/p'
>
>
> You could try these simplified commands, to see if you get any output:
>
> /opt/local/bin/
>
> ldapsearch -LLL -x -h ipatest.grcph.local -D
> "uid=solaris,cn=sysaccounts,cn=etc,dc=grcph,dc=local" -w strongPassword -b
> 'dc=grcph,dc=local' 'objectclass=*'
> /opt/local/bin/
>
> ldapsearch -LLL -x -h ipatest.grcph.local -D
> "uid=admin,cn=users,cn=accounts,dc=grcph,dc=local" -w strongPassword -b
> 'dc=grcph,dc=local' 'objectclass=*'
>
> If this doesn't work for you, it would be interesting to see which error
> messages these commands return.
>
> If these commands return some output, then you could check with grep if
> there is any pubkey in there, by adding:
>
> | grep -i sshpubkey
>
> You could also compare the output of "ldapclient list" with mine here
> below:
> (I think the last line here is of great importance to get it working)
>
> [root@smbase3 ~]# ldapclient list
> NS_LDAP_FILE_VERSION= 2.0
> NS_LDAP_BINDDN= uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com
> NS_LDAP_BINDPASSWD= {NS1}c589488685b73567a5a52ca1bd18
> NS_LDAP_SERVERS= lxipa.example.com
> NS_LDAP_SEARCH_BASEDN= dc=example,dc=com
> NS_LDAP_AUTH= none
> NS_LDAP_SEARCH_REF= TRUE
> NS_LDAP_SEARCH_TIME= 15
> NS_LDAP_PROFILE= default
> NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=example,dc=com
> NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=example,dc=com
> NS_LDAP_BIND_TIME= 5
> NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount
>
> kind regards
> Stefan
>
> On 03/11/17 05:32, Joven Sabanal wrote:
>
> Hi Stefan,
>
> Thanks for this guide and I tried to do as what indicated on your guide.
> But I couldn't get it work.
>
> May I know what setup did you do on your FreeIPA server?
>
> Also, using the script that you provide:
>
>
> ::::::::::::::
> /opt/local/bin/ssh-ldap-pubkey-wrapper.sh
> ::::::::::::::
> #!/bin/bash
>
> /opt/local/bin/ldapsearch -LLL -x -u \
> -o ldif-wrap=no \
> -h ipatest.g <http://ipaserver.example.com/>rcph.local \
> -D "uid=admin,cn=sysaccounts,cn=etc,dc=grcph,dc=local" \
> -w "password" \
> -b "dc=grcph,dc=local" \
> '(&(objectClass=posixAccount)(uid='"$1"'))' \
> ipaSshPubKey | sed -n 's/^[ \t]*ipaSshPubKey:[ \t]*\(.*\)/\1/p'
>
>
> Modified it and try to run, it doesn't return any output:
>
> [image: Inline image 1]
>
>
>
> Thanks and Regards,
>
>
> Joven D.
>
>
>
> Please consider the environment before printing this email.
> ------------------------------------------------------------
> ------------------------
> Confidentiality Notice | This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential or proprietary information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, immediately contact the sender by reply e-mail and destroy all
> copies of the original message.
>
>
> On Thu, Nov 2, 2017 at 5:59 AM, Stefan Eestermans <[email protected]>
> wrote:
>
>> Hello
>>
>> I've been fighting with FreeIPA and SmartOS for while now and had this
>> sorted out. It's just that there is no sssd for SmartOS and hence it
>> doesn't work out of the box.
>>
>> Normally, it shouldn't be to hard to get it working once you have the
>> ldap client on SmartOS connected to the FreeIPA directory server. I'll
>> paste here below a recent post of my new blog (https://blog.soholabs.org),
>> dedicated to SmartOS and related technologies as a lab environment.
>>
>> So, if I understood the situation well: 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/ssh-ldap-pubkey-wrapper.sh
>> ::::::::::::::
>> #!/bin/bash
>>
>> /opt/local/bin/ldapsearch -LLL -x -u \
>> -o ldif-wrap=no \
>> -h ipaserver.example.com \
>> -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/ssh-ldap-pubkey-wrapper.sh 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/ssh-ldap-pubkey-wrapper.sh %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.
>>
>> kind regards
>>
>> Stefan
>>
>>
>> On 03/10/17 06:06, Shridhar Daithankar wrote:
>>
>>> On Monday 2 October 2017 11:57:34 AM IST Joven Sabanal wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm trying to connect SmartOS Zone VM on FreeIPA but I cannot get it
>>>> work.
>>>> I use this link as reference.
>>>>
>>>> https://www.redhat.com/archives/freeipa-users/2014-April/msg00128.html
>>>>
>>>> I follow on what's indicated on the link. I only register the Zone VM to
>>>> FreeIPA domain. I can see also that the VM is connection to the domain
>>>> by
>>>> running "ldaplist".
>>>>
>>>> Problem now is when I try to login using SSH and use the user that I
>>>> created on FreeIPA, it cannot login.
>>>>
>>>> Anyone did try the same setup as mine?
>>>>
>>>> Appreciate any advice and recommendation. Thanks in advanced.
>>>>
>>> Adding a me too here. I can join lxc containers to AD domain using
>>> sssd(realm
>>> join etc.) in a jiffy but SmartOS lx branded zones are unable to join
>>> the AD.
>>>
>>> I could threw in the hand-made kerberos authentication configuration and
>>> create the users by hand, so not much was lost. but sssd definitely
>>> didn't
>>> work and I couldn't spend much time investigating it either.
>>>
>>>
>>
>>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>
>
> *smartos-discuss* | Archives
> <https://www.listbox.com/member/archive/184463/=now>
> <https://www.listbox.com/member/archive/rss/184463/27557395-7e1f220a> |
> Modify
> <https://www.listbox.com/member/?&;>
> Your Subscription <http://www.listbox.com>
>
>
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
