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