OpenSSH integration - known_hosts
by Jan Zelený
Hello everyone,
there is a new effort in IPA and SSSD teams and that is SSH key integration in
both parts of SSSD-IPA infrastructure. We've put together some basic plans and
now we would like to know your opinion.
Note that this is just shortened version to make it easier to read. It doesn't
contain every bit of information about the design. For full version see
https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration
Problems:
=========
* the known_hosts file becomes outdated as machines get new host keys (e.g. re-
installed systems in virtualized environment)
* the user accepts any host key of the remote host without validating its
authenticity
Solution:
=========
Instead of checking stale known_hosts file, provide a dynamic mechanism to
lookup and deliver the public ssh key of the remote host to the client and use
it for validation of the remote host identity. The dynamic mechanism would
imply that no action is needed from the user because the source of the
retrieved key is trusted.
Limitations:
============
It is out of scope of this work to solve the problem in general. We propose a
solution for following use case:
Client host is a managed host meaning that it has SSSD installed and it is
joined an IPA domain. It also has OpenSSH patched to interact with SSSD to get
the information about the remote host
Other UNIX machines or Windows machines as SSH clients are out of the scope of
the current project. For the client hosts that can not be managed but can
access IPA via the standard LDAP tools we will provide documentation on how to
construct the content of the known_hosts file by querying LDAP server and
saving the results.
The remote host can be a managed (joined IPA domain via SSSD) or an unmanaged
host. IPA server needs to provide a way to create entries for any managed and
unmanaged hosts and store public keys for those hosts in that entries.
What would change in IPA:
=========================
* external host would have entries with the possibility of storing their
public keys
* new mechanism to work with keys through UI and CLI
* host key fingerprints would be stored in SSHFP DNS records for each host
joined in IPA domain
What would change on the client:
================================
* SSSD would fetch and cache host public keys from IPA
* joining to IPA domain would upload host public key
* ssh client would communicate with SSSD, probably through ssh-agent, to check
if the remote host is known
It is still a question whether the solution is sufficient enough to address the
needs and pains of the real deployments or other technologies outside the
proposed should be used later (or instead).
--
Thank you
Jan Zeleny
Red Hat Software Engineer
Brno, Czech Republic
12 years, 4 months
OpenSSH integration - authorized_keys
by Jan Zelený
Hello everyone,
this is a follow-up on the email on OpenSSH integration - known_host. It
describes another scenario we want to address in the process of integrating
OpenSSH to SSSD-IPA infrastructure - user public keys and their central
management. As in the previous email, we would also like to know your opinion.
Note that this is just shortened version to make it easier to read. It doesn't
contain every bit of information about the design. For full version see
https://fedorahosted.org/freeipa/wiki/SSH-FreeIPA-Integration
Problems:
=========
* how to distribute keys for new users / regenerated keys through the domain.
The authorized_keys is probably not an option, we also want to cover use case
when home directories are remote and not mounted on the server.
* user may want to log on to the remote server using different account. We need
to determine if he is allowed to impersonate that account
Solution:
=========
Similarly to openssh-lpk, the solution is to centrally manage and store user
public keys in the IPA server and deliver them to the host for validation when
user accesses that host.
In the central server provide a way to define which account can do
impersonation of which other accounts. Optionally add a way to represent
special service accounts that are not full user accounts but can be logged as
via ssh (stretch goal).
What would change on IPA:
=========================
* user entry will have additional multi-valued attribute for storing public
keys. Unlike in openssh-lpk, this attribute will store what keys the user has,
not who can impersonate him.
* user entry would also have a multi-valued attribute containg DNs of users he
can impersonate
* new mechanisms to work with account public keys and impersonation via UI and
CLI
* HBAC rules would be extended to cover impersonation
* provide an LDAP control to get a list of ssh keys that correspond to
accounts that can impersonate a particular account in one operation.
On the client side:
===================
* SSSD would fetch (and cache?) user public keys from IPA
* new SSSD client would fetch user public keys from SSSD
* use SSH agent feature to get user public key from an output of the SSSD
client
--
Thank you
Jan Zeleny
Red Hat Software Engineer
Brno, Czech Republic
12 years, 4 months
memberUID corruption handling
by Stephen Gallagher
I've noticed lately on a couple of LDAP environments (all of which
having been converted at some point in the past from NIS) that there is
a tendency for bad conversion scripts to sometimes leave around groups
with improperly formatted memberUID values.
For example:
dn: cn=groupA,ou=Groups,dc=example,dc=com
objectClass: posixGroup
...
memberUID: user1,user2,user3
Now, the standards-compliant approach here would be to just treat
'user1,user2,user3' as a single group entry (that except on the most
psychotic of systems would never match an actual username).
However, it's well within our power in SSSD to handle this more
gracefully, by parsing the commas ourselves. My question is, is this
something we should do, or should we continue treating this as useless
data and use it to encourage admins to fix their systems?
This *has* caused negative behavior in the SSSD in the past
(specifically, there was a bug in some older versions of LDB that caused
it to be unable to perform a reindex on DNs that contained an escaped
comma, thus rendering SSSD incapable of safely upgrading to newer
versions).
12 years, 4 months
Unable to auth using SSSD on RHEL 5
by Eric
I have been unable to auth using ssh and sssd.
I have attached my sssd.conf (sanitized) and sssd_LDAP.conf (sanitized), sssd.log, sssd_pam.log, sssd_nss.log.
My ldap server is OpenLDAP 2.4.23. The system is a RHEL 5.5.
I am seeing the following in /var/log/secure:
masterldap sshd[3299]: error: Could not get shadow information for testuser
masterldap sshd[3299]: Failed password for testuser from 192.168.0.10 port 46521 ssh2
I am able to do an ldap bind using uid=testuser,ou=People,dc=mydomain,dc=org so the password hash appears to be correct.
I am using the package sssd-1.5.1-37.el5 and sssd-client-1.5.1-37.el5
Any help would be greatly appreciated. I can provide more information upon request.
/etc/pam.d/system-auth-ac
========================================================================
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow debug
account sufficient pam_localuser.so debug
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session optional pam_sss.so
session required pam_unix.so
==============================================================================
-Eric
12 years, 4 months
autofs support
by Ondrej Valousek
Just a captious question: anyone working on the autofs support yet? :-)
12 years, 4 months