Hi,
I'm using openssh 3.9p1, and here is what bothers me.
If ssh is executed from an X application, when a password is prompted, ssh
manages to grap on to /dev/tty, but then the SIGTTOU is constantly sent to the
ssh and that loops the password prompt function infinetely, since it actually
gets to the console. Because of Solaris implemenation (I guess), that also
gives no cycles to other applications. It took me few hours (!) to login
remotely and kill the ssh process. (And them my CPUs reported the temp outside
of safe limits |-) )
(well, X application is a bad definition, anything that is executed directly
by my Window Manager, which is started by X. Everything will be fine, of
course, if an application (X or not) was started from a connected terminal.
I actually tested this just doing popen("ssh") from a test program and
just
starting it from the window manager menu)
I guess the best way to fix that is to detect that condition in
"readpass.c:read_passphrase()", and fallback to 'use_askpass'.
However,
I haven't found a way to do so :) poll() works fine, writing to the
terminal doesn't rase TTOU immediately (yeah, how did read() trigger a
TTOU ???)
As a relief, I guess I'll restrict the readpassphrase to only restart
limited amount of times (and prevent the lockout), and also pass the
RP_ALLOW_STDIN in "sshconnect2.c:userauth_passwd()", to allow ssh to
actually work.
P.S.
cygwin also has an issue, when a native window application runs
'ssh' inside it, in that case the password can not be read from
anywhere, and the whole thing just hangs...
P.P.S.
please include me into replies, I'm not on the list.
Thanks,
Pawel.
Bye.
--
Pawel S. Veselov [vps], Sun Microsystems, Inc.
Staff Engineer, Java Mobile Systems and Services Engineering __ __(O) _ __
(408) 276-5410 e-mail: Pawel.Veselov at Sun.COM \ V /| || '
\
fax(408) 276-6090 HomePage: http://manticore.2y.net \_/ |_||_|_|_|
