Bug 103364

Does this happen with test3?

It does.

Simple example

scp root:/etc/motd root:/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).

This is a problem not only with the betas, but with many versions of Red Hat.  I
tried this:

scp root@localhost:/etc/motd root@localhost:/tmp/foo

It asks for the first password, but fails on the second.  I verified this on Red
Hat 7.2, 7.3, 8.0, 9, AS 2.1 and both betas.  I created an ssh key, and then I
see in the logs that it authenticates twice.  The question is--has this ever
worked with openssh?

To clarify:
scp /etc/motd root@localhost:/tmp/foo
works where:

scp root@localhost:/etc/motd root@localhost:/tmp/foo
does not.

It does state in the man page that it is possible to use two remote hosts.

I see something similar on a RH7.3 (fully patched) box.  It's trying 
to run the ssh-askpass program and that fails if your $DISPLAY is 
wrong/unset.  The thing I don't understand is why it's trying to run 
that program.  The ssh manpage says it runs $SSH_ASKPASS if you're 
not running ssh from a terminal.  But xterm *is* a terminal (last I 
checked) so that should not be happening.  Really stumped on this one.

Ok, so my problem was incorrect permissions on /dev/tty, so it's not 
directly related to this bug.

However, I learned something that may explain what you guys are 
seeing.  If you're not running from a terminal then it uses the 
$SSH_ASKPASS program.  When you're trying to scp a box between two 
remote boxes, the connection between them doesn't have a terminal, 
right?

I can't say for sure, but I think I might be on to the root of the 
problem.  Good luck!

Still present in Fedora Core 2 test 1

Still present in Fedora Core 2 test 2

It might be interesting to note that this does not occur when
authenticating with gssapi (using the OpenSSH GSSAPI patch). It still
occurs if you use keypair authentication. This gives some confirmation
to it being ASKPASS related.

Bug is still present in openssh-3.8.1p1-5:

# scp root@localhost:/etc/motd root@localhost:/tmp/foo
root@localhost's password:
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password,keyboard-interactive).
lost connection
#

Just to complicate things, here's what I see with FC2.

Using password-based authentication fails with bogus key-verification
errors:

$ scp root@localhost:/etc/passwd root@localhost:/tmp/passwd
root@localhost's password:
Host key verification failed.
lost connection
$

The host key *is* correct in the above

Using key-based authentication works:

$ rm /tmp/passwd
$ scp localhost:/etc/passwd localhost:/tmp/passwd
$ ls -l /tmp/passwd
-rw-r--r--  1 kaboom kaboom 1942 Aug 25 10:35 /tmp/passwd
$

Created attachment 103825 [details]
Proposed patch

This was really easy to fix. Note however that I don't know if it doesn't have
any unwanted side effects.

Also note that if you try this:
scp someone.host:/xxxxx anyone@localhost:/bbbbbb

it will do something else than what you thought it should do, because it will
copy the /xxxxx file to the localhost on the remote machine not on the machine
you have typed the command on.

*** Bug 121568 has been marked as a duplicate of this bug. ***

Still broken over a year late in FC3test3 despite a patch in the bug

*** Bug 27831 has been marked as a duplicate of this bug. ***