Mailing List Archive: OpenSSH: Dev

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

Index | Next | Previous | View Threaded

dkg-openssh.com at fifthhorseman

Aug 20, 2008, 3:08 PM

Post #1 of 5 (603 views)
Permalink

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] squea]$ umask 077
[0 dkg [at] squea]$ rm -f x
[0 dkg [at] squea]$ touch x
[0 dkg [at] squea]$ unset DISPLAY
[0 dkg [at] squea]$ unset SSH_ASKPASS
[0 dkg [at] squea]$ 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] squea]$ ps $(pidof ssh-add)
PID TTY STAT TIME COMMAND
3013 pts/19 S+ 0:00 ssh-add x
[0 dkg [at] squea]$ 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] squea]$

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

jmknoble at pobox

Aug 20, 2008, 3:27 PM

Post #2 of 5 (570 views)
Permalink

Re: using ssh-add unattended on dubious files -- how can i avoid a hang? [In reply to]

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 | 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|
+----------------------------------------------------------------------+
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

dkg-openssh.com at fifthhorseman

Aug 20, 2008, 4:46 PM

Post #3 of 5 (573 views)
Permalink

Re: using ssh-add unattended on dubious files -- how can i avoid a hang? [In reply to]

On Wed 2008-08-20 18:27:59 -0400, Jim Knoble wrote:

> Have you tried running ssh-add via setsid(1)?

Thanks, Jim! I didn't know about setsid, and it appears to be what
i'm looking for.

The only remaining irritation is that ssh-add returns a status code of
0 rather than the expected non-zero value from a failed attempted add
under setsid.

(it also emits the prompt on stderr, even when there is no terminal to
read from, which seems useless but not as difficult to work around as
the zero-valued return code)

In the example below, the number at the beginning of the shell prompt
is the return code of the process just completed (i hit ctrl+D (EOF)
after the first passphrase prompt, but all other interaction is
visible):

[0 dkg [at] squea test]$ umask 077
[0 dkg [at] squea test]$ rm -f x
[0 dkg [at] squea test]$ touch x
[0 dkg [at] squea test]$ ssh-add x </dev/null
Enter passphrase for x:
[1 dkg [at] squea test]$ setsid ssh-add x </dev/null
Enter passphrase for x: [0 dkg [at] squea test]$

So ssh-add is emitting a different return code in the setsid situation
than the normal situation. Is that what i should expect?

Regards,

--dkg

david-bronder at uiowa

Aug 20, 2008, 5:00 PM

Post #4 of 5 (575 views)
Permalink

Re: Re: using ssh-add unattended on dubious files -- how can i avoid a [In reply to]

Daniel Kahn Gillmor wrote:
>
> On Wed 2008-08-20 18:27:59 -0400, Jim Knoble wrote:
>
> > Have you tried running ssh-add via setsid(1)?
>
> Thanks, Jim! I didn't know about setsid, and it appears to be what
> i'm looking for.
>
> The only remaining irritation is that ssh-add returns a status code of
> 0 rather than the expected non-zero value from a failed attempted add
> under setsid.

Actually, that isn't really working, either. The ssh-add is still
running and grabbing /dev/tty even though you get your prompt back
(check ps from another shell). It will eat terminal input until the
next newline even though you don't see the prompt. The 0 exit code
is coming from setsid, which had no errors.

Instead, try setting SSH_ASKPASS to /bin/false or DISPLAY to a bogus
value, and redirect/close stdin/stdout/stderr. That will make ssh-add
try to use SSH_ASKPASS which will fail (one way or another).

$ SSH_ASKPASS=/bin/false ssh-add foo </dev/null >/dev/null 2>&1
$ DISPLAY=bar ssh-add foo </dev/null >/dev/null 2>&1

=Dave

--
Hello World. David Bronder - Systems Admin
Segmentation Fault ITS-SPA, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm. david-bronder [at] uiowa
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

dkg-openssh.com at fifthhorseman

Aug 20, 2008, 9:05 PM

Post #5 of 5 (571 views)
Permalink

Re: Re: using ssh-add unattended on dubious files -- how can i avoid a [In reply to]

On Wed 2008-08-20 20:00:46 -0400, David Bronder wrote:

> Actually, that isn't really working, either. The ssh-add is still
> running and grabbing /dev/tty even though you get your prompt back
> (check ps from another shell). It will eat terminal input until the
> next newline even though you don't see the prompt.

Hrm. It really doesn't appear to be still running when i check from
another shell comparing the output of "ps -eFH" immediately before and
after running "setsid ssh-add x". setsid(1) really does appear to
disable the functionality of /dev/tty.

And it doesn't eat terminal input until the next newline for me. To
be clear, i did:

unset -v DISPLAY
unset -v SSH_ASKPASS
setsid ssh-add x </dev/null

(this is using bash 3.2.39(1)-release, if it matters).

> The 0 exit code is coming from setsid, which had no errors.

hrm. you appear to be right: the version of setsid i'm using forks
and then just returns 0, which means that it's being invoked as a
process group leader by the shell. Weird, and not the behavior i'd
expected. If it finds that it has to fork, why doesn't
/usr/bin/setsid wait for the child process and propagate its exit
status directly?

This seems like it's veering off-topic for this list, so I started a
separate discussion on debian's bugtracker, if anyone wants to follow
up on the vagaries of the behavior of setsid(1):

http://bugs.debian.org/495881

> Instead, try setting SSH_ASKPASS to /bin/false or DISPLAY to a bogus
> value, and redirect/close stdin/stdout/stderr. That will make ssh-add
> try to use SSH_ASKPASS which will fail (one way or another).
>
> $ SSH_ASKPASS=/bin/false ssh-add foo </dev/null >/dev/null 2>&1
> $ DISPLAY=bar ssh-add foo </dev/null >/dev/null 2>&1

This is a great (and in retrospect, obvious) suggestion. Thank you!
My final solution is just:

DISPLAY=nosuchdisplay SSH_ASKPASS=/bin/false ssh-add foo </dev/null

Thanks to both Jim and David! I learned a bunch today.

--dkg

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads