Bug 1068706 - Password prompt matching requires colon, which may be missing
Summary: Password prompt matching requires colon, which may be missing
Alias: None
Product: Fedora
Classification: Fedora
Component: perl-Net-SFTP-Foreign
Version: 20
Hardware: All
OS: All
Target Milestone: ---
Assignee: Normunds
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-02-21 17:39 UTC by Ted Rule
Modified: 2015-06-30 00:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-30 00:54:32 UTC
Type: Bug

Attachments (Terms of Use)

Description Ted Rule 2014-02-21 17:39:31 UTC
Description of problem:

Net::SFTP::Foreign's password prompt matching code goes into a permanent loop when the remote server supplies a prompt without a trailing colon.

Version-Release number of selected component (if applicable):


How reproducible:

When testing Net::SFTP::Foreign against an "unusual" host which supported keyboard-interactive authentication, and thus generated a server-supplied password prompt, it was found that the host in question had a prompt of the form "username's password", rather than the more usual "username@host's password: " as seen from OpenSSH client code supporting the password authentication mode.

As a consequence, the Net::SFTP::Foreign module simply sulked waiting for a colon.

Looking at the relevant /usr/share/perl5/vendor_perl/Net/SFTP/Foreign/Backend/Unix.pm code file, we find the following code fragment:

debug and $debug & 65536 and _debug "looking for user/password prompt";
my $re = ( defined $password_prompt
                  ? $password_prompt
                  : qr/(user|name|login)?[:?]\s*$/i );

$debug and $debug & 65536 and _debug "matching against $re";

if (substr($buffer, $at) =~ $re) {
   if ($ask_for_username_at_login and
       ($ask_for_username_at_login ne 'auto' or defined $1)) {
       $debug and $debug & 65536 and _debug "sending username";
       print $pty "$user\n";
       undef $ask_for_username_at_login;
   else {
       $debug and $debug & 65536 and _debug "sending password";
       print $pty "$pass\n";
       $password_sent = 1;
   $at = length $buffer;

In the absence of the $password_prompt setting, $re only matches a password prompt containing the string "password" if it contains a colon or question-mark after the word "password".

The code is also questionable in being capable of sending a password in response to a prompt which contains only a colon followed by whitespace; I feel it ought to at least see the word "password" or "passphrase".

The code also uses the $password_prompt variable to match against a potential username prompt, which is questionable.

I believe it would be better to more completely separate the user and password prompt matching with different Regex's, and avoid being able to match against the short ":" string alone, and cope with the unusual condition of a missing colon.

This recoding of the relevant block is a potential solution:

$debug and $debug & 65536 and _debug "looking for user/password prompt";
my $reuser = qr/(user|name|login)([:?])?\s*$/i;
my $repass = ( defined $password_prompt ?
          $password_prompt : qr/(password|passphrase)([:?])?\s*$/i );

if (substr($buffer, $at) =~ $reuser) {
    $debug and $debug & 65536 and _debug "matched against $reuser";
    if ($ask_for_username_at_login and
        ($ask_for_username_at_login ne 'auto' or defined $1)) {
        $debug and $debug & 65536 and _debug "sending username";
        print $pty "$user\n";
        undef $ask_for_username_at_login;
    $at = length $buffer;
} elsif (substr($buffer, $at) =~ $repass) {
    $debug and $debug & 65536 and _debug "matched against $repass";
    $debug and $debug & 65536 and _debug "sending password";
    print $pty "$pass\n";
    $password_sent = 1;
    $at = length $buffer;

Comment 1 Normunds 2014-02-21 20:37:25 UTC
Thank you for the bug report and thorough investigation. I'll look to inform upstream about this bug and hopefully get this solved soon.

Comment 2 Salvador Fandiño 2014-11-04 10:31:18 UTC
Checking just for /[:?]/ is not something that ocurred to me alone, but the result of lots of feedback from users. Checking for /password|passphrase/ on the other hand is quite a bad idea as that would break authentication against systems where the locale is not English based.

I don't think it is possible to come to some regular expression that would catch all the possibilities. That is the reason the door is open for unhandled cases as the one you are facing through the password_prompt option.

In any case, at this point it is too late to change the regular expressions used for password prompt detection as that would break lots of existant scripts and that is unaceptable to me (I am upstream, btw :-)

Comment 3 Fedora End Of Life 2015-05-29 11:00:47 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 4 Fedora End Of Life 2015-06-30 00:54:32 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.