5

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.

3
  • 1
    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. Commented Aug 14, 2011 at 22:04
  • Are those servers in your LAN, or in the cloud? Commented Aug 14, 2011 at 22:21
  • @rozcietrzewiacz; in the cloud. I edited me answer to show what happens.
    – nopcorn
    Commented Aug 14, 2011 at 23:09

2 Answers 2

4

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

6
  • 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.
    – nopcorn
    Commented Aug 14, 2011 at 23:52
  • 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. Commented Aug 14, 2011 at 23:53
  • 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.
    – nopcorn
    Commented Aug 14, 2011 at 23:55
  • Hmm, maybe you were giving them in the wrong order? :) Commented Aug 15, 2011 at 0:04
  • Nope :) the password is the same. And it's still "working". I'm pretty sure it's hanging.
    – nopcorn
    Commented Aug 15, 2011 at 0:07
3

As I understand it, it seems that the following authentications work correctly localhostserver.a and localhostserver.b. So, ssh server.a works, and ssh server.b works. The connections server.xserver.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.aserver.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.

7
  • Is this what's happening in my edit?
    – nopcorn
    Commented Aug 14, 2011 at 23:09
  • @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.) Commented Aug 14, 2011 at 23:37
  • I'm not sure, but without the -3 flag doesn't scp just logs into server.a, then from there makes a connection to server.b? I pretty sure it still requires server.a -> server.b.
    – nopcorn
    Commented Aug 14, 2011 at 23:54
  • @Max Err, seems you are right for the -3. And the issue seems more complex than I thought. I can reproduce it somehow. Commented Aug 15, 2011 at 1:07
  • I've edited my question. It's a bug on their side, so I'm using a work around.
    – nopcorn
    Commented Aug 15, 2011 at 1:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .