Transferring file to local machine when SSHing into a foreign box

[Ángel González]

On 14/05/12 18:01, Peter Stuge wrote:
> There are lots of
> variations, ~G(et) ~P(ut), ~S(end) ~R(eceive), and so on.
Sure, the actual option is not that important.

>> 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.
> Now you are reinventing an SFTP user interface. 
I think it's what they need.

> I think this may be going too far for OpenSSH. I think it's bad enough that the SFTP
> protocol has to be added to the ssh client..
Yes, it seems odd for the command line client provided by OpenSSH. It
may be possible to simply spawn sftp binary instead of implementing sftp
in ssh, though.

> I agree strongly that a filexfer channel is what must be used to
> actually perform the transfer.
>
> On Linux it's easy to get the shell's cwd: /proc/childpid/cwd but
> what is the situation like on other systems? Unless there is a
> portable solution this feature can't really be taken seriously
> IMO.
It seems to be platform dependant. Not all UNIX systems contain a /proc
fs, and even on those who have one, they might not have cwd. For
instance, Solaris seems to have a cwd symlink on /proc/pid, but it
apparently points nowhere :S

Also, even on Linux, take into account that we are not communicating
with the shell, /proc/childpid/cwd would have to be sent to local by
sshd. Also it may have a different view of the fs tree, I'm not sure if
it's under the same chroot as the shell.


> Also, this is a very different user interface than what was
> originally requested, and which I think is what makes the most sense.
> The question of how exactly the cp2local command will IPC to
> sftp-server what file to transfer remains to be solved.
Well, the interface was "You write something on the shell and the file
gets copied",
I just changed cp2local with ~F so that it would be trapped by the local
client :)

>> 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).
> IMO having an sftp client reuse a connection is a different feature
> than requested feature, whose purpose is to save time by being able
> to transfer one or more files from remote shell to local filesystem
> with very little user interaction.
Not at all. Half of the advantage of doing it from the open shell is
that they skip all the connection and authentication steps (specially if
they're using keyboard-interactive).