On Wed, Dec 19, 2018 at 09:18:35PM -0600, Bryan Mesich via FreeIPA-users wrote:
> On Thu, Dec 20, 2018 at 01:08:14AM +0000, Theese, David C wrote:
> > Bryan,
> > 
> > Thank you very much for the response.
> > 
> > I have double-checked that I do have both A and PTR records configured for 
> > all hosts, and I even have an automated test that runs daily to check both 
> > forward and reverse consistency of all DNS records specifically to avoid 
> > DNS-related authentication issues.
> 
> Do you have anything in ~/.ssh/config that would be messing with your
> connection?
> 
> > "Your client is looking for a host principle of 
> > host/[email protected], which I think is a clue."
> > 
> > Yes, I believe you are exactly right. However, such a principal is not 
> > created automatically when I do an "ipa-join -h" on the host. ipa-join 
> > provides an option to create a hostname-based Kerberos principal, but not 
> > one based on an IP address:
> > 
> > ipa-join --help
> > Usage: ipa-join [OPTION...]
> >   -d, --debug                 Print the raw XML-RPC output in GSSAPI mode
> >   -q, --quiet                 Quiet mode. Only errors are displayed.
> >   -u, --unenroll              Unenroll this host from IPA server
> >   -h, --hostname=hostname     Hostname of this server
> >   -s, --server=hostname       IPA Server to use
> >   -k, --keytab=filename       Specifies where to store keytab information.
> >   -f, --force                 Force the host join. Rejoin even if already 
> > joined.
> >   -w, --bindpw=password       LDAP password (if not using Kerberos)
> >   -b, --basedn=basedn         LDAP basedn
> > 
> > Help options:
> >   -?, --help                  Show this help message
> >   --usage                     Display brief usage message
> > 
> > Do you by chance have thoughts on how I can get such a principal created?
> 
> I'm not a FreeIPA user, but I use the same technology in our environment
> (i.e. Kerberos, Bind w/dyndb-ldap).  Adding a IP based host principal into
> the KDC is typically not needed since the host name should be resolved
> and the FQDN based principal should be used.  It smells like a sshd/ssh
> configuration issue to me.  I just tested connecting to a server using
> only an IP address without issue.  My client resolves the IP to a FQDN
> and then makes the request to the KDC.
> 
> Can you post the output of "ssh -G 10.10.10.5" so we can see what client
> side options are being used?
> 
> Also, post the results of "dig -x 10.10.10.5" from the same client.
> Just verifying nothing in /etc/hosts or elsewhere is interfering.

I was able to reproduce the problem on my end.  I forgot that Kerberos
can canonicalize host names.  If I set "dns_canonicalize_hostname =
false" under the [libdefaults] section (in krb5.conf on client), I get
the same problem:

debug1: Unspecified GSS failure.  Minor code may provide more
information Server host/[email protected] not found in Kerberos database

Try setting it to true and see what happens.

Bryan
> 
> Bryan
> 
> > 
> > Regards,
> > Dave
> > 
> > 
> > -----Original Message-----
> > From: Bryan Mesich [mailto:[email protected]] 
> > Sent: Wednesday, December 19, 2018 5:42 PM
> > To: FreeIPA users list
> > Cc: Theese, David C
> > Subject: Re: [Freeipa-users] Single Sign On (SSO) SSH via IP Address
> > 
> > On Thu, Dec 20, 2018 at 12:10:37AM +0000, Theese, David C via FreeIPA-users 
> > wrote:
> > > Hello FreeIPA Community,
> > > 
> > > I am using FreeIPA version 4.4.0 on CentOS Linux 7.3.1611.
> > > 
> > > Via FreeIPA's use of Kerberos, I have no problem SSHing among hosts in a 
> > > passwordless manner (Single Sign On (SSO)) as long as I use their 
> > > hostnames. Example relevant output from the SSH client verbose mode is:
> > > 
> > > 
> > > 
> > > [email protected]$ ssh -v host-2.example.com
> > > ...
> > > debug1: Authentication succeeded (gssapi-with-mic).
> > > ...
> > > [email protected]$ 
> > > 
> > > 
> > > However, if I try to SSH to the same host using its (fixed) IP address 
> > > rather than its hostname, SSO does not succeed as an authentication 
> > > method, and the client falls back to keyboard-interactive, prompting me 
> > > for a password, as can be seen here:
> > > 
> > > 
> > > 
> > > [email protected]$ ssh -v 10.10.10.5
> > > ...
> > > debug1: Authentications that can continue: 
> > > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> > > debug1: Next authentication method: gssapi-keyex
> > > debug1: No valid Key exchange context
> > > debug1: Next authentication method: gssapi-with-mic
> > > debug1: Unspecified GSS failure.  Minor code may provide more information
> > > Server host/[email protected] not found in Kerberos database
> > 
> > Your client is looking for a host principle of host/[email protected], 
> > which I think is a clue.
> > 
> > > debug1: Authentications that can continue: 
> > > publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
> > > debug1: Next authentication method: keyboard-interactive
> > > Password:
> > > 
> > > We have in-house code that performs remote command execution via SSH. 
> > > We've made sure our code always uses hostnames to avoid this problem. 
> > > (Being prompted for a password kills the automation we're trying to 
> > > achieve.)
> > > 
> > > We also use some external code (over which we have no control and are not 
> > > permitted to modify), and that code also performs remote command 
> > > execution via SSH. Unfortunately, however, it does so using an *IP 
> > > address*, rather than a hostname, as a destination.
> > > 
> > > For this reason, we need FreeIPA's SSO SSH capability to work when SSHing 
> > > to a host via that host's IP address.
> > > 
> > > Is this possible and, if so, how would it be accomplished?
> > 
> > I'm guessing you don't have a proper PTR for this host.  This is
> > preventing your client from resolving its hosts name, which it need to
> > look-up in the KDC for a service ticket.  Try adding a reverse entry for
> > host-2.example.com and try again.
> > 
> > Bryan
> > 
> > > Thanks,
> > > Dave
> > > _______________________________________________
> > > FreeIPA-users mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedorahosted.org/archives/list/[email protected]
> > 
> > -- 
> > Bryan Mesich
> > Sr. System Administrator
> > DIGI-KEY ELECTRONICS
> > 701 Brooks Ave. South
> > Thief River Falls, MN 56701 USA
> > [email protected]
> > 218.681.8000 x6104
> > 
> > Powered by Linux 3.10.0-862.6.3.el7.x86_64
> 
> -- 
> Bryan Mesich
> Sr. System Administrator
> DIGI-KEY ELECTRONICS
> 701 Brooks Ave. South
> Thief River Falls, MN 56701 USA
> [email protected]
> 218.681.8000 x6104
> 
> Powered by Linux 3.10.0-862.6.3.el7.x86_64
> _______________________________________________
> FreeIPA-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/[email protected]

-- 
Bryan Mesich
Sr. System Administrator
DIGI-KEY ELECTRONICS
701 Brooks Ave. South
Thief River Falls, MN 56701 USA
[email protected]
218.681.8000 x6104

Powered by Linux 3.10.0-862.6.3.el7.x86_64
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]

Reply via email to