openssh unix dev - Aug 2008 - using ssh-add unattended on dubious files -- how can i avoid a hang?

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

Circa 2008-08-20 18:08 dixit 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.

  [...]

: 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.

Have you tried running ssh-add via setsid(1)?  According to setsid(2)
(used by setsid(1)):

       setsid()  creates a new session if the calling process is not a
       process group leader.  The calling process is the leader of  the
       new session, the  process group leader of the new process group,
       and has no controlling tty. [...]

--jim

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: C6F31FFA  >>>>>> 
http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+