On Fri, Nov 27, 2020 at 06:17:40AM -0000, mir mal via FreeIPA-users wrote:
Hi,
Sorry, maybe I wasn't detailed enough. The environments are client Ubuntu 20.04, FreeIPA Fedora 32 - freeipa-server-4.8.9-2.fc32.x86_64 It's an odd behaviour which should really not happen in a live environment we've discovered it during testing and therefore started opening multiple ssh connections to the host. In our example, in real life, you wouldn't try to open 5 concurrent SSH connection to the same host in a minute, but nevertheless, the behaviour is as follow: Start connecting SSH to Ubuntu client after a few successful connections I start receiving preauth failures. On client in auth.log you can't see anything other than standard failed to auth even on Debug3 level I couldn't find anything that would indicate client setup issue, it looks the same as wrong password error. As I mentioned exactly the same password base method worked ok a few seconds ago and if I wait for a few minutes it does work fine again. The sssd log is empty and auth.log and krb5kdc.log are not showing anything other then a standard generic error, it looks like there is some delay or max connection limit somewhere on Kerberos side but I couldn't find anything in the documentation. I've checked our SSH and there are no limits there, in fact, I can use public key auth for the same user on the same host no problem it's just FreeIPA authentication that is affected. I can create tickets with kinit using the same user as well. Happy to provide more details, just don't know what details at the moment.
auth.log snippet Nov 27 05:54:32 csc-64 sshd[513083]: debug3: send packet: type 53 [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug1: userauth_send_banner: sent [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug2: input_userauth_request: try method none [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug3: user_specific_delay: user specific delay 0.000ms [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug3: ensure_minimum_time_since: elapsed 4.484ms, delaying 0.949ms (requested 5.433ms) [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive" [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug3: send packet: type 51 [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug3: receive packet: type 50 [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug1: userauth-request for user c111111 service ssh-connection method publickey [preauth] Nov 27 05:54:32 csc-64 sshd[513083]: debug1: attempt 1 failures 0 [preauth]
On FreeIPA server krb5kdc.log snippet Nov 27 05:55:39 lab-ipa.stuxnet.lab krb5kdc[4894](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.64: NEEDED_PREAUTH: host/csc-64.stuxnet.lab@STUXNET.LAB for krbtgt/STUXNET.LAB@STUXNET.LAB, Additional pre-authentication required Nov 27 05:55:39 lab-ipa.stuxnet.lab krb5kdc[4894](info): closing down fd 11
Hi,
the 'NEEDED_PREAUTH' messages in krb5kdc.log are expected and do not indicate an error. The '[preauth]' messages in the sshd debug output indicate some specific internal sshd steps and are not related to the Kerberos message.
For further investigations I would suggest to add 'debug_level = 9' to the [pam] and [domain/...] sections in sssd.conf, restart SSSD, rerun the test until it fails and send the SSSD logs together with the full sshd logs. With this it should be possible to identify if the issue is caused by SSSD or Kerberos or if it is related to sssd.
bye, Sumit
klist output from an existing ssh connection on the same host, create just a few seconds before. c111111@csc-64:~$ klist Ticket cache: KEYRING:persistent:1938600006:krb_ccache_5K4WZSD Default principal: c111111@STUXNET.LAB
Valid starting Expires Service principal 27/11/20 06:09:22 28/11/20 06:09:22 krbtgt/STUXNET.LAB@STUXNET.LAB _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...