Yes, that helps.
I guess you have 'PasswordAuthentication yes' in your
default
sshd_config and ipa-client-install adds
'ChallengeResponseAuthentication yes'.
Yes and yes.
It looks the ChallengeResponseAuthentication is always tried first
and
then PasswordAuthentication.
Some testing with and without IPA installed says yes.
So this is not a FreeIPA bug.
In theory, it's a bug that FreeIPA users might be more likely to be exposed to (as I
was) but I suspect that probably it's not a common issue.
Anyway.
If I understand it correctly
PermitEmptyPasswords is expected to only work properly with
PasswordAuthentication.
Yes. This certainly seems to be the case - and it's a particularly painful fail.
If ChallengeResponseAuthentication simply ignored PermitEmptyPasswords, that would be
sensible.
But it doesn't. If PermitEmptyPasswords is set, then ChallengeResponseAuthentication
ruins the login - it prompts the user for a password, and if the password word is correct,
it kills the login. The only way to login is to deliberately give wrong passwords until
ChallengeResponseAuthentication gives up and then use PasswordAuthentication to login. And
it's not obvious that this is a possibility. How my colleague discovered that it could
be done, I don't know.
if you really need PermitEmptyPasswords
We don't. I don't know why it was set and, in my opinion, it shouldn't have
been.
So, we have the most trivially easy of work arounds: "don't do that".
Having said that, it took us a bit of effort to work through the issue, which is why I
reported it here.
I figured, it's probably not worth fixing, but maybe if other people hit the same
problem, then they can find this thread and be enlightened.
I'm not even sure what a good fix would be.
Comment out "PermitEmptyPasswords yes", if set?
Abort the install with an explanatory warning?