#3824 sftp file broswer causes 4 (System Error)
Closed: wontfix a year ago by pbrezina. Opened 2 years ago by aethylred.

We just had a bit of fuss involved user logins. We’re using sssd 1.16.1 on a client and FreeIPA 4.5.4 (ok, it’s really RHIdM)

We had a lot of users having issues logging and/or resetting their passwords on a host with 2FA enabled, and it turns out when they’re using an advanced SSH client (e.g. MobaXterm) that also starts a SFTP session they can’t login and we see error like:

Sep 11 00:09:05 lander sshd[27408]: pam_sss(sshd:auth): received for user testuser: 4 (System error)
Sep 11 00:09:06 lander sshd[27380]: error: PAM: Authentication failure for testuser from remote.local

If the SFTP file browser is disabled, or it’s protocol is set to use SCP then logins progress normally.

In FreeIPA we’ve enabled 2FA on a per-host basis and the HBAC rule only allows sshd services, so if these were the cause of the ‘4 (System error)’ failures then it’d be much better if the error reports were more meaningful.

Does anyone have any advice on setting up SFTP so that it works (and ideally, doesn’t need repeated entry of credentials).


We've also found that this allows login too:

$ ssh testuser@lander.local
testuser@lander.local's password: <Enter>
testuser@lander.local's password: <Enter>
testuser@lander.local's password: <Enter>
First Factor: <First Factor>
Second Factor (optional): <Second Factor>

However, afterwards MobaXterm's file browser asks for it's own credentials

Oops, used my not $work account

I believe the issue is between sssd and sftp-server and internal-sftp in OpenSSH's sshd

The issue remains if either of thes sftp configurations are used in /etc/ssh/sshd_conf

Subsystem      sftp    /usr/libexec/openssh/sftp-server

or

Subsystem sftp internal-sftp

There was an issue recently with password changes or expired passwords with 2FA. But, System Error more or less means "Unhandled exception", IOW, sssd couldn't figure out a better, more human-readable error code to return, so it just throws its hands in the air and gives up.

Any chance you could attach the SSSD logs? See https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

We've also found that this allows login too:
$ ssh testuser@lander.local
testuser@lander.local's password: <Enter>
testuser@lander.local's password: <Enter>
testuser@lander.local's password: <Enter>
First Factor: <First Factor>
Second Factor (optional): <Second Factor>

This looks like another PAM module asks for credentials before pam_sss, how does your PAM configuration looks like?

However, afterwards MobaXterm's file browser asks for it's own credentials

I guess for SFTP a new connection is opened which needs authentication. Since you are using one-time passwords you have to enter new credentials for each new connection. Using ssh-keys or single-sign-on with Kerberos/GSSAPI might be an alternative here.

And yes, please attach logs.

I don't think it's PAM asking first, I think its the sshd subsystem call to sftp triggering another authentication process. I think SCP is working because it doesn't require re-authentication.

All our logs in /var/log/sssd are pretty much empty, only contain restart messages. I've emailed them to Sumit rather than upload them.

I'm hoping the least we can get from this is a better error message like "sshd subsystem failed authentication" from sssd, as I expect the real issue is the sftp server built into OpenSSH

There was an issue recently with password changes or expired passwords with 2FA.

I suspect this could be related, it's possible that setting up the sftp channel is interrupting the workflow for resetting an expired password with 2FA, esp. as it seems sftp doesn't handle 2FA well.

Metadata Update from @pbrezina:
- Issue tagged with: Canditate to close

a year ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

a year ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4818

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata