Transferring file to local machine when SSHing into a foreign box

[Peter Stuge]

Dotan Cohen wrote:
> As we have described it, the cpLocal feature would work something
> like this:
> 
> me at local:~$ ls
> file1 file2
> me at local:~$ ssh anotherMe at remote
> anotherMe at remote:~$ ls
> document1 document2
> anotherMe at remote:~$ cpLocal document1
> 
> ----------------------------------    <-- Here opens a "VIM-window" (see above)
> | me at local: Download document1?  |
> | [y/N/r/l]?                     |     <-- 'r' is Rename, 'l' is Choose Location
> 
> anotherMe at remote:~$ exit
> me at local:~$ ls
> document1 file1 file2
> me at local:~$

Thanks for answering my question about user interface. Unfortunately
it seems that you are not so aware of how the systems you use
actually work, and your proposal further does not address the very
important concerns about a remote system being able to control a
local client.

What you call the "VIM-popup" can not be created by the local SSH
client because it is not operating the terminal in a windowed mode.

You would have to study a bit of systems programming and with
particular focus on how applications can interact with their
controlling terminal to have a good background for finding a good
yet viable solution to this user interface problem.

And as I mentioned the above has a rather severe security problem.
The above can be abused by a remote server to make the logged-in
session unusable. Re-using your analogy with web browsers, think of
having a prompt enabled about approving cookies while navigating to
yahoo.com or cnn.com or some other site with lots of cookies and
banners. The client effectively becomes useless due to all the
prompts.

Now, the ~C command line was mentioned. This can be used to realize a
feature similar to what you ask for, but with some differences, and a
few technical problems to solve:

* difference: file transfer requests must always be initiated manually
  on the client in the ~C command line.
* problem: the client command line does not know the cwd of the
  remote shell, meaning that relative paths can not be used, which is
  somehow the whole point of this proposal.

A further variant on this is where on the remote system a file
transfer is prepared with the semantics of the proposed cp2local
command, but no transfer begins until an explicit ~C command (or
perhaps ~D for download) is entered on the client to actually perform
the transfer. There will be no notification from the client that a
transfer is pending, because in fact nothing is pending, the transfer
has only been prepared on the remote side, and will still be
initiated only by the client, just that on the remote server there is
now the marker running which identifies what should be transfered.

A technical problem still remains; how all this should work in terms
of the SSH protocol and what exactly the marker command (cp2local)
does.


//Peter