Open AlbertMN opened 2 years ago
I don't really understand your setup. Did you use nullok
?
I don't really understand your setup. Did you use
nullok
?
Yep, I did set "nullok", just like in the guide - and that works for most SSH clients like PuTTY, or just connecting via the Mac terminal etc., but it still does give the brief message like it required multi factor, but then skips it.
But not every client is as "large", and keeps "reading" messages after being told it needs multi factor.
So, I can confirm that after removing;
auth required pam_google_authenticator.so nullok
auth required pam_permit.so
from /etc/pam.d/sshd
, as well as ,keyboard-interactive
from AuthenticationMethods
, and re-enabling @include common-auth
, I'm successfully allowed to connect via phpseclib
, but as soon as it's enabled again, there's this "false positive" that results in the connection not succeeding.
That's a lot of changes. Could you narrow down which step breaks it?
That's a lot of changes. Could you narrow down which step breaks it?
I had to do all those things for it to break - it was my understanding, that it's a part of the setup? At least from following this guide; https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-20-04
Just to be on the same page here; is it something in my setup / something in the guide that causes this, or is it a problem with this module?
You could try just adding ,keyboard-interactive
to SSH. Then just adding pam_permit.so
.
Did you fix it? Same issue here!
@hairy-tortoise sadly no. Didn't have the time to dig much deeper, so we actually ended up just disabling MFA for the time being.
I'm running into this with a different client (rapid7 scanner). If I try to force pubkey+googleauth for sshd by setting "AuthenticationMethods publickey,keyboard-interactive:pam", the client appears to abort when requested to do keyboard-interactive, even though I have nullok in /etc/pam.d/sshd and no authenticator configured for that user. Symptom is that ssh works for that user with a real client, and fails from rapid7. I think this would have to be hacked around on the client side or require native support in sshd.
Hi there - first of all; love the project! Been using it for about 2 years for a more secure server, so thanks for all your hard work.
I am, however, experiencing a little problem; for users that don't have multi-factor enabled, SSH still says
Further authentication required
, which messes with a library for SSH connections via. PHP that I'm using, as it thinks multi-factor is required, when it actually isn't.This isn't a problem for normal SSH'ing, one could argue that the problem lies with phpseclib, as they don't give it a chance to pass even though it acts as if it needs multi-factor... (also; just passing a fake code to it doesn't help... My guess is it then expects a response on whether or not the code is accepted, which it then of course doesn't get). I have also created an issue on this for the phpseclib repository; https://github.com/phpseclib/phpseclib/issues/1795
For the setup, I've followed the “How To Set Up Multi-Factor Authentication for SSH” DigitalOcean guide (https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-20-04), but as mentioned, after setting multi-factor up for one user, there's some "artifact" for all other users, even though it's disabled for them.
Connecting through something like PuTTY, it works just fine; it does note that “Further authentication is required”, but it just ignores it and successfully logs in - I’m just not that lucky with the mentioned library.
I did follow "Step 7" in the mentioned guide, but it still seems like it prompts somehow…
Have I done something wrong, or is this a bug (that would probably normally be harmless)? Is there a way to server not send the keyboard-interactive message to the client, when it’s indeed not needed?