scp - Problem in Copying file from system A to system B using system C
 

I am facing a problem while copying file from one system to another system.
Configuartion :
a) All three are linux systems.
b) ssh is installed on all three systems.
c) IP of system-A is 192.168.1.7 & IP of system-B is 192.168.1.9

Process :
I am using system C (ubuntu). I am trying to copy a file from system A (centos) to system B (ubuntu).
I am using following command.
It gives following error.
I have removed known_hosts file of all three systems but it still gives the error.
The error was not before.
Sometimes before, I got an error on my system
To remove this, I have to uninstall and install the ssh on my system.
Now the error was removed and all other things are working fine but I am not able to copy the files from another system to another system using my system.

Please help.

Have you checked the endpoints to see if they are set to only accept keys and not passwds?

Yes, I have checked that too. there is no key file implementation.
There was only one method using password and it was removed too using authorized_keys concept.
So it did not use to ask password and just copied the file.
But when I faced this problem, I thought may be it is because of changed keys or something so I have removed the fie authorized_keys but nothing happened. it still gives same error.

Now what I am doing if I want to copy the file in this way, I copy into my system and copy from my system to destination system using scp. Since now there is no authorized_keys, it asks for password and It works fine.
But this is really time consuming.

So create some auth keys for it to use....
The 2 main methods used for auth are passwd or auth-keys.
There are other more exotic ones, but they are rarely used.
If you want to see, try adding -vvv for verbose debugging info

scp -vvv ....

http://www.itworld.com/it-management...hacks?page=0,1

When I run
I get this

If you read druuna's comment in this post.
http://www.linuxquestions.org/questi...puters-822550/
He clearly says :
But you are saying, you have done this before, when you reinstalled ssh and you lost this functionality.
You can try these two solutions.
Solution : 1
Suppose your system is A where you are executing scp command to copy file of system B to system C.
Copy your public key (system A) and save it in the system B and system C as file ~/.ssh/authorized_keys
Now it won't ask password and you can copy files between two systems.
Your command was :
Before executing the command, save your public key file as authorized_keys in the system 192.168.1.7 and 192.168.1.9 in the directory /root/.ssh/authorized_keys
Now execute the command.

If you can not save your public key in these two systems but you have passwords of both systems. Try following Solution.
Solution : 2
It can copy file from system B to System C while you are executing command on system A.

It has been a while, but I believe that internally solution 2 is what scp does internally when two remote hosts are specified.

When that fails it is because credentials from system B are not accepted by system C.

No fortran, it is not true at all. I can copy a file from system B to system C executing scp command on system A.
If you want proof, here it is.
https://sites.google.com//site/uncle...am_ssh_rc.mpeg

@jpollard
Yes, you are correct. Solution 2 is using scp with ssh I was not asking this. What I was asking is mentioned in above video.

Yes because the reason is, now your CentOS is able to open an interactive shell.
When you run scp from one remote server to another remote server, technically you logged into first remote server then an interactive shell is opened in the remote server, now it copies file to destination remote server.

are the ssh servers preventing root from logging in ?

Technically, it is not an "interactive shell". sshd directly executes scp again, but with modified parameters. It is very nearly exactly the same as "ssh B scp file C:file", the scp running on B is not under an interactive shell (no terminal is assigned). The major difference is that using "ssh B ..." causes a shell to be run to interpret the "scp ..." portion. As I recall, when sshd does it, there is no shell needed as the parameters have already been parsed. Now granted, it has been a while so it is possible a shell is invoked, but there is no reason for it and there is reason to not use a shell - you really don't want a shell reinterpreting path names as it is possible for embedded characters (legal for file names) to cause problems with the shell.

No, No I am not saying scp is doing it interactively. scp is non-interactive.
But if you see the video you will find, A creates a connection with B that's why when transfer is completed, it says connection B is closed.

For me the working is,
A client initiates an SSH connection to the remote host, and requests an SCP process to be started on the remote server. There are two modes: source mode, which reads files and sends them back to the client and sink mode, which accepts the files sent by the client and writes them on the remote host.

In remote-to-remote secure copy, the SCP client opens an SSH connection to the source host and requests that it, in turn, open an SCP connection to the destination.

I was talking about the connection.

Sorry to interrupt you in your technical discussion but if functionality is not working, it is not worth for the user.

I am still facing this problem. When I use CentOS to remote copy from one remote server to another, it is successful but if I execute same command on other two systems(ubuntu) for remote copy, it says
All three systems have ssh installed, all three have same settings in ssh_config and sshd_config but still I face problem if I use ubuntu to remote copy but no problem for CentOS.

@fortran
I am facing same problem if I use scp with ssh. If you want, I can provide it's video too.
I am using ubuntu and my IP is 192.168.0.89, now I execute
I get
I couldn't figure it out the problem with ubuntu and what centOS have both ubuntu do not have.

Missing credentials.

To create the connection to 192.168.0.20 the host must have credentials between the system using ssh and 192.168.0.20.

To create the connection with 192.168.0.99, 192.168.0.20 must have the correct credentials.

The usual cause of the problem is workstation has credentials for the other two systems. In this case, the other two systems must also have credentials.

It usually ends up with everybody having to have credentials for everybody else. It isn't so bad when there is only two or three systems involved (A B) or (A B C). The number of combinations is (read as "system X has given credentials to system Y"):

For two systems:

easy.

Three systems though:

This allows all systems to make connections to any other, thus any source to any destination. But just adding a fourth system, you have to do:

This shows the combinatorial growth problem. The usual result is that some combinations get dropped, or forgotten, and that causes the problem you are seeing.

The growth problem is so bad, that most people don't even bother. They only make connections from one system to the others, thus keeping the growth linear:
Much simpler - but you cannot copy from just any system to any other, only from A to/from the others.

As a side note, this also happens to be more secure.

In the first case (everybody to everybody) a crack to one system gives access the keys for all the other systems. In the last case (only workstation to everybody), ONLY a crack to the workstation gains access keys to the other systems.

What is the output of
for above command?