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(a)STUXNET.LAB for
krbtgt/STUXNET.LAB(a)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(a)STUXNET.LAB
Valid starting Expires Service principal
27/11/20 06:09:22 28/11/20 06:09:22 krbtgt/STUXNET.LAB(a)STUXNET.LAB
_______________________________________________
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://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.fedoraho...