"Permission denied, try again" while transferring files with scp

Question

I have two servers (A and B) and my local machine. I'm trying to transfer a file from server A to server B.

From server A:

scp ./backup.tar [email protected]:/home/public/
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey, password).
lost connection

From server B:

scp [email protected]:/home/public/backup.tar .
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey, password).
lost connection

Same error message when I try from my local computer. What's going on?

---

This is what I get when I try to ssh from Server A to Server B with the debug flag:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/private/.ssh/identity
debug1: Trying private key: /home/private/.ssh/id_rsa
debug1: Trying private key: /home/private/.ssh/id_dsa
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such file or directory
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: No such file or directory
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Does this mean it can't find my terminal? I should mention that server B is a subdomain of server A. My hosting provider however sees them as completely different entities and they are not hosted on the same LPAR.

---

Conclusion I've emailed my hosting provider and it seems that there is a small bug related to the version of ssh and the OS (freeBSD). Currently, my workaround is to (1) scp the file locally to my machine, then (2) scp the file locally to the second server. This is what scp -3 is supposed to do, but that fails as well.

Solution 1

This looks like there is a problem with ssh configuration on the servers - you cannot ssh from any of them (probably for security reasons).

You can try Stephane's suggestion to do the transfer from your local machine (scp [email protected]:/home/public/backup.tar [email protected]:/home/public/). This should out rule the problem with taking input from terminal (which might me purposely created on the servers).

If that doesn't help, it will mean that the provider probably disallows outgoing ssh connections. In that case, you'll be left with two options:

• ask the provider to enable outgoing ssh connections

or

• transfer the files through your local machine:

  scp -3 [email protected]:/home/public/backup.tar [email protected]:/home/public/

Solution 2

As I understand it, it seems that the following authentications work correctly localhost → server.a and localhost → server.b. So, ssh server.a works, and ssh server.b works. The connections server.x → server.y fail because of some strange problem with the 'read password' procedure on the servers.

Easiest workaround would be to configure ssh keys to connect automatically from one server to the other:

server.a$ ssh-keygen   #use default answers and empty passphrase
server.a$ ssh-copy-id server.b

This allows server.a → server.b connections with key authentication. Do the same on server.b for the other direction.

After that, I hope scp should work with automatic authentication, avoiding the 'read password' issue.

Comments

[Admin]

What happens if you ssh into A and from there, try to ssh into B? And the other way around? Also, use ssh -v in stead of just ssh for debugging.

[Admin]

Are those servers in your LAN, or in the cloud?

[Admin]

@rozcietrzewiacz; in the cloud. I edited me answer to show what happens.

[n0pe]

Is this what's happening in my edit?

[Stéphane Gimenez]

@Max It seems that the ssh command on the servers is somehow broken when trying to read your password. It tries to open /dev/tty which seems to be missing. There is something wrong with the ssh installation (or the servers' OS, whatever it is). However, since you can ssh to them from your host, you can use the method provided in my answer. (Unless you are writing an automated backup script, and you want to copy directly from one server to the other directly.)

[n0pe]

I used the -3 flag and it seemed promising. It asked me my password for server A, then said it was wrong. It did this a couple times displaying the "Try Again" message and now it's hanging. Not sure if it is actually copying.

[rozcietrzewiacz]

It probably is - see man scp : there is no progress bar when you use -3. But you can just check your transfers to detrmine that.

[n0pe]

Odd, ssh must be oddly configured because it wasn't accepting my passwords (which I know are right). I'll wait a bit, the file isn't too big, and post back with results.

[rozcietrzewiacz]

Hmm, maybe you were giving them in the wrong order? :)

[n0pe]

Nope :) the password is the same. And it's still "working". I'm pretty sure it's hanging.

[rozcietrzewiacz]

Well, too bad then - try a simple two-step method or contact the hosting provider :(

[Stéphane Gimenez]

@Max Err, seems you are right for the -3. And the issue seems more complex than I thought. I can reproduce it somehow.

[n0pe]

I've edited my question. It's a bug on their side, so I'm using a work around.

[Stéphane Gimenez]

@Max: maybe have a look at my workaround also.

[n0pe]

I've logged a service request for my hosting provider to do this (they like doing it themselves, don't ask me why). Hopefully that will help. Thanks