Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 user@server.b:/home/public/
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey, password).
lost connection

From server B:

scp user@server.a:/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.

share|improve this question
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. –  rozcietrzewiacz Aug 14 '11 at 22:04
    
Are those servers in your LAN, or in the cloud? –  rozcietrzewiacz Aug 14 '11 at 22:21
    
@rozcietrzewiacz; in the cloud. I edited me answer to show what happens. –  MaxMackie Aug 14 '11 at 23:09

2 Answers 2

up vote 2 down vote accepted

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 user@server.a:/home/public/backup.tar user@server.b:/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 user@server.a:/home/public/backup.tar user@server.b:/home/public/

share|improve this answer
    
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. –  MaxMackie Aug 14 '11 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. –  rozcietrzewiacz Aug 14 '11 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. –  MaxMackie Aug 14 '11 at 23:55
    
Hmm, maybe you were giving them in the wrong order? :) –  rozcietrzewiacz Aug 15 '11 at 0:04
    
Nope :) the password is the same. And it's still "working". I'm pretty sure it's hanging. –  MaxMackie Aug 15 '11 at 0:07

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.

share|improve this answer
    
Is this what's happening in my edit? –  MaxMackie Aug 14 '11 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.) –  Stéphane Gimenez Aug 14 '11 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. –  MaxMackie Aug 14 '11 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. –  Stéphane Gimenez Aug 15 '11 at 1:07
    
I've edited my question. It's a bug on their side, so I'm using a work around. –  MaxMackie Aug 15 '11 at 1:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.