Sending data between two remote machines.

In short I want to tranfer files between two remote linux machines, running a command on a third machine.

My situation is this:

There are three machines involved:

SERVER1: This machine accepts either sftp or scp file transfers.

SERVER2: I control this server, so it accepts pretty much anything I want it to accept. Sftp, scp, rsync, ftps… you name it. Anything that’s safe to have open to the internet.

WORK: This is a remote machine at my workplace that’s runnin SunOS 5.9 (Solaris 9). I have very limited access to this machine. I can ssh into it, but can’t install any programs.

The main problem is that SERVER1 and SERVER2 can’t talk together. But WORK can talk to both of them. So what I need to do is ssh into WORK, and use that computer to transfer data between SERVER1 and SERVER2. It would be perfect to use rsync for this, but for some reason rsync doesn’t work on the WORK server. Does anyone know how I could do this? Any nice scripts or tools out there that I could use for this project, that maybe utilize sftp or scp?

Btw I found a promising script here: xtravar.net/article.php?id=14 , that I might maybe have used and changed. But unfortunately WORK doesn’t have php installed.

Now I know that it would be logical to talk to my admin at work and ask him to set something up, but I’d rather want to do this just by myself. He’s not that friendly actually and would take ages to find the time to help me out

Regards
Frímann Kjerúlf

Hi
You just need to create a ssh tunnel to SERVER2, have a look here;
<http://souptonuts.sourceforge.net/sshtips.htm&gt;
In the example think of linux laptop (SERVER1), SSH Server (WORK) and
HTTP Server (SERVER2).


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.2 Milestone 2 (i586) Kernel 2.6.30-rc6-git3-4-default
up 20:34, 2 users, load average: 0.18, 0.31, 0.24
CPU VIA Esther processor 1000MHz GPU VIA CX700/VX700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Exactly. The approximate commands would be the following to transfer a
file from server1 (named file1 in your home directory) to yourServer2User
(again to the home directory) on the remote machine after SSH-ing into
your work computer as yourWorkUser:

#On SERVER1
SERVER1:~> ssh -L 2222:SERVER2:22 yourWorkUser@WORK
WORK:~>

#Open another shell
SERVER1:~> scp $HOME/yourFile yourServer2User@localhost: -P 2222

Keep in mind that ‘SERVER2’ above is either an IP or DNS name resolvable
from WORK that resolves to SERVER2 and is not an IP or DNS name that must
work from SERVER1. Tunnels are beautiful things.

Good luck.

Malcolm wrote:
>

> Hi
> You just need to create a ssh tunnel to SERVER2, have a look here;
> <http://souptonuts.sourceforge.net/sshtips.htm&gt;
> In the example think of linux laptop (SERVER1), SSH Server (WORK) and
> HTTP Server (SERVER2).
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKKycGAAoJEF+XTK08PnB5k5kQAJkLa6n+CV7cvropI24MqQ5j
GkSthxU9n6m44oo0Pb+kL91qrI588k5m8EP5DssJC2htlIv2fVRy6t1rloAz1eOl
BYxtk3X9a30xnrUw/zQNJKyMoW7QMM1qURIN/wLfCCQ0J5yV2j8t/Woq1Ryp71MP
KYepAUoqOHxn05TOoQoxr0iF3T1jCTmHwBAYWh+UkB8qR6TzvoxBW8eFP+KFMxON
vb2CGaj6CX2AL0PPYaXSdSrRb/uh1tCKJ6xBpH4i94pJi0C4jlQF3USQc4j49Hap
xvnsIkX1LqltXOrQCfcP0yDYr08fjlvTYzodSEL7e4XHiNmPTooXzX5/VriD0I/V
G9bngVlnkRENM/FlSOaaOTwj/frRK0aNU44JxOxDW1KMDNPwZSF/xW4UNNPJZrA8
CRZPEEE7hHbvIBXfFfntria2hptM3qFOGMJKg+PBEQgI2uZeyqwjBZuWRnETC4oL
9iNqUxwy/1Y8hvPoMfpFOkfulErAKL0F/G2iWwUZ7FARpbddUHhnvQ2Pesj0KSua
6vff4VouRtYM4drIE6/7slBLq5+CqVTl0osw8QJWyBKfFVLVKduSTSHDGD0Sfhjq
dNIWdI7jRikJ4pzBgOrC0F3ZfLzBhDN7vnJ0K+aG2SQRZ5NxbjniHqJh2ABR7/pP
iAMlnocKZeZgaUnDNXX+
=E28q
-----END PGP SIGNATURE-----

