Open basvandervlies opened 2 years ago
Is there something wrong with this patch?
Why don't you use the OTP as a password and simply "skip" skip_password
?
How does your pam stack look like?
This PR does not work, since it will fail for all other encodings except "ascii". I.e. it will not work with passwords with special chars (which will also be sent via RADIUS to our perl module!)
I assumes that totp/hotp tokens where ascii. we can delete skip_passwd
because the prompt is different and we do not see what we type, our users will type there password instead of their token, first factor at our side is ssh public keys
Enter passphrase for key '/Users/vlies001/.ssh/id_ed25519':
(bas@login4.lisa.surfsara.nl) Password:
with skip_passwd
Enter passphrase for key '/Users/vlies001/.ssh/id_ed25519':
(bas@login4.lisa.surfsara.nl) please enter otp: 123456
Is much more friendly and the user know what to do
As said with newer pam _radius versions no problem and maybe we must make an option for this which encodings we support. But a lot of distros have still the old one
Same here would be nice to have a response or update. It is a fix for disto's still shipping old pam_radius
versions. Should we make an option or just leave it. Think several people have this issue.
would be nice to have some feedback ;-). I will keep my updated version
At our site we only allow:
So no password ask at all. We have the following pam_radius setup
auth sufficient pam_radius_auth.so skip_passwd retry=1
This fails at our site because we have
pam_radius
version 1.4.0. This is a known problem fixed in 2021:A lot of distributions do not have this fix. So I also solved it in the perl module.
skip_passwd
must sent aNULL
but instead sent garbled input:This is detected and fixed with this patch