[Freeipa-users] PasswordAuthentication option for SSH
Hi, Today I faced the issue that Kerberos authentication stopped working after disabling PasswordAuthentication in /etc/ssh/sshd_config on a FreeIPA client. The deactivation of this option was done due to security issues. Is it really necessary to have this option set to yes when using Keberos authentication? IPA client 3.0.0 IPA server 3.3.2 Thanking you in advance. David ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Running a FreeIPA replica in a limited-resource environment
Hello, FreeIPA list. We're looking to start using FreeIPA to replace our standard 389 LDAP server on our public web server. That public web server also houses a public wiki, which currently authenticates against 389. We're running FreeIPA on site in our hackerspace, but are working toward a goal of a federated login system between all of our public and internal systems. My plan, as it stands, is to set up a VPN link between our public web server and our space, and set up a master-master replication between a FreeIPA server running onsite, and another on our public web server. The limitation I'm currently considering is that our public web server is limited on resources - it's a VM with 1GB of RAM, on which we're already running Apache, Mediawiki, and an IRC bot. The VM is currently donated by a member. We're a little crunched on resources as it is, and I fear that spinning up a full FreeIPA replica on that system may push us over the edge of resource constraints. Is it possible to tune FreeIPA to run with fewer resources, or replicate only the portions of it that we really need running remotely (just the LDAP server)? Thanks! Christopher Swingler CTO South Side Hackerspace Chicago 2233 South Throop St | Unit 214 | Chicago, IL 60608 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] PasswordAuthentication option for SSH
On Wed, 2014-04-16 at 20:08 +0200, David Kreuter wrote: Hi, Today I faced the issue that Kerberos authentication stopped working after disabling PasswordAuthentication in /etc/ssh/sshd_config on a FreeIPA client. The deactivation of this option was done due to security issues. Is it really necessary to have this option set to yes when using Keberos authentication? No, GSSAPI authentication does not need PasswordAuthentication, of course it requires valid kerberos credentials on the client and a valid keytab on the server. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Running a FreeIPA replica in a limited-resource environment
On Wed, 2014-04-16 at 13:40 -0500, Christopher Swingler wrote: Hello, FreeIPA list. We're looking to start using FreeIPA to replace our standard 389 LDAP server on our public web server. That public web server also houses a public wiki, which currently authenticates against 389. We're running FreeIPA on site in our hackerspace, but are working toward a goal of a federated login system between all of our public and internal systems. My plan, as it stands, is to set up a VPN link between our public web server and our space, and set up a master-master replication between a FreeIPA server running onsite, and another on our public web server. The limitation I'm currently considering is that our public web server is limited on resources - it's a VM with 1GB of RAM, on which we're already running Apache, Mediawiki, and an IRC bot. The VM is currently donated by a member. We're a little crunched on resources as it is, and I fear that spinning up a full FreeIPA replica on that system may push us over the edge of resource constraints. Is it possible to tune FreeIPA to run with fewer resources, or replicate only the portions of it that we really need running remotely (just the LDAP server)? If you avoid configureing the replica as a CA and a DNS server you'll have only a handful of services running, namely 389ds, krb5kdc, kadmind, httpd, ipa_memcahed. Unless you plan on doing maintenance via the public instance, what you could do is to manually turn off kadmind and ipa_memcached on that instance. The managment UI would sto pworking and you wouldn't be able to change password through that server so you may want to avoid advertizing it on your internal newtork, but it should otherwise work for authentication on your satellite VM. Note however that if you are replicating just to allow for redundancy in authentication what you could do instead is to use pam based authentication for your applications and use sssd on the system. Using password based authentication via pam/sssd would allow sssd to cache password hashes of the users and allow authentication even when the VPN link fails and would be much more lightweight. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] [SOLVED] Re: FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Good! And thanks for letting us know, it may help other users too. Simo. On Wed, 2014-04-16 at 17:58 -0400, Fredy Sanchez wrote: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-ldap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-ldap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com - - ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA backend. Mavericks server shows UIDs instead of usernames in File Sharing.
Fredy Sanchez wrote: Hi Simo, Thanks for your reply. Good old Google pointed me to https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/open-l dap_bind_script/Mac_OpenLDAP_bind_script.sh, which gave me the idea of updating the RealName mapping to displayName. This solved the problem, I'll have to recreate the permissions for every share, but the user names now show up, and stick. No more UIDs. Great. Any chance you can write something and post a howto on our wiki? Or send the details to me and I'll write something up? thanks rob On Tue, Apr 15, 2014 at 9:30 AM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Fri, 2014-04-11 at 10:37 -0400, Fredy Sanchez wrote: Hi all, We asked this same question at discussions.apple.com http://discussions.apple.com, but figured we'd have better luck here. I apologize in advance if this is the wrong forum. We are switching from Synology (DSM 5) to Mavericks server (v3.1.1. running in Mavericks 10.9.2) for File Sharing. We use a FreeIPA (ipa-server.x86_64 3.0.0-37.el6) backend for SSO, and the Mac server seems correctly bound to it. Unfortunately, although we can add usernames to the shares for the initial config, the usernames transform to UIDs after (only for SSO accounts; local accounts are not affected). That is, when we go to edit the permissions for a share, all we see are UIDs. We can always figure out the username from the UID, but this is an extra step we don't want to have. We've tried reinstalling the Mac server app from scratch, re-binding to the FreeIPA backend, changing mappings in Directory Utility (for example, mapping GeneratedUID to uid, which is the username), recreating the shares and permissions, etc. Here are more details about the binding: * The binding happens thru a custom package we created based primarily on http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 * Sys Prefs, Users Groups, Login Options show the server bound to the FreeIPA backend with the green dot * The following mappings are in place in Directory Utility, Services, LDAPv3, FreeIPA backend Users: inetOrgPerson AuthenticationAuthority: uid GeneratedUID: random number in uppercase HomeDirectory: #/Users/$uid$ NFSHomeDirectory: #/Users/$uid$ OriginalHomeDirectory: #/Users/$uid$ PrimaryGroupID: gidNumber RealName: cn RecordName: uid UniqueID: uidNumber UserShell: loginShell Groups: posixgroup PrimaryGroupID: gidNumber RecordName: cn The search bases are correct * Directory Utility, Directory Editor shows the right info for the users. * $ id $USERNAME shows the right information for the user FreeIPA is working beautifully for our Mac / Linux environment. We provide directory services to about 300 hosts, and 200 employees using it; and haven't had any problems LDAP wise until now. So we think we are missing a mapping here. Any ideas? Fredy, I quickly tried to check for some documentation on how to configure this stuff, but found only useless superficial guides on how to find the pointy/clicky buttons to push to enable the service. I am not a Mac expert by a long shot so I cannot help you much here. Is there any guide available on how to use this service with other LDAP servers, like openLDAP or Active Directory ? We can probably draw some conclusions from there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Cheers, Fredy Sanchez IT Manager @ Modernizing Medicine (561) 880-2998 x237 fredy.sanc...@modmed.com mailto:fredy.sanc...@modmed.com *Need IT support?* Visit https://mmit.zendesk.com https://mmit.zendesk.com/ * * * * ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Keberos authentication - Unspecified GSS failure
Yesterday I installed the FreeIPA client on machine and after the installation the login with password worked fine. After that I tried to login with a valid Kerberos ticket and it failed. First i traced the ssh login: ssh -vvv da...@test.example.com ---cut--- debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), debug2: key: /home/david/.ssh/id_dsa ((nil)), debug2: key: /home/david/.ssh/id_ecdsa ((nil)), debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/david/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /home/david/.ssh/id_dsa debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/david/.ssh/id_ecdsa debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). ---cut--- Then I enabled the log for SSH on the IPA client machine and faced following error: ---cut--- Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for david Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to 10.100.3.2 Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to ssh Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user david service ssh-connection method gssapi-with-mic Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. Minor code may provide more information\nNo key table entry found matching host/infra01@\n ---cut--- Unspecified GSS failure. Minor code may provide more information.No key table entry found matching host/infra01@\n. After that I tried to receive a ticket on the IPA client machine and everything worked fine: kinit user klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: david@realm.INFO Valid starting Expires Service principal 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... 04/16/14 23:25:51 04/17/14 23:24:47 host/... kvno -k /etc/krb5.keytab host/... host/...: kvno = 1, keytab entry valid So the Kerberos setup on the machine seems to be fine, but still the login SSH using Keberos is not working. GSSAPI is correctly enabled in the sshd configuration file. Any hint is highly appreciated. Thanks. David ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Keberos authentication - Unspecified GSS failure
David Kreuter wrote: Yesterday I installed the FreeIPA client on machine and after the installation the login with password worked fine. After that I tried to login with a valid Kerberos ticket and it failed. First i traced the ssh login: ssh -vvv da...@test.example.com ---cut--- debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), debug2: key: /home/david/.ssh/id_dsa ((nil)), debug2: key: /home/david/.ssh/id_ecdsa ((nil)), debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/david/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /home/david/.ssh/id_dsa debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/david/.ssh/id_ecdsa debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). ---cut--- Then I enabled the log for SSH on the IPA client machine and faced following error: ---cut--- Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for david Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to 10.100.3.2 Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to ssh Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user david service ssh-connection method gssapi-with-mic Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. Minor code may provide more information\nNo key table entry found matching host/infra01@\n ---cut--- Unspecified GSS failure. Minor code may provide more information.No key table entry found matching host/infra01@\n. After that I tried to receive a ticket on the IPA client machine and everything worked fine: kinit user klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: david@realm.INFO Valid starting ExpiresService principal 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... 04/16/14 23:25:51 04/17/14 23:24:47 host/... kvno -k /etc/krb5.keytab host/... host/...: kvno = 1, keytab entry valid So the Kerberos setup on the machine seems to be fine, but still the login SSH using Keberos is not working. GSSAPI is correctly enabled in the sshd configuration file. Any hint is highly appreciated. Thanks. Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab and see what principal is there. sshd didn't look for a FQDN according to your log. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Keberos authentication - Unspecified GSS failure
On Wed, 2014-04-16 at 18:13 -0400, Rob Crittenden wrote: David Kreuter wrote: Yesterday I installed the FreeIPA client on machine and after the installation the login with password worked fine. After that I tried to login with a valid Kerberos ticket and it failed. First i traced the ssh login: ssh -vvv da...@test.example.com ---cut--- debug2: key: /home/david/.ssh/id_rsa (0x7f2ad3112d80), debug2: key: /home/david/.ssh/id_dsa ((nil)), debug2: key: /home/david/.ssh/id_ecdsa ((nil)), debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/david/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /home/david/.ssh/id_dsa debug3: no such identity: /home/david/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/david/.ssh/id_ecdsa debug3: no such identity: /home/david/.ssh/id_ecdsa: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). ---cut--- Then I enabled the log for SSH on the IPA client machine and faced following error: ---cut--- Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 0 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: initializing for david Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_RHOST to 10.100.3.2 Apr 16 23:43:18 infra01 sshd[9940]: debug1: PAM: setting PAM_TTY to ssh Apr 16 23:43:18 infra01 sshd[9941]: debug1: userauth-request for user david service ssh-connection method gssapi-with-mic Apr 16 23:43:18 infra01 sshd[9941]: debug1: attempt 1 failures 0 Apr 16 23:43:18 infra01 sshd[9940]: debug1: Unspecified GSS failure. Minor code may provide more information\nNo key table entry found matching host/infra01@\n ---cut--- Unspecified GSS failure. Minor code may provide more information.No key table entry found matching host/infra01@\n. After that I tried to receive a ticket on the IPA client machine and everything worked fine: kinit user klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: david@realm.INFO Valid starting ExpiresService principal 04/16/14 23:24:51 04/17/14 23:24:47 krbtgt/... 04/16/14 23:25:51 04/17/14 23:24:47 host/... kvno -k /etc/krb5.keytab host/... host/...: kvno = 1, keytab entry valid So the Kerberos setup on the machine seems to be fine, but still the login SSH using Keberos is not working. GSSAPI is correctly enabled in the sshd configuration file. Any hint is highly appreciated. Thanks. Seems like sshd looked for the wrong key. Run klist -kt /etc/krb5.keytab and see what principal is there. sshd didn't look for a FQDN according to your log. FYI: If your hosts for some reason has a non qualified name and you can't fix the issue due to some other broken software requiring short, unqualified, hostnames, you can look into setting the following in krb5.conf: ignore_acceptor_hostname = true Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
