[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: draft-ietf-secsh-userauth-01.txt (fwd)



On Thu, 27 Mar 1997, Tatu Ylonen wrote:

> I'm not very very familiar with the way PAM works.
> 
> However, in the new protocol the server actually drives the
> authentication process.  Whenever a request fails, it lists the
> authentication methods that might productively continue the dialog.
> The server's policy may dictate that other authentications can be
> tried only after "pam" authentication.  Or, the client's policy might
> say that "pam" authentication is tried before any other
> authentications if the server is willing to accept it.

Ahh. Sounds like it will work well with PAM, just a little round-a-bout.

> I'd appreciate if someone can tell me what it would take to add "pam" 
> as an authentication method (or multiple methods if appropriate). 
> Ideally, someone could write a section on the pam authentication methods
> to be included in the draft. 

Well here's a bit of how PAM works WRT ssh:

It's designed to allow you to use many different authentication methods
with a standard API and without recompiling.

Can we do something like:
Ask client for remote username
pam_start()
do pam_set_item for PAM_RUSER, PAM_RHOST, and PAM_TTY (may not have tty if
it's not an interactive login, that's OK).
Call pam_authenticate()
	pam_authenticate may call our conversation callback which will
	send a custom prompt to the client and ask the client for a
	password.
The results of this would tell us whether or not to let the user in.

There are also some other PAM functions that need to be called when
starting/closing a session:
	pam_setcred() (usually does equiv of initgroups() and other stuff
			like that)
	pam_acct_mgmt() (some other stuff)
	pam_open_session() (utmp handling theoretically, resource limits, etc.)
--- do whatever your program does
	pam_close_session()
	pam_end()

May be problems with allowing the conversation function to send a message
back to the client - i.e. do we use a global variable to let it access the
socket fd and/or state information in order to be able to send messages?

Well there's my ideas, I'm sure other pam-list members have comments
as well.

Hope this helps,
-- Elliot Lee
   http://www.redhat.com/             http://www.linuxexpo.org/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []