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/10.10.10.5(a)EXAMPLE.COM, 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.
Bryan
Regards,
Dave
-----Original Message-----
From: Bryan Mesich [mailto:bryan.mesich@digikey.com]
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:
>
>
>
> my-user(a)host-1.example.com$ ssh -v
host-2.example.com
> ...
> debug1: Authentication succeeded (gssapi-with-mic).
> ...
> my-user(a)host-2.example.com$
>
>
> 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:
>
>
>
> my-user(a)host-1.example.com$ 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/10.10.10.5(a)EXAMPLE.COM not found in Kerberos database
Your client is looking for a host principle of host/10.10.10.5(a)EXAMPLE.COM, 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 -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> 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/freeipa-users@lists.fedoraho...
--
Bryan Mesich
Sr. System Administrator
DIGI-KEY ELECTRONICS
701 Brooks Ave. South
Thief River Falls, MN 56701 USA
bryan.mesich(a)digikey.com
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
bryan.mesich(a)digikey.com
218.681.8000 x6104
Powered by Linux 3.10.0-862.6.3.el7.x86_64