also needed for Tru64 SIA to work in privsep. WAS: Password expirypatch plans
Michael Steffens
michael_steffens at hp.com
Mon Nov 18 23:59:42 EST 2002
Darren Tucker wrote:
> "Toni L. Harbaugh-Blackford" wrote:
>>This is exactly the problem with getting Tru64 SIA to work in privsep
>>mode. SIA wants to 'talk' to the user directly over the tty that is passed
>>to the auth routines.
>
>
> How about allocating a pty and passing the fd's back to the slave, then
> calling chauthtok or whatever in the monitor? ie:
>
> 1) Slave calls wrapped chauthtok, request passed to monitor
> 2) Monitor allocs pty, opens, makes controlling tty
> 3) Monitor passes descriptors back to slave
> 4) Monitor calls chauthtok / SIA / whatever
> 5) Slave spins copying to and from stdio and the passed fd's
> 6) In monitor, chauthtok returns and returns status to slave
> 7) Slave reads return status from monitor
Sounds very good to me. But 5) seems to be the tough point
(where actually my brain got spinning :)
How to avoid communication monitor <-> slave and
slave <-> network socket blocking each other? The
latter one will need to be served for the remote client
to see the communication in any case.
The PAM conversation funtion of keyboard-interactive seems
to avoid a similar problem by taking over network communication
itself, using SSH2_MSG_USERAUTH_INFO_REQUEST packets.
Besides being protocol 2 only, would this method be usable
for our purpose? Or does it need to be integrated in sshd's
server loop?
More information about the openssh-unix-dev
mailing list