Strange read_passphrase behaviour ?

[Jarno Huuskonen]

Hi,

On Sun, Jan 27, Jarno Huuskonen wrote:
> On Sun, Jan 27, Markus Friedl wrote:
> > why do you get ENOTTY?
> 
> I think it was the util-linux bug where login didn't set controlling
> tty. It was on some test install box that had the buggy util-linux and
> it didn't have eth0 configured. If I logged in as root and manually
> brought eth0 up then ssh some.host.com would fail to read the password
> and just send empty password three times to some.host.com
> (open(/dev/tty) returned -1). (Funny thing was that after logout/login
> (when eth0 was up) ssh was able to read the password from tty).
> 
> The tty problem is/was something with util-linux, but I think that ssh
> should handle ENOTTY more "gracefully".
> 
> > should ssh auto-set Batchmode=yes for ENOTTY?
> 
> This might work. I'll try to test it (I still have the buggy util-linux
> around). BTW I failed to mention that I tested this with openssh-3.0.2p1.

I finally managed to test this issue a bit further: I made a really ugly
hack and forced read_passphrase to set option.batch_mode if
readpassphrase returned NULL. This way ssh didn't loop three times
sending empty password to the server (it sends the empty password once).

Perhaps a better fix would be for read_passphrase return NULL to the
caller if it can't read password and let caller worry about it. I'm not
sure how well for example auth-pam.c is able to cope if read_passphrase
returns NULL.

-Jarno

-- 
Jarno Huuskonen <Jarno.Huuskonen at uku.fi>