defeated by optmisation! - SSH

This is a discussion on defeated by optmisation! - SSH ; I have a situation where, due to VPNs, routing, gating, etc machines 'A' and 'Z' can both be seen from machine 'M', but machine 'A' cannot see machine 'Z'. I do NOT have access/authority to change this. I do have ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: defeated by optmisation!

  1. defeated by optmisation!

    I have a situation where, due to VPNs, routing, gating, etc
    machines 'A' and 'Z' can both be seen from machine 'M',
    but machine 'A' cannot see machine 'Z'.

    I do NOT have access/authority to change this.

    I do have user level access and logins
    for all 3 machines.

    In order to transfer data, I logged on to machine
    'M' and used scp thus:

    scp user1@A:/path/file.txt user2@Z:/path

    The command failed.

    A little probing revealed that scp had
    attempted to initiate a direct copy from A to Z,
    which is not (in fact) possible.

    Now, I can see where this optimisation is desirable.

    If the links between M and A,Z were slow,
    but the link between A and Z were swift,
    what SCP is doing is very fine

    (e.g. user on a remote dialup initiating
    transfer between 2 servers)

    Is there a way for me to (conveniently) proceed,
    or do I require a "new" flag?

    BugBear

  2. Re: defeated by optmisation!

    On 2007-10-19, bugbear wrote:

    > scp user1@A:/path/file.txt user2@Z:/path
    >
    > A little probing revealed that scp had
    > attempted to initiate a direct copy from A to Z,
    > which is not (in fact) possible.


    on M you could start 2 ssh commands piped together
    ssh user1@A tar cf - /path/file.txt | ssh user2@Z tar xvof -
    (which would be nicer if you could avoid the absolute pathname)

    See the rsh and tar man pages for issues with this approach -
    involving buffering and standard streams.

    Unfortunately you cannot do
    rsync -e ssh -tvv A:/path/ Z:/path/

    --
    Elvis Notargiacomo master AT barefaced DOT cheek
    http://www.notatla.org.uk/goen/

  3. Re: defeated by optmisation!

    bugbear writes:

    >I have a situation where, due to VPNs, routing, gating, etc
    >machines 'A' and 'Z' can both be seen from machine 'M',
    >but machine 'A' cannot see machine 'Z'.


    >I do NOT have access/authority to change this.


    >I do have user level access and logins
    >for all 3 machines.


    >In order to transfer data, I logged on to machine
    >'M' and used scp thus:


    >scp user1@A:/path/file.txt user2@Z:/path


    >The command failed.


    >A little probing revealed that scp had
    >attempted to initiate a direct copy from A to Z,
    >which is not (in fact) possible.


    Yes, that is what it does.



    >Now, I can see where this optimisation is desirable.


    >If the links between M and A,Z were slow,
    >but the link between A and Z were swift,
    >what SCP is doing is very fine


    >(e.g. user on a remote dialup initiating
    >transfer between 2 servers)


    >Is there a way for me to (conveniently) proceed,
    >or do I require a "new" flag?


    scp A:filename /tmp/filename
    scp /tmp/filename Z:/path/to/filename



  4. Re: defeated by optmisation!

    Unruh wrote:
    >
    >> Now, I can see where this optimisation is desirable.

    >
    >> If the links between M and A,Z were slow,
    >> but the link between A and Z were swift,
    >> what SCP is doing is very fine

    >
    >> (e.g. user on a remote dialup initiating
    >> transfer between 2 servers)

    >
    >> Is there a way for me to (conveniently) proceed,
    >> or do I require a "new" flag?

    >
    > scp A:filename /tmp/filename
    > scp /tmp/filename Z:/path/to/filename
    >


    Yes, that works; but I want (not need, clearly)
    the convenience of "cp" including the -r option,
    and the "destination is a directory" option.

    BugBear

  5. Re: defeated by optmisation!

    all mail refused wrote:
    > On 2007-10-19, bugbear wrote:
    >
    >> scp user1@A:/path/file.txt user2@Z:/path
    >>
    >> A little probing revealed that scp had
    >> attempted to initiate a direct copy from A to Z,
    >> which is not (in fact) possible.

    >
    > on M you could start 2 ssh commands piped together
    > ssh user1@A tar cf - /path/file.txt | ssh user2@Z tar xvof -
    > (which would be nicer if you could avoid the absolute pathname)
    >
    > See the rsh and tar man pages for issues with this approach -
    > involving buffering and standard streams.
    >
    > Unfortunately you cannot do
    > rsync -e ssh -tvv A:/path/ Z:/path/
    >


    Following your post, a colleague thought
    along these lines...

    > The full path problem can be overcome by
    > ssh user1@A "cd /start/place; tar cf - ." | ssh
    > user2@Z "cd /dest/place; tar xvBf -"
    >
    > Alternatively the -C flag can be used on the source tar, this is
    > particularly useful if there are multiple source directories.
    > ssh user1@A "tar cf - -C /start/place1 dir1 -C /start/place2
    > dir2" | ssh user2@Z "cd /dest/place; tar xvBf -"
    >
    >
    > One problem encountered was that at least one of the machines
    > needs to trust M, because otherwise both passwords are prompted
    > for simultaneously.



    BugBear

+ Reply to Thread