LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 05-27-2013, 02:33 AM   #1
unclesamcrazy
Member
 
Registered: May 2013
Posts: 188

Rep: Reputation: 1
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.
Code:
# scp 192.168.1.7:/root/install.log 192.168.1.9:/root
It gives following error.
Code:
Host key verification failed.
lost connection
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
Code:
Error: ssh program unexpectedly exited Please select another viewer and try again
SFTP connection closed by server with exitcode 141
To remove this, I have to uninstall and install the ssh on my system.
Code:
$ apt-get --purge remove openssh-server openssh-client
$ apt-get install openssh-server openssh-client
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.

Last edited by unclesamcrazy; 05-27-2013 at 03:12 AM.
 
Old 05-27-2013, 02:36 AM   #2
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.8, Centos 5.10
Posts: 17,245

Rep: Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327
Have you checked the endpoints to see if they are set to only accept keys and not passwds?
 
Old 05-27-2013, 02:44 AM   #3
unclesamcrazy
Member
 
Registered: May 2013
Posts: 188

Original Poster
Rep: Reputation: 1
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.
 
Old 05-27-2013, 02:56 AM   #4
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.8, Centos 5.10
Posts: 17,245

Rep: Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327Reputation: 2327
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
 
Old 05-27-2013, 03:14 AM   #5
unclesamcrazy
Member
 
Registered: May 2013
Posts: 188

Original Poster
Rep: Reputation: 1
When I run
Quote:
# scp -vvv 192.168.1.7:/root/install.log 192.168.1.9:/root
or
# scp -v 192.168.1.7:/root/install.log 192.168.1.9:/root
I get this
Quote:
Executing: /usr/bin/ssh '-v' '-x' '-oClearAllForwardings yes' '-n' '--' '192.168.1.7' 'scp -v' '/root/install.log' '192.168.1.9:/root'
OpenSSH_5.5p1 Debian-4ubuntu6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.7 [192.168.1.7] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.7' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Unspecified GSS failure. Minor code may provide more information
Credentials cache file '/tmp/krb5cc_0' not found

debug1: Unspecified GSS failure. Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_IN
debug1: Sending command: scp -v /root/install.log 192.168.1.9:/root
Executing: program /usr/bin/ssh host 192.168.1.9, user (unspecified), command scp -v -t /root
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.9 [192.168.1.9] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
lost connection
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2904, received 3992 bytes, in 0.1 seconds
Bytes per second: sent 43616.1, received 59957.1
debug1: Exit status 1
 
Old 07-28-2014, 07:27 AM   #6
fortran
Member
 
Registered: Nov 2011
Location: Cairo, Egypt
Distribution: CentOS, RHEL, Fedora
Posts: 300
Blog Entries: 2

Rep: Reputation: 51
If you read druuna's comment in this post.
http://www.linuxquestions.org/questi...puters-822550/
He clearly says :
Quote:
Are you executing the scp command on computer A and try to scp file(s) from computer B to computer C? If so: That doesn't work.
Scp copies files from the host you are on to a remote host (or vice versa).
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 :
Code:
scp 192.168.1.7:/root/install.log 192.168.1.9:/root
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
Code:
ssh 192.168.1.7 scp /root/install.log 192.168.1.9:/root
It can copy file from system B to System C while you are executing command on system A.
 
Old 07-28-2014, 08:57 AM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,638

Rep: Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252
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.
 
Old 07-28-2014, 09:40 AM   #8
unclesamcrazy
Member
 
Registered: May 2013
Posts: 188

Original Poster
Rep: Reputation: 1
Quote:
Originally Posted by fortran View Post
@fortran
Are you executing the scp command on computer A and try to scp file(s) from computer B to computer C? If so: That doesn't work.
Scp copies files from the host you are on to a remote host (or vice versa).
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.
 
Old 07-28-2014, 11:45 AM   #9
fortran
Member
 
Registered: Nov 2011
Location: Cairo, Egypt
Distribution: CentOS, RHEL, Fedora
Posts: 300
Blog Entries: 2

Rep: Reputation: 51
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.

Quote:
(localhost)...........(Interactive shell)
system A -----------> system B ------------------> system C
(scp command).......(copies to destination)
 
1 members found this post helpful.
Old 07-28-2014, 11:52 AM   #10
schneidz
LQ Guru
 
Registered: May 2005
Location: boston, usa
Distribution: fc-15/ fc-20-live-usb/ aix
Posts: 5,047

Rep: Reputation: 851Reputation: 851Reputation: 851Reputation: 851Reputation: 851Reputation: 851Reputation: 851
are the ssh servers preventing root from logging in ?
 
Old 07-28-2014, 03:39 PM   #11
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,638

Rep: Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252
Quote:
Originally Posted by fortran View Post
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.
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.
 
Old 07-29-2014, 02:05 AM   #12
fortran
Member
 
Registered: Nov 2011
Location: Cairo, Egypt
Distribution: CentOS, RHEL, Fedora
Posts: 300
Blog Entries: 2

Rep: Reputation: 51
Quote:
Originally Posted by jpollard View Post
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.

Last edited by fortran; 07-29-2014 at 02:45 AM.
 
Old 07-29-2014, 02:36 AM   #13
unclesamcrazy
Member
 
Registered: May 2013
Posts: 188

Original Poster
Rep: Reputation: 1
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
Code:
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
lost connection
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
Code:
ssh 192.168.0.20 scp /root/.bashrc user1@192.168.0.99:/home/user1/Downloads
I get
Code:
Host key verification failed.
lost connection
I couldn't figure it out the problem with ubuntu and what centOS have both ubuntu do not have.
 
Old 07-29-2014, 05:35 AM   #14
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,638

Rep: Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252Reputation: 1252
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:

Code:
A->B
B->A
easy.

Three systems though:

Code:
A->B
A->C
B->C
B->A
C->A
C->B
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:

Code:
A->B
A->C
A->D
B->A
B->C
B->D
C->A
C->B
C->D
D->A
D->B
D->C
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:
Code:
A->B
A->C
A->D
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.

Last edited by jpollard; 07-29-2014 at 05:36 AM.
 
1 members found this post helpful.
Old 07-29-2014, 09:23 AM   #15
eklavya
Member
 
Registered: Mar 2013
Posts: 619

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by unclesamcrazy View Post
@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
Code:
ssh 192.168.0.20 scp /root/.bashrc user1@192.168.0.99:/home/user1/Downloads
I get
Code:
Host key verification failed.
lost connection
What is the output of
Code:
ssh -v 192.168.0.20 scp /root/.bashrc user1@192.168.0.99:/home/user1/Downloads
for above command?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Copying file to different system via crontab-called scp - 'No route to host' EnderX Linux - Networking 3 06-11-2012 08:11 AM
i wanted to send a file from one system to another system using SCP anurupr Linux - Networking 8 03-21-2010 09:22 AM
cannot upload data using scp, Read-only file system ufmale Linux - Newbie 3 08-27-2008 12:46 AM


All times are GMT -5. The time now is 03:53 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration