using ssh-add unattended on dubious files -- how can i avoid a hang?

[Daniel Kahn Gillmor]

I need ssh-add to fail cleanly if it tries and fails to read a key,
rather than prompting the user.  I can't seem to figure out how to do
that.

This is on a Linux 2.6.26 system, running OpenSSH 5.1p1 (as built on
debian lenny/sid)

First, the things i've tried:

 * i've unset the DISPLAY and SSH_ASKPASS environment variables, so no
   X11-style prompting should happen.

 * i've redirected stdin from /dev/null (stdout and stderr too, just
   for good measure).

 * i've tried running ssh-add under /usr/bin/nohup

However, even with all that, if i feed ssh-add a garbage key as a
subprocess of anything that as a controlling terminal, it opens
/dev/tty and prompts for a passphrase for the key directly there.

You can see what it's doing here:

[0 dkg at squeak]$ umask 077
[0 dkg at squeak]$ rm -f x 
[0 dkg at squeak]$ touch x
[0 dkg at squeak]$ unset DISPLAY
[0 dkg at squeak]$ unset SSH_ASKPASS
[0 dkg at squeak]$ ssh-add x </dev/null >/dev/null 2>/dev/null
Enter passphrase for x: 

 ...

and at that point it hangs until a carriage return is typed into that
terminal.  In the meantime, i can look at the process and see that
it's opened /dev/tty directly:

[0 dkg at squeak]$ ps $(pidof ssh-add)
  PID TTY      STAT   TIME COMMAND
 3013 pts/19   S+     0:00 ssh-add x
[0 dkg at squeak]$ lsof -p $(pidof ssh-add) | tail -n5
ssh-add 3013  dkg    0r   CHR        1,3            627 /dev/null
ssh-add 3013  dkg    1w   CHR        1,3            627 /dev/null
ssh-add 3013  dkg    2w   CHR        1,3            627 /dev/null
ssh-add 3013  dkg    3u  unix 0xd5df5580         105092 socket
ssh-add 3013  dkg    4u   CHR        5,0           1165 /dev/tty
[0 dkg at squeak]$ 

This seems to be because the ssh-add process is still attached to a
pseudoterminal, so read_passphrase (from readpass.c) opens up /dev/tty
directly.  I'm not sure how to detach the process full from /dev/tty
(or if that would do what i need, even).  

What would it take to get it to just fail with a non-zero return code
(the way it does when confronted with a too-permissive key file)?  Is
this a bug, or am i doing something wrong?

Pointers appreciated,

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080820/d4ad71f1/attachment.bin