This happens when copying from my1.box to my2.box: scp root@my1.box:/etc/motd root@my2.box:/tmp/foo Asks password for one side then displays Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password,keyboard-interactive). The reason is that the ssh invoked on the first machine will have input redirected from /dev/null and thus it cannot authenticate. See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103364
Created attachment 805 [details] Proposed patch This patch calls ssh with option to force tty allocation so it's possible to enter the password. Do you think it's correct?
Created attachment 1108 [details] updated patch The scp changes in 4.3 broke the old patch, so here is an updated one.
After thinking about this some more, there is a good reason why this patch should not go in: when you perform a copy "scp host_a:file host_b" with this patch, you must expose your password on "host_a" rather than the local host. You may not trust "host_a" with your "host_b" password (e.g. someone making a trojan scp binary there could easily collect passwords without your knowledge), and it isn't obvious to someone without a good knowledge of how this actually works that they are actually entering a password on a non-local system. Adding a warning is probably not practical because the host that initiates a remote to remote copy doesn't know what authentication mechanisms will be needed.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.