| Summary: | conversation function for passwd auth method assumes instead of fail | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Zdeněk Kotala <zdenek.kotala> |
| Component: | PAM support | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED WONTFIX | ||
| Severity: | major | CC: | djm, t8m |
| Priority: | P2 | ||
| Version: | 5.3p1 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Zdeněk Kotala
2009-12-04 02:23:27 AEDT
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 |