Thanks for your replies. This methood would have worked perfectly. But it seems that the WORK server has tunneling disabled.

I make a tunnel like described, but when I then open another terminal window and try to sftp from SERVER2 to SERVER1 through WORK I get this message:

ssh_exchange_identification: Connection closed by remote host
Connection closed

And in the ssh tunnel terminal window (the one that has an open ssh connection to WORK) I get this message:

channel 5: open failed: administratively prohibited: open failed

Any other ways of doing this, maybe by executing some command at the WORK computer?

I might add that I only have scp and sftp access to SERVER1, but not ssh access.

Thanks
Frímann

Hi
On the home machine, open either nautilus and use sftp://…server1 or
if konq use fish://…server1 and see if that works.


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.2 Milestone 2 (i586) Kernel 2.6.30-rc6-git3-4-default
up 11:12, 2 users, load average: 0.02, 0.07, 0.08
CPU VIA Esther processor 1000MHz GPU VIA CX700/VX700

malcolmlewis: Thanks for your answer, but the problem is that SERVER1 and SERVER2 can’t talk together. But they can both talk to WORK, so the transfer would have to go through WORK. I think SERVER1 is connected to the same network as WORK through vpn.

regards
Frímann

Hi
You still need to create the tunnel as in step 1, then try the GUI
method with sftp rather than scp.

If that doesn’t work, how much access do you have on your solaris box,
can you install perl modules? Do you have many files to transfer?


Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.21-0.1-default
up 7 days 17:10, 2 users, load average: 0.05, 0.19, 0.27
GPU GeForce 8600 GTS Silent - Driver Version: 180.51

I tried using Konq and Krusader, got exactly the same results.

Regarding the WORK machine I can’t install any Perl modules.

The files are many, and I will be doing this for a long time. Best would be to be able to sync a directory on SERVER2 with the contents on SERVER1.

I’m thinking it must be possible at least for me to write a script which will somehow manage to do this. I was just hoping someone had done it before :slight_smile:

One thing I’m confused about though. Shouldn’t I put sftp://localhost:22000 in konq? 22000 is the port that I set to forward in .ssh/config

Just to make sure :slight_smile:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you forwarded an alternate port, yes.

Good luck.

