On 22 Dec 1998, Niels [ISO-8859-1] Möller wrote:
> Balazs Scheidler <[EMAIL PROTECTED]> writes:
>
> > one of my never-completed hack projects was an FTP server. I had a global
> > variable holding the sent password (which is available under lsh as well
> > in case password authentication is used), and faking the communication
> > with the user. (e.g. when PAM asked for password, simply feed it the value
> > of that given global variable) This was ugly, but worked.
>
> Ok, you could do something like that, but it's still difficult to do a
> decent mapping between PAM conversation and SSH messages. For
> instance, if there is a PAM module to send a banner message to the
> user before the login promt, this hack would have to distinguish
> between the login prompt (which should be discarded) and the banner
> message, which should be sent the the client as a USERAUTH_BANNER
> message. And even if that works, the banner message would be displayed
> to the user *after* that she has entered her password, which is not
> what was intended. Or consider password change requests.
>
> PAM and ssh user authentication have many features in common, but they
> are severely incompatible. Using them together loses the flexibility
> and power of both.
Here is the conversation function (originally from wu-ftpd pam patch):
static int pamConversation(int num_msg, const struct pam_message **msg,
struct pam_response **resp, void *params )
{
int count = 0, replies = 0;
struct pam_response *reply = NULL;
int size = sizeof(struct pam_response);
for (count = 0; count < num_msg; count++) {
switch (msg[count]->msg_style) {
case PAM_PROMPT_ECHO_ON:
return PAM_CONV_ERR;
break;
case PAM_PROMPT_ECHO_OFF:
if (reply)
realloc(reply, size);
else
reply = (pam_response *) malloc(size);
if (!reply) return PAM_CONV_ERR;
size += sizeof(struct pam_response);
reply[replies].resp_retcode = PAM_SUCCESS;
if (params)
reply[replies++].resp =
xstrdup((char *) params);
else
reply[replies++].resp =
strdup("");
break;
case PAM_TEXT_INFO:
/* ignore it... */
break;
case PAM_ERROR_MSG:
default:
/* Must be an error of some sort... */
return PAM_CONV_ERR;
}
}
if (reply) *resp = reply;
return PAM_SUCCESS;
}
static struct pam_conv pamconv = {
&pamConversation,
NULL
};
bool RealUser::authenticate(Connection *conn, char *password)
{
#ifdef CONFIG_PAM
pam_handle_t *pamh;
pamconv.appdata_ptr = password;
if (pam_start("ftp", name, &pamconv, &pamh) == 0 &&
pam_set_item(pamh, PAM_RHOST, conn->clienthostname) == 0 &&
pam_authenticate(pamh, 0) == 0 &&
pam_acct_mgmt(pamh, 0) == 0) {
pam_end(pamh, 0);
return True;
}
else {
pam_end(pamh, 0);
return False;
}
#else
>
> > if shadow support is based on runtime detection and _not_ a compile time
> > option we have the same functionality. I don't like programs that need to
> > be recompiled when simple passwd is converted to shadow file.
>
> If you look at the configure.in, you will see that lsh checks for two
> shadow related things: It tests if shadow.h can be included, and if
> the linker can find the getspnam function. The idea is that if the
> system supports shadow passwords at all, it should automatically be
> compiled into lsh; if shadow passwords were actually in use when lsh
> was compiled should not matter.
>
> Do you think that is good enough? If we really want to, we could
> always let lshd dlopen some pluggable authentication modules of its
> own ;-)
:-)) better solution would be redesign PAM and call it PAM-NG :-)
>
> The runtime detection is basically
[snip]
>
> (I don't know much about the shadow mechanism myself. Keresztfalvi
> Gabor Agoston helped me with the code above, i.e. he should have the
> credits if it works, and I should be blamed if it doesn't).
it should be enough detecting shadow passwords.
btw: do we really need CC's, or the list is enough? and another question:
would it be possible to move my email address towards the beginning of the
list? that way I would get posts to the list more quickly.
--- Bazsi
