Hello,
I have a Fedora 26 desktop joined to a freeipa domain running two ipa 4.5.4-10 servers on CentOS 7.5.1804. I have an odd "problem" I hope someone here can help me fix.
I can ssh from my desktop to any server in the domain using my password (i.e. interactive) or GSSAPI. Once on a server, I can ssh to some hosts in the domain using GSSAPI delegation, but not to others.
When GSSAPI delegation doesn't work, I see this error:
debug1: Unspecified GSS failure. Minor code may provide more information Server host/ipa01@THEINSIDE.RNR not found in Kerberos database
I think I solved this once before, but it was a very, very long time ago and I don't have any notes to refer to.
What am I messing up?
On Wed, 2018-09-05 at 16:19 -0400, Ranbir via FreeIPA-users wrote:
Hello,
I have a Fedora 26 desktop joined to a freeipa domain running two ipa 4.5.4-10 servers on CentOS 7.5.1804. I have an odd "problem" I hope someone here can help me fix.
I can ssh from my desktop to any server in the domain using my password (i.e. interactive) or GSSAPI. Once on a server, I can ssh to some hosts in the domain using GSSAPI delegation, but not to others.
When GSSAPI delegation doesn't work, I see this error:
debug1: Unspecified GSS failure. Minor code may provide more information Server host/ipa01@THEINSIDE.RNR not found in Kerberos database
Is this the actual error? no editing ?
I think I solved this once before, but it was a very, very long time ago and I don't have any notes to refer to.
What am I messing up?
if ipa01 is really unqualified as you show up here that probably means that you are either ssh-ing using the short name instead of the fully qualified name, or you have reverse resolution enabled and a line in your hosts file with "IP shortname longname", and the shortname is resolved as the name of the server.
HTH, Simo.
Ranbir via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
When GSSAPI delegation doesn't work, I see this error:
debug1: Unspecified GSS failure. Minor code may provide more information Server host/ipa01@THEINSIDE.RNR not found in Kerberos database
You used "ssh ipa01", right? And the host has been enrolleed with ipa01.theinside.rnr?
What am I messing up?
I have in my ~/.ssh/config: CanonicalizeHostname always CanonicalDomains example.org
Hope that helps. Jochen
On Thu, 2018-09-06 at 05:08 +0200, Jochen Hein via FreeIPA-users wrote:
You used "ssh ipa01", right? And the host has been enrolleed with ipa01.theinside.rnr?
Yes.
I have in my ~/.ssh/config: CanonicalizeHostname always CanonicalDomains example.org
I can try that. But, it doesn't answer my question: why does GSSAPI delegation work for some hosts and not others? I'm going to assume I did something wrong, but I don't know what.
For example, I can ssh from my Fedora desktop to ipa01. I don't have to use a password or an ssh key because my kerberos ticket allows me access. Then, from ipa01, I can ssh to anything else in the freeipa domain without a password or ssh key because GSSAPI delegation allows me access.
I have some servers where I can login using kerberos tickets from my Fedora desktop, but GSSAPI delegation fails.
I haven't been able to find a difference between them.
On to, 06 syys 2018, Ranbir via FreeIPA-users wrote:
On Thu, 2018-09-06 at 05:08 +0200, Jochen Hein via FreeIPA-users wrote:
You used "ssh ipa01", right? And the host has been enrolleed with ipa01.theinside.rnr?
Yes.
I have in my ~/.ssh/config: CanonicalizeHostname always CanonicalDomains example.org
I can try that. But, it doesn't answer my question: why does GSSAPI delegation work for some hosts and not others? I'm going to assume I did something wrong, but I don't know what.
For example, I can ssh from my Fedora desktop to ipa01. I don't have to use a password or an ssh key because my kerberos ticket allows me access. Then, from ipa01, I can ssh to anything else in the freeipa domain without a password or ssh key because GSSAPI delegation allows me access.
I have some servers where I can login using kerberos tickets from my Fedora desktop, but GSSAPI delegation fails.
I haven't been able to find a difference between them.
GSSAPI delegation is a client side thing. If you ssh-ed into a server from a client that allowed GSSAPI delegation, now your server becomes a client for the next leg. Is that client allows GSSAPI delegation in itself?
Look at man page for ssh_client: GSSAPIDelegateCredentials Forward (delegate) credentials to the server. The default is no.
Do you have GSSAPIDelegateCredentials yes on all your servers in /etc/ssh/ssh_config?
On Thu, 2018-09-06 at 19:04 +0300, Alexander Bokovoy via FreeIPA-users wrote:
Do you have GSSAPIDelegateCredentials yes on all your servers in /etc/ssh/ssh_config?
Ah crap, I didn't explain it fully: from some servers, GSSAPI delegation only works when I use the FQDN for the server I'm trying to ssh to. On others, I can use just the hostname for the next leg (i.e. short name).
Hmm...maybe there's a configuration parameter set on some that I overlooked.
On to, 06 syys 2018, Ranbir via FreeIPA-users wrote:
On Thu, 2018-09-06 at 19:04 +0300, Alexander Bokovoy via FreeIPA-users wrote:
Do you have GSSAPIDelegateCredentials yes on all your servers in /etc/ssh/ssh_config?
Ah crap, I didn't explain it fully: from some servers, GSSAPI delegation only works when I use the FQDN for the server I'm trying to ssh to. On others, I can use just the hostname for the next leg (i.e. short name).
Hmm...maybe there's a configuration parameter set on some that I overlooked.
By default FreeIPA deals with fully qualified host names. Unless you added non-FQDN names as aliases to your host records in IPA (I suspect you don't), doing non-FQDN ssh access will not work if they aren't resolved by the ssh client to FQDN ones like others in the thread pointed out.
On Thu, 2018-09-06 at 19:25 +0300, Alexander Bokovoy via FreeIPA-users wrote:
By default FreeIPA deals with fully qualified host names. Unless you added non-FQDN names as aliases to your host records in IPA (I suspect you don't), doing non-FQDN ssh access will not work if they aren't resolved by the ssh client to FQDN ones like others in the thread pointed out.
I still don't understand how resolving to the FQDN works from some hosts and not others. For one, the DNS config on all servers is the same. Second, the hosts file for each follows the same format. Third, I don't have any aliases in IPA.
On Thu, 06 Sep 2018, Ranbir via FreeIPA-users wrote:
On Thu, 2018-09-06 at 19:25 +0300, Alexander Bokovoy via FreeIPA-users wrote:
By default FreeIPA deals with fully qualified host names. Unless you added non-FQDN names as aliases to your host records in IPA (I suspect you don't), doing non-FQDN ssh access will not work if they aren't resolved by the ssh client to FQDN ones like others in the thread pointed out.
I still don't understand how resolving to the FQDN works from some hosts and not others. For one, the DNS config on all servers is the same. Second, the hosts file for each follows the same format. Third, I don't have any aliases in IPA.
Start by comparing ssh client configurations on those hosts. Do 'ssh -vvv' runs and compare outputs. Once you see the difference, bring what is there to discuss.
On Thu, 2018-09-06 at 16:03 -0400, Ranbir via FreeIPA-users wrote:
On Thu, 2018-09-06 at 19:25 +0300, Alexander Bokovoy via FreeIPA-users wrote:
By default FreeIPA deals with fully qualified host names. Unless you added non-FQDN names as aliases to your host records in IPA (I suspect you don't), doing non-FQDN ssh access will not work if they aren't resolved by the ssh client to FQDN ones like others in the thread pointed out.
I still don't understand how resolving to the FQDN works from some hosts and not others. For one, the DNS config on all servers is the same. Second, the hosts file for each follows the same format. Third, I don't have any aliases in IPA.
I need to ask, if you really mean "delegation" or if you mean "single- sign-on" here.
Delegation is completely unrelated to whatever server name is used, so a short name won't break delegation per se. However SSO will be broken if a ticket cannot be found.
Simo.
-- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc
On Thu, 2018-09-06 at 16:24 -0400, Simo Sorce via FreeIPA-users wrote:
I need to ask, if you really mean "delegation" or if you mean "single- sign-on" here.
I definitely am. I've been using the -K switch for ssh to ensure GSSAPI credentials are used and forwarded.
Delegation is completely unrelated to whatever server name is used, so a short name won't break delegation per se. However SSO will be broken if a ticket cannot be found.
I've also been double checking that I have a ticket each time I've tested.
On Fri, 2018-09-07 at 11:49 -0400, Ranbir via FreeIPA-users wrote:
On Thu, 2018-09-06 at 16:24 -0400, Simo Sorce via FreeIPA-users wrote:
I need to ask, if you really mean "delegation" or if you mean "single- sign-on" here.
I definitely am. I've been using the -K switch for ssh to ensure GSSAPI credentials are used and forwarded.
Delegation is completely unrelated to whatever server name is used, so a short name won't break delegation per se. However SSO will be broken if a ticket cannot be found.
I've also been double checking that I have a ticket each time I've tested.
So you are able to SSH into the other server without any password prompt, but when you klist there your ccache is empty, is this what you are experiencing ?
Simo.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Jochen Hein -
Ranbir -
Simo Sorce