[Bug 3314] New: RP_ALLOW_STDIN flag to read_passphrase() not working as documented

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Fri May 28 19:27:56 AEST 2021


            Bug ID: 3314
           Summary: RP_ALLOW_STDIN flag to read_passphrase() not working
                    as documented
           Product: Portable OpenSSH
           Version: 8.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: allison.karlitskaya at redhat.com

This bug was originally filed against Fedora:


The maintainers there have asked me to also open a bug here.

The problem is that the read_passphrase() function accepts a flag
called RP_ALLOW_STDIN, which is documented as part of the comment that
appears above that function:

 * Reads a passphrase from /dev/tty with echo turned off/on.  Returns
 * passphrase (allocated with xmalloc).  Exits if EOF is encountered.
 * RP_ALLOW_STDIN is set, the passphrase will be read from stdin if no
 * tty is available

The problem is with the word "ALLOW" and the text "...if no tty is
available".  The way this flag is currently implemented, if it is
given, it *requires* the passphrase to be read from stdin, even if
/dev/tty *is* available.  Additionally, stdin must, itself, be a
reference to a tty.  Otherwise, you fall back to askpass, unless some
heuristic conditions are met, in which case you get to use the tty

The logic in the function is pretty complex...  The offending segment
for this particular problem is here, though:

        else if (flags & RP_ALLOW_STDIN) {
                if (!isatty(STDIN_FILENO)) {
                        debug("read_passphrase: stdin is not a tty");
                        use_askpass = 1;

In any case, this issue is causing problems with tools like git and scp
which pass their own (non-tty) stdin.  In particular, Fedora carries a
patch which introduces the use of this flag with PKCS11 passphrases.

The result is that the askpass program is called, even if it's not
installed, and even if a controlling terminal is available.

Some workarounds are available: setting SSH_ASKPASS_REQUIRE=never, or
unsetting DISPLAY or setting it to the empty string all work (by
triggering changes in some of the heuristics code in this function).

>From what I understand, Fedora is considering dropping or reworking
their patch, so a valid fix to this bug may be simply changing the
comment to more accurately describe the current behaviour (and probably
renaming the flag).

I guess, however, that the current behaviour of this code is not what
was intended, so hopefully it can be fixed.

Thanks very much for your consideration!

You are receiving this mail because:
You are watching the assignee of the bug.

More information about the openssh-bugs mailing list