[Bug 3571] New: Canceling SSH_ASKPASS actually sends an empty string

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Sat May 13 00:10:41 AEST 2023


https://bugzilla.mindrot.org/show_bug.cgi?id=3571

            Bug ID: 3571
           Summary: Canceling SSH_ASKPASS actually sends an empty string
           Product: Portable OpenSSH
           Version: 8.8p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: phil.brown.2k+mindrot at gmail.com

I'm using Fedora 36 and the official OpenSSH 8.8p1 install available to
it. I am forcing use of SSH_ASKPASS via "export
SSH_ASKPASS_REQUIRE=force" and using the Gnome askpass program ("export
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass").

I then attempt to log in to a remote machine that requires normal
password authentication and the Gnome askpass dialog appears. In this
dialog, clicking "Cancel" or closing the dialog via "X" causes SSH to
send an empty string which will very likely end up causing an
authentication failure on the target machine.

This empty string comes from line 183 of readpass.c
(https://github.com/openssh/openssh-portable/blob/bf944e3794eff5413f2df1ef37cddf96918c6bde/readpass.c#L183),
which is happening because the RP_ALLOW_EOF flag is not set from the
caller on line 1961 of sshconnect2.c
(https://github.com/openssh/openssh-portable/blob/bf944e3794eff5413f2df1ef37cddf96918c6bde/sshconnect2.c#LL1961C66-L1961C66).

The actual response from the ssh_askpass method in readpass.c is NULL
(from line 104 of readpass.c), which is correct.

The latest source available on the master branch as of the time of
writing up this report is the same as what exists in 8.8p1.

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


More information about the openssh-bugs mailing list