Transferring file to local machine when SSHing into a foreign box

[Ángel González]

On 14/05/12 15:26, Peter Stuge wrote:
> 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.
I have been considering a variant of this, where you use a ~command.
~C is already taken, but if could be eg. ~F (for transfering *f*iles).

So when you typed ~F the client opens a sftp channel over the same
connection, and shows you a tree view of files and folders to
browse/download.
If you were on Windows, it could be equivalent to being on a PuTTY session,
and on that action getting a WinSCP spawned (reusing the connection).