2

From my local machine I can copy files from a remote machine

scp remote:/some/file/path ~

But what if I'm already SSHed into the remote machine? Can I do something like this

ssh remote
cd /some/file
scp path local:~

where local somehow resolves to the machine I SSHed from. This would of course be possible if the local machine is running an SSH server and the remote is configured to connect to it, but that isn't always an option.

Is something like this possible?

Max
  • 129
  • 3
    Have you tried scp's ugly little sister, sftp? – Andreas Wiese Apr 23 '14 at 19:56
  • 1
    I second the sftp suggestion. However I would also suggest not using really complicated & annoying paths. If they are annoying to type why type them? Name them something easier to type. Finally, I would suggest using single quotes instead of double backslashes because double slashes are harder to read. Instead of ...\\\ \\\&..., you could just do '...\ \&...'. See how much more readable that is? – jw013 Apr 23 '14 at 20:18
  • This is one specific use case, and I appreciate your suggestions for alternatives but I'm really looking for an answer to my specific question. – Max Apr 23 '14 at 20:33
  • I think @AndreasWiese suggestion is an answer to your question :) – Ramesh Apr 23 '14 at 20:53
  • Take a look at the accepted A to this AU Q&A: http://askubuntu.com/questions/13382/download-a-file-over-an-active-ssh-session. Gilles A is also a method that I've used to do what you want to0. It's the 2nd A on that same Q. – slm Apr 23 '14 at 20:54
  • 1
    There are several approaches highlighted on this U&L Q&A as well, specifically Gilles A: http://unix.stackexchange.com/questions/4552/copy-text-from-one-terminal-into-another/4557#4557 – slm Apr 23 '14 at 20:58

1 Answers1

2

As mentioned in the comments, I'd suggest using sftp:

$ sftp remote
user@remote's password: 
Connected to remote.
sftp> pwd
Remote working directory: /home/user
sftp> cd /etc
sftp> get fstab
Fetching /etc/fstab to fstab
/etc/fstab                                 100%  435     0.4KB/s   00:00    
sftp> 

Another, rather… hacky approach would be abusing port-forwarding capabilities of SSH, combined with nc (a.k.a. netcat). nc is the "swiss army knife of networking" (the smaller one… there's also socat, which is more the MultiTool® ;) — a kind of cat with networking capabilities.

The idea: tell ssh to forward a remote port of your remote machine to a local port on the client side and use this connection to pipe along your data using nc:

  1. Connect to $remote establishing remote port forwarding:

    client:~> ssh -R 8888:localhost:8888 $remote
    

    This establishes a normal connection to $remote, but additionally tells ssh to listen on port 8888 on the remote side. If something connects to port 8888 on the remote side, ssh will open a connection to localhost, port 8888 on the client side (thus, the client) and forward anything sent to remote-side's port 8888 to this port.

  2. Listen on client side's port 8888 (so ssh has something to connect to), using nc. We pipe the output (client-side) nc receives into tar, since we'll send a tar stream to it later:

    client:~> nc --recv-only -l -p 8888 | tar xvf -
    
  3. On the remote side, change your current working directory anywhere you wanted.

  4. If you're on the right spot, use tar to gather the files you want to copy and pipe them into (remote-side) nc, connecting to the remote-side opened port:

    server:~> cd /path/with/those/files
    server:files> tar cvf - ./some/files | nc --send-only 127.0.0.1 8888
    
  5. Magic™ happens.

Note: There are at least three different implementations of nc out there, all with a slightly different syntax; --send-only and --recv-only are AFAIK only supported by netcat6. If you've an implementation that does not support those (or similar) options, you'll have to look whether tar exited and hit Ctrl-C on the sender side. nc usually waits forever and does not handle EOF (--send-only tells it to do and automatically close the connection).

Another note: You could also use nc directly, but by using ssh's port forwarding, your data goes through the SSH connection, avoiding two problems: first, your data is still sent encrypted, and second, this also works if your client is behind a NAT'ing firewall or otherwise not directly reachable from your $remote.

Andreas Wiese
  • 10,400
  • Or set the port forward to connect to localhost:22 and then you can scp -p 8888 file localhost:, and not have to get out the nc swiss army knife :) – Drav Sloan Apr 24 '14 at 02:05