PAM documentation says (http://docs.sun.com/app/docs/doc/816-4863/emrbk?l=en&a=view): ---- Developers should make no assumptions about how PAM is to communicate with users. Rather, the application should exchange messages with the user until the operation is complete. Applications should display the message strings for the conversation function without interpretation or modification. An individual message can contain multiple lines, control characters, or extra blank spaces. Note that service modules are responsible for localizing any strings sent to the conversation function. ---- But sshpam_passwd_conv() "Assumes that echo-off prompts are for the password" and pass password as a reply. It could lead that password is exposed to a wrong consumer. Correct solution is to set AUTHTOK before pam_autheticate is called in sshpam_auth_passwd() function. Something like this: pam_set_item(sshpam_handle, PAM_AUTHTOK, password);
I forgot to mentioned, that sshpam_passwd_conv() should return PAM_CONV_ERR in case of PAM_PROMPT_ECHO_OFF message.
Setting PAM_AUTHTOK will not work with Linux-PAM as this item is not accessible by applications.
As documentation and draft of XSSO standard says you really cannot read AUTHTOK in application but it is not a problem. Application (in this case ssh) does not need to read it because it could lead to leak a passwd in some cases, but the information is in the PAM session and PAM module can access it.
Maybe the standard says that however I am just saying what current and all previous Linux-PAM versions did - they do not allow neither to get nor set the PAM_AUTHTOK item from application. Maybe the setting PAM_AUTHTOK item from application should be allowed in the future Linux-PAM versions however I do not think openssh can depend on having the PAM_AUTHTOK available to the application. Also not supporting the current way how the openssh password authentication is implemented with PAM means that current PAM setups might not work anymore - PAM modules for example might require try_first_pass option to consult the PAM_AUTHTOK item at all before calling the conversation function. In fact the "assume that echo-off prompts are for the authtok" worked fine in most of the PAM configurations and in the remaining special cases the sshd should have been configured to use keyboard-interactive authentication instead of password authentication.
(In reply to comment #4) > Maybe the standard says that however I am just saying what current and > all previous Linux-PAM versions did - they do not allow neither to get > nor set the PAM_AUTHTOK item from application. Also Linux-Pan documentation says (http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/mwg-expected-by-module-item.html#mwg-pam_set_item): --- PAM_AUTHTOK The authentication token (often a password). This token should be ignored by all module functions besides pam_sm_authenticate(3) and pam_sm_chauthtok(3). In the former function it is used to pass the most recent authentication token from one stacked module to another. In the latter function the token is used for another purpose. It contains the currently active authentication token. --- It is also mentioned in documentation from 2002/05/09. It should work on linux as well. If not PAM modules stack could works together.
Where do you see in the Linux-PAM documentation that it is available to applications? It just says it is available to modules to pass the token between each other in the stack.
I'm sorry I overlooked it. It mentioned that it works only between modules. I checked also Linux PAM code and there is a wrong check. Fix is easy but it will take longtime to spread Linux distribution. :(
Yes, this is one of the (many) horrors of PAM. Unfortunately for the reasons discussed we cannot ever really get rid of this (PAM_AUTHTOK is Linux-only). On the other hand, it is quite well understood how PAM must be configured to operate correctly with SSH password authentication. If the thought of this assumption in password auth is too much for you, you can disable PAM or use keyboard-interactive authentication which makes no such assumptions.
Move resolved bugs to CLOSED after 5.7 release