10

Is there a way to get a file from a remote server you are connected to via ssh, by simply running a command like get file within the ssh session? Is there a method, or pre-existing tool, to do this? Its slow to copy and paste the path into an sftp command in another terminal, so it'd be preferable to have a quick method like this.

Improve this question
4
  • iterm2 allows this with their utilities: iterm2.com/documentation-utilities.html it's a mac termianl, not sure if there's similar for linux
    – RiaD
    Mar 31 at 14:52
  • it2dl The it2dl program downloads files. This is useful when you are ssh'ed to a remote host. The downloaded files are placed in your Downloads folder.
    – RiaD
    Mar 31 at 14:52
  • 1
    Check zssh. I wanted to test it and to my surprise konsole tried to intercept the file I was about to send with sz. (This way I discovered a useful feature of the terminal emulator I use daily. Yay!)
    – Kamil Maciorowski
    Mar 31 at 15:48
  • lrzsz (zmodem) and an ssh client that integrates it nicely, such as securecrt on windows, where sz and rz automatically trigger a GUI file picker
    – Dark
    Apr 2 at 13:40

4 Answers 4

Reset to default
13

If you can connect to the original client host via SSH, then you can use the scp command to copy the file. An example session could look something like this.

barry@earth:~$ ssh pi@raspberrypi
pi@raspberrypi:~$ scp secrets.txt barry@earth:secrets.txt
pi@raspberrypi:~$ exit
barry@earth:~$ ls secrets.txt
secrets.txt
barry@earth:~$

Of course, as you seem concerned with speed and ease, you could do something fancy with aliases or something to wrap up the invocation to scp into something memorable.

Improve this answer
5
  • 1
    instead of aliasing the commands, use .ssh/config to alias the server details. also, keep in mind you can actually tab-complete with scp (it is slow, since it runs over ssh, but it works!)
    – Capi Etheriel
    Mar 31 at 13:20
  • 7
    Your first sentence is confusing enough to be misleading. What you mean is "If you can connect to the original client host via ssh". A naive user reading your answer would assume you mean "if you can connect to the server via ssh", but you are referring to the case where BOTH hosts are running reachable ssh servers
    – thegreatemu
    Mar 31 at 20:53
  • 1
    If one knows the location of the file, SSH:ing in first is unnecessary. Simple scp user@system:/path/to/file path/to/destination/ will copy file from the remote system to destination/ folder.
    – Peregrino69
    Apr 1 at 14:56
  • @Peregrino69 Yes, of course, it's just an example. I tried to make the example similar to what I imagined OP was doing, from his description.
    – Героям слава
    Apr 7 at 4:47
  • @thegreatemu that's a good point, I'll change it.
    – Героям слава
    Apr 7 at 4:47
9

No, there isn't. SSH does not have a "client filesystem access" channel the way RDP does.

Though, there might be terminals that have built-in support for the ancient BBS file transfer protocols such as Xmodem/Zmodem (HyperTerminal is one of them, but it's not a very good terminal emulator; I think there are PuTTY forks that support Xmodem). Running the sz command on the server would initiate a file transfer over the terminal, which the terminal would recognize and ask you where to save the file.

It might be possible to have a custom get command that would connect back to the client machine (via another SSH session) and upload the file from the remote system to local one, e.g. by getting your IP address from $SSH_CONNECTION or by using a prepared "remote forward" -R tunnel, but it's not exactly convenient as a general solution. (It works in specific environments such as your own personal systems, but not when SSH'ing to various random customer servers.)

Don't forget that the sftp client on Linux supports tab-completion for remote paths. You might prefer lftp, which is another SFTP client that has a few handy things such as the 'edit' command (which automatically gets a file, runs the local editor, then puts it back).

A different workflow involving sshfs (SFTP-as-a-filesystem) might be a solution. For example, if you often SFTP files locally just to edit them and put them back, that can be replaced by directly editing the file through an sshfs mount. (Or, of course, editing everything locally and only deploying to the server via Git...)

Your Linux desktop environment may support SFTP in the graphical file manager, using sftp:// URLs, so that you could directly navigate to the file you need, bookmark the location, etc. (In GNOME it is even possible to start an interactive SSH terminal at "current location".)

Between personal systems, NFS can also be used (in both directions – editing server files locally, and having the server copy files back to the client). For example, on my personal environments, I have set up automatic /n/<hostname> NFS mounts to home directories on all machines, so I can just cp foo /n/laptop and it appears in my laptop's home directory. (Wouldn't work on a corporate environment, but interesting to think about.)

(The latter is actually similar to how RDP's file redirection works – if you RDP into a server, you can access the special \\tsclient\C network share that leads back to the client's C: drive, piggy­backing on the RDP connection. No such thing in SSH, unfortunately.)

Improve this answer
0
0

I also wondered why some builtin file transferring capabilities lack in SSH.

What I do if I need exactly this for rather small files (in some cases using scp or sftp is not possible):

I pipe the file to base64:

base64 < file

(copy the garbage-looking text)

then, on another terminal, on another machine:

base64 -d > file

(paste the encoded content from above)

then: ctrl-d

Done.

I have a copy of the file.

Of course, other encodings can be used, but base64 is compact enough, tolerant to line end differences, spaces and character sets, copy-paste artifacts and so on.

It simply works.

Improve this answer
5
  • 1
    Often the output will scroll out of your terminal if you do that. To make this less likely, you can compress the output before base64'ing it: cat file | gzip - | base64 and base64 -d | gunzip - > file.
    – Danya02
    Mar 31 at 17:22
  • @Danya02 Why cat and not gzip < file?
    – Neil
    Apr 1 at 0:03
  • 2
    @Neil It's what's called a useless use of cat, but I prefer writing it that way because it means the pipeline always goes from left to right; with the left-arrow, instead of cat (1) | (2) | (3) | (4), you have (2) < (1) | (3) | (4), which to me is needlessly confusing in exchange for dubious benefits.
    – Danya02
    Apr 1 at 7:25
  • 3
    @Danya02 Here, like in most cases, you can achieve "from left to right" without cat: <file gzip … | …. See the second part of this answer.
    – Kamil Maciorowski
    Apr 1 at 16:30
  • You don't even need the <, you can simply do gzip -c file | base64.
    – terdon on strike
    Apr 2 at 13:25
-1

TRUE DESPERATION and MORE WORK FOR YOU: netcat or nc especially with -c,
-e name,-K keyfile, -o staplefile, -R cafile, -T option and -Z peercertfile . example from manpage:
nc localhost 25 << EOF
HELO host.example.com
MAIL FROM:user@host.example.com
RCPT TO:user2@host.example.com
DATA
Body of email.
.
QUIT
EOF

Improve this answer
2
  • 1
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Apr 1 at 14:28
  • There are better ways to mail something to yourself, like sendmail or wrappers for it. netcat to localhost port 25 is super hacky.
    – Peter Cordes
    Apr 1 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.