dmulder
commented
2 months ago MR #130 resolves some of the issues here. Part of the problem was that the cache kept dropping our NSS data for the users, which would repeatedly break SSH. That's resolved. Now a user can submit their first auth attempt via SSH, will immediately be kicked out, then subsequent attempts will succeed. The last remaining thing to fix will be to use the spn for id mapping (this would also solve #71, because SSSD is doing it this way). Since we have the spn at auth time (and I've found a way to discover if the user exists in Entra ID), we can generate a mostly complete NSS passwd response (with the exception of the GECOS, which is fixed immediately after the auth completes).
openssh-server is intentionally corrupting the incoming password from a user which doesn't exist in NSS. This is for some security measure. The problem for Azure Entra ID authentication, is that Azure doesn't tell us if a user exists until after they have successfully authenticated. Somehow we need to enumerate the user prior to authentication. This may mean requiring an admin to authenticate to the host and call a command that enumerates the users ahead of time, etc.