openssh
auth-pam: Immediately report instructions to clients and fix handling in ssh client
As it has been discussed some long time ago in bug #2876, I'm adding support for immediate reporting of instructions to clients as defined by RFC4256. There was a similar attempt on #337, however this implied few more changes (see each commit for further details), in particular:
- ~~Add an option to disable this behavior server-side~~
- Fix
sshclient to properly handle the instructions, parsing them properly as per the standard format
~~I'm not fully sure if the server-side setting is needed given that SSHv1 is not supported anymore by sshd, but probably it still makes sense to disable this behavior form server-side, even though using the device selection is possible too now.~~
FYI this has been tested also with PuTTy, and it properly supports the changes without any modification.
Thanks for raising this @3v1n0! I'm running into issues with PAM/SSH and would love to see your fix implemented. Hopefully this can gain some traction.
I think implementing it without backwards compatibility is fine, we could land this early in the release cycle and see if anyone finds breakage with non-OpenSSH clients. If there are problems we can use a compat.[ch] hack to turn it off for the broken clients somehow.
Message ID: @.*** com>
Oh, I see... Well I thought they were also more prone to errors, but will do.
There's very little type safety gained by enums, so it doesn't help as much as we'd like :(
I think implementing it without backwards compatibility is fine, we could land this early in the release cycle and see if anyone finds breakage with non-OpenSSH clients. If there are problems we can use a compat.[ch] hack to turn it off for the broken clients somehow.
Fair... My only concerns is for those new clients (modulo this PR), that may still want the old behavior because otherwise they may get wrong utf-8 output, but if this is not a problem, we can avoid supporting -o KbdInteractiveDevices=pam-legacy-instructions too.
On Wed, 6 Dec 2023 at 08:26, Marco Trevisan @.***> wrote:
Fair... My only concerns is for those new clients (modulo this PR), that may still want the old behavior because otherwise they may get wrong utf-8 output, but if this is not a problem, we can avoid supporting -o KbdInteractiveDevices=pam-legacy-instructions too.
Wouldn't those clients either 1) not be using notification only PAM modules because they don't work properly now or 2) using them before a module that prompts and therefore be seeing the messed up UTF-8 (as the messages are accumulated) already?
Message ID: @.***>
On Wed, 6 Dec 2023 at 08:26, Marco Trevisan @.***> wrote: Fair... My only concerns is for those new clients (modulo this PR), that may still want the old behavior because otherwise they may get wrong utf-8 output, but if this is not a problem, we can avoid supporting -o KbdInteractiveDevices=pam-legacy-instructions too. Wouldn't those clients either 1) not be using notification only PAM modules because they don't work properly now or 2) using them before a module that prompts and therefore be seeing the messed up UTF-8 (as the messages are accumulated) already?
- Eh, but it's not up to the clients to decide if the server uses a pam module that may require that or not.
However, I've been conservative since there are tons of setups I may not have considered, and so providing working-already workaround for old clients seemed to me sane.
But I'll drop this. :)
@djmdjm any chance you could have another look at this? Ubuntu plans to ship this in 24.04 and I'd very much prefer if we had an upstream approved fix instead of an out-of-tree patch.
Is there any progress on this PR? We are writing customized multi-factor authentication pam module for ssh and hope to have the ability to prompt some message without requiring any user input during authentication.
