openssh bugs - Mar 2019 - [Bug 2984] New: scp -3 authentication fails when providing key passphrases for two remote hosts

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

            Bug ID: 2984
           Summary: scp -3 authentication fails when providing key
                    passphrases for two remote hosts
           Product: Portable OpenSSH
           Version: 7.9p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: scp
          Assignee: unassigned-bugs at mindrot.org
          Reporter: damonswirled at gmail.com

OpenSSH_7.9p1 Debian-6, OpenSSL 1.1.1a  20 Nov 2018

this situation has been ongoing for years now. when i have tried to
send files using the -3 option i am presented with two simultaneous
passphrase prompts like so:

scp -3 root at remote1:/home/remote1/testfile root at remote2:/home/remote2
Enter passphrase for key '/remote1.key': Enter passphrase for key
'/remote2.key':

## note that the order that the keys are asked for can change ##

depending on which passphrase is entered next, one of two situations
arise:

1. if the LAST asked for passphrase is entered first (in the case above
this would be remote2.key) then there are no errors printed, and the
system asks for the passphrase for remote1.key. however upon giving the
remote1.key passphrase it will ask for remote2.key passphrase again,
and will continue to alternate between the two i believe until 3 tries
are made for each, whereupon it will fail auth.

2. if the FIRST asked for passphrase is entered first, (in the case
above this would be remote1.key) then after enter is sent the system
just sits waiting with no feedback printed at all. simply pressing
enter at this point will cause the auth to fail immediately. any input
entered at the keyboard is displayed in clear text on the screen.

in order to complete the auth i have found that it is necessary to,
after situation 2 above, enter some character (i have tried "a" and
"n"
-- both work) after the first passphrase has been sent and the system
is waiting, and press enter again. this seems to be interpreted as a
wrong passphrase for remote2.key and the passphrase for remote2.key is
asked for again. at this point, if i enter the passphrase for
remote2.key and send enter, the auth completes, and the testfile is
sent.


i am hoping this report gives enough information so as to make this
work more easily.

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

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

proctor <damonswirled at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal

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

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

Castro B <castro8583bennett at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |castro8583bennett at gmx.com

--- Comment #1 from Castro B <castro8583bennett at gmx.com> ---
Thank you proctor thats helps alot but i hope you can really make it
user friendly

Castro B,
http://webtrafficgeeks.org

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |djm at mindrot.org

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
This should be fixed after scp converted to the sftp protocol, as
connections now happen sequentially and synchronously. Please reopen if
this isn't the case

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.