Support requiring both key and password

[henriklundahl]

Would it be possible to add support for requiring both public key and password in a simple way?

Configuration wise, perhaps the denied_login_methods can be used for this by adding a new alternative, e.g. "publickey-and-password". Then you can deny all other methods. This shouldn't be any problem with backward compatibility.

[drakkan]

Hi,

we need multi-step authentication support in crypto/ssh to be able to add this feature, there is already an open ticket there and a pending pull request

golang/go#17889
https://go-review.googlesource.com/c/crypto/+/175978

Currently we can support multi step authentication via keyboard interactive authentication but this method is not suitable to ask for public keys

[drakkan]

Hi,

I'm working on this, I wrote a first patch to add Multi-Step Auth to crypto/ssh. Existing patches don't allow per-user Multi-Step Authentication.

I'll add publickey+password and publickey+keyboard-interacitive to the supported SFTPGo authentication methods in the next days (probably in a separate branch). I think other combinations are not needed, do you agree?

I tested using sftp CLI only, do you have a target SFTP client? Can you help me to test this feature?

Thanks!

[henriklundahl]

That sounds great!

We will probably just use password, publickey and publickey+password, so yes. :-)

I'm not really sure what clients are used today, but we will at least need to support Apache Camel and FileZilla. I can help test with those.

[drakkan]

Hi,

partial authentication is now supported, you should see logs such as these ones:

{"level":"debug","time":"2020-04-09T23:52:14.289","sender":"sftpd","connection_id":"6721c5f0aca840bfb50190340b6a938c6cffeb9a045456045cc831a2a944c6e7","message":"user \"a\" authenticated with partial success"}
{"level":"info","time":"2020-04-09T23:52:16.770","sender":"sftpd","connection_id":"6721c5f0aca840bfb50190340b6a938c6cffeb9a045456045cc831a2a944c6e7","message":"User id: 5031, logged in with: \"publickey+password\", username: \"a\", home_dir: \"/tmp/test\" remote addr: \"127.0.0.1:53532\""}

I was unable to find a way to activate partial authentication in filezilla (keyboard-interactive works fine), while jsch should support it, but I didn't test it myself.

Please let me know if it works for you and if you have a client that works against OpenSSH and doesn't work against SFTPGo, thanks!

[drakkan]

This work for me now, please reopen or fill separate issues if you have any problems or suggestions

[henriklundahl]

I have tested publickey+password with the sftp client from the openssh-client package, with FileZilla and with Apache Camel. I configured all other auth methods as denied.

• sftp client:
  • Fails when just using password.
  • Succeeds when supplying the key and entering the password when asked.
• FileZilla:
  • Fails when just using password.
  • Fails when just supplying the key.
  • Succeeds when first setting logon type "Key file", supplying the key, trying to connect and then changing the logon type to either "Ask for password" or "Interactive" and entering the password. It seems like FileZilla in this scenario "remembers" the key and uses it in the auth process...
• Apache Camel:
  • Fails when just using password.
  • Fails when just supplying the key.
  • Succeeds when supplying both the key and password.

So this seems to work as intended from my perspective. Thanks!

When can a new release be expected? :-)

[drakkan]

I have tested publickey+password with the sftp client from the openssh-client package, with FileZilla and with Apache Camel. I configured all other auth methods as denied.

• sftp client:

  • Fails when just using password.
  • Succeeds when supplying the key and entering the password when asked.

• FileZilla:

  • Fails when just using password.
  • Fails when just supplying the key.
  • Succeeds when first setting logon type "Key file", supplying the key, trying to connect and then changing the logon type to either "Ask for password" or "Interactive" and entering the password. It seems like FileZilla in this scenario "remembers" the key and uses it in the auth process...

• Apache Camel:

  • Fails when just using password.
  • Fails when just supplying the key.
  • Succeeds when supplying both the key and password.

So this seems to work as intended from my perspective. Thanks!

Great thank you for your feedback!

When can a new release be expected? :-)

Honestly I don't know. I would like to receive at least a first review for my patch before the next release, let's see.

[drakkan]

I have tested publickey+password with the sftp client from the openssh-client package, with FileZilla and with Apache Camel. I configured all other auth methods as denied.

• sftp client:

  • Fails when just using password.
  • Succeeds when supplying the key and entering the password when asked.

• FileZilla:

  • Fails when just using password.
  • Fails when just supplying the key.
  • Succeeds when first setting logon type "Key file", supplying the key, trying to connect and then changing the logon type to either "Ask for password" or "Interactive" and entering the password. It seems like FileZilla in this scenario "remembers" the key and uses it in the auth process...

Is Filezilla working the same way with OpenSSH too? It could be a bug, thanks

• Apache Camel:

  • Fails when just using password.
  • Fails when just supplying the key.
  • Succeeds when supplying both the key and password.

So this seems to work as intended from my perspective. Thanks!

When can a new release be expected? :-)

[henriklundahl]

I have tested this now and I saw the same behavior with OpenSSH.

[drakkan]

Thank you for the feedback, very appreciated

[drakkan]

Hi again,

please update to the latest version, my patch for crypto/ssh contains a security bug that should be fixed now

760cc9b
drakkan/crypto@320d321

sorry for the annoyance