[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