dreamspy wrote:
> malcolmlewis;1996187 Wrote:
>> Hi
>> On the home machine, open either nautilus and use sftp://…server1
>> or
>> if konq use fish://…server1 and see if that works.
>>
>> –
>> Cheers Malcolm °¿° (Linux Counter #276890)
>> openSUSE 11.2 Milestone 2 (i586) Kernel 2.6.30-rc6-git3-4-default
>> up 11:12, 2 users, load average: 0.02, 0.07, 0.08
>> CPU VIA Esther processor 1000MHz GPU VIA CX700/VX700
>
>
> One thing I’m confused about though. Shouldn’t I put
> sftp://localhost:22000 in konq? 22000 is the port that I set to forward
> in .ssh/config
>
> Just to make sure :slight_smile:
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJKLlvgAAoJEF+XTK08PnB5/hcQAM03HRdjhQziiSjZ8DL7Bvzr
AsLz/pUIwqhW79VlzTOdrngxRu95UmsP5T59vOa026gbwsOWaJkOYNsLjaYIuY0V
WwnKt9ckpcizAPOafltK6yUuYdC0WlEoDZmRX9SFjlrYex7W6dm3ePMV4GZ3JO5E
AGvFbog+ta1XUUv5IBf9ImrfGCVHNdWr/zoMim6902wpN/TccWAaGiXU7Ca2zs7s
nDV/p3C+w/+1gZs1VfAiu7lEMymKenN3c14E+668quwRynjtC4bBZARAb4V75qAe
2L3kEunV5ou6PQ+g982jxE62lYVUQiQtTuTt+joCWdvDDosu0CQ2LGMq6r9z+rnK
NSFV+xe0wHH4xCOZIBe2DY0QxgdmE6Z0Ggzt5IzE/ESamJtUVCWnVjzAUFduhl5E
d5cmRo+/k1jIcJs5IGTtGjCpv0m5RutpcY6gn4ITP6US0RpYlaE55Apo6N5WbeBe
rD/tO9u1ku/9C9kepBSiHJKcYV2ql52+Xb5PX3gAr1pPeV5tGuK6kyhpDG6e25G+
1ZuElPdFlhRxTin0wdgipvOT2Bju1711LH9Z2/woXwrK//V4UaCxr8SgnkgqNeBe
Q8YP2p1Hii8hLod5/EBp8ZBi/u93eygw8BD9Mik5b+aIBKSH1f062imDEKs+mVC8
w6QAMqWBmfXVP53pSWhE
=ERCf
-----END PGP SIGNATURE-----

I managed to find a simple solution to this. I used rsync from the WORK server to sync a directory on SERVER1 to a directory on SERVER2. The trick was to use an alternative port for rsync, and not the default port. The command looks something like this:

rsync -avP --rsh=‘ssh -p22’ SERVER1:directory SERVER2:directory

Here SERVER1 and SERVER2 have been defined in ~/.ssh/config like descriped in the tutorial mentioned earlier. This command does exactly the same thing:

rsync -avP --rsh=‘ssh -p22’ username@ip-of-SERVER1:directory username@ip-of-SERVER2:directory

Here we are using port 22 for rsync.

Thanks to you all for your replies :slight_smile:

regards
Frímann

I just realised that the rsync command I mentioned earlier doesn’t actually work :frowning:

I realized that rsync can only sync a remote server to a local directory, but it cant sync two remote servers.

So when I executed the command:

rsync -avP username@SERVER1:directory username@SERVER2:directory

I was actually syncing the contents of SERVER1 to a local directory.

It seems that I’m almost back to square one here :slight_smile:

I’we also tried to copy straight between SERVER1 and SERVER2 using scp:

scp SERVER1:file SERVER2:.

But I get the message:

Host key verification failed.
lost connection

Which is very strange since I can copy local files both to SERVER1 and SERVER2 without problems, f.x. like this:

scp localfile SERVER1:.
scp localfile SERVER2:.

So the only possibility I see it to write some sort of script to do this. A script that runs on WORK and copies files from SERVER1 to a local directory on WORK, and then copies them to SERVER2.

The biggeset problem with this is my harddrive limitation on the WORK server, which is around 1-2 GB’s I think. Is there any possibility to copy only part of files using scp or sftp?

Also if anyone has any better suggestins I’m all ears :slight_smile:

regards
Frímann

But the

I tried this command now on a different set of servers:

scp username@source_server:file_to_transfer username@dest_server:

And I got the same message:

Host key verification failed.
lost connection

Although all the servers can ssh into each other without trouble

I even tried deleting all the known_hosts and authorized_keys files on all the servers. When I did that I was asked for the password for source_server, and then I got the same message as before. So scp doesn’t even try to connect to dest_server. I’m confused here. Anyone have a clue?

Oh and btw, if I do it the other way around, switch the dest_server and source_server, I get no errors.

Very interesting. I stronly suspect that this is something that can be fixed with the proper line in .ssh/config :slight_smile: