As mentioned in the comments, I'd suggest using
$ sftp remote
Connected to remote.
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
Another, rather… hacky approach would be abusing port-forwarding capabilities of SSH, combined with
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
$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
8888 on the client side (thus, the client) and forward anything sent to remote-side's port
8888 to this port.
Listen on client side's port
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 -
On the remote side, change your current working directory anywhere you wanted.
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
Note: There are at least three different implementations of
nc out there, all with a slightly different syntax;
--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
--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