10

I SSH tunneled from my local Ubuntu machine to a remote Ubuntu machine and I want to copy/move files from the remote Ubuntu to the local one.

I need to do that from within the SSH session (i.e, from within the remote Ubuntu).

These didn't work:

scp [remote-source] [local-destination] # Which is actually:
scp /home/user/files_to_depart/file1.txt /home/user/files_that_arrived/file1.txt

How can this otherwise be done?

  • Why within the remote session? Since SSH already works, you could just open a new terminal and run scp form there. – muru Apr 10 '17 at 01:47
  • 1
    It is most comfortable when done from the remote session: You just run a script or paste an heredoc from within this session and you are done: Now need to exit to the previous session or opening another window of a local session... –  Apr 10 '17 at 22:11
  • I don't see what heredocs have to do with anything, but you do have an obsession with those. – muru Apr 10 '17 at 22:23
  • No, it's just a comfortable way to paste multi-row code in place, without storing small script files inside the system bur rather copy them from a single script vault file. I just gave that as an example... –  Apr 10 '17 at 23:00

4 Answers4

11

nullmeta's answer is completely valid, and perhaps nullmeta will edit to provide the clarification you're looking for. I'm posting a separate solution altogether to account for the situation where it may be difficult because of network structure (think NAT firewall) to simply ssh back into the local system.

Say you have two computers, ComputerA and ComputerB. ComputerA is your local workstation. ComputerB is a remote machine that you can access via ssh.

Scenario 1: If ComputerA is not behind an NAT firewall

This is a swift and easy solution, combining scp and ssh (scp performs a secure copy using ssh protocols). It requires you to have an ssh server (and client) installed on both ends (computerA and computerB).

To use this solution, run from ComputerB: 

scp /path/to/file/on/ComputerB ComputerAUser@ComputerA:/path/to/dump/file/on/ComputerA

Scenario 2: If ComputerA is behind an NAT firewall

In this scenario, you would typically need to configure port-forwarding in the NAT firewall. However, you may not always have access to make these kinds of changes. In this case, you can configure your ssh tunnel from ComputerA -> ComputerB such it can tunnel reverse connections as well.

When establishing the ssh connection ComputerA -> ComputerB, do so with the -R option in the following manner. ssh ComputerBUser@ComputerB -R 2222:localhost:22 where ComputerBUser is the username for the account on ComputerB being authenticated and 2222 is a free port on ComputerB. We'll use this port to reverse-tunnel back to ComputerA from ComputerB.

Now from ComputerB, you can issue the scp command in the following manner to copy files from ComputerB -> ComputerA where ComputerAUser is your username on ComputerA: 

scp -P 2222 /path/to/file/on/ComputerB ComputerAUser@localhost:/path/to/drop/file/on/computerA

What's happening here? It looks like we are simply telling ComputerB to send the file back to itself because we're passing localhost instead of ComputerA. We are indeed telling scp to pass the file back to ComputerB, but to port 2222. All connections to port 2222 on ComputerB get forwarded to port 22 (default ssh port) on ComputerA. Thus, by tunneling backwards over the existing ssh connection, it doesn't matter that ComputerA is behind an NAT firewall.

Scenario 3: perform the file copy from ComputerA

Or rather than trying to do it from ComputerB, you can just run the scp command from ComputerA.

scp ComputerBUser@ComputerB:/path/to/file/on/ComputerB /path/to/dump/file/on/ComputerA
b_laoshi
  • 4,660
  • 4
  • 25
  • 46
  • In regards to solution 1 (B->A): On ComputerAUser@ComputerA:/path/to/dump/file/on/ComputerA Do we need I don't have an SSH server and I don't want people to try to login to it). Must I use the IP of the computer A in the reverse SSH command? –  Apr 10 '17 at 04:57
  • 1
    @Benia, if you don't have an ssh server configured on ComputerA, then Scenario 3 is your only real option. You could use netcat and the -R switch in ssh, but that's a lot of hassle (requires running netcat on both machines for file transfer) and makes less sense than the scenario 3 approach. Scenario 3 does not require ComputerA to have an ssh server installed. – b_laoshi Apr 10 '17 at 06:14
  • Indeed, but it does require leaving everything in scenario 3, opening another local session, and then mining the data with an heredoc or a script (because it has a few lines).... That's non minimal by means of doing everything in one place and indeed scenario 3 (or scenario 4 - netcat) seems the most minimal solutions in that sense. BTW, please correct me if I'm wrong @b_laoshi, but there isn't a big different between file transfer between both ends with an SSH server or with netcat? –  Apr 10 '17 at 22:03
  • 1
    @Benia, There's a huge difference. Of note, netcat is not encrypted. Tunneling over SSH addresses that issue since SSH provides encryption. From the sound of it, netcat probably isn't going to suit you either because you need to start netcat listening on ComputerA before you can send a file from ComputerB for EACH file transfer. This can be automated with a script running in a loop on ComputerA. If that's something you want more feedback on, make a new question to that affect, and bump me here and I'll elaborate more. Have you considered using screen? – b_laoshi Apr 11 '17 at 01:46
  • I didn't know screen basically but I would prefer something direct at the moment, so I guess Setting up an OpenSSH server is the best option for me. It also best because it gives me encryption which I also desire and it's good you brought that up. –  Apr 11 '17 at 02:34
  • @Benia, screen allows you to create and switch back and forth between multiple interactive shells within the same terminal session. Thus, with a couple keyboard strokes, you can easily switch back and forth between your remote and local sessions without have to disconnect/reconnect. It can be super handy if you're not using a GUI. – b_laoshi Apr 11 '17 at 03:11
  • So much thanks! BTW, I guess that tmux (which I use now mainly for sleep sessions on background) isn't like Screen by the sense it runs only on the current session (local or remote). –  Apr 11 '17 at 03:30
  • BTW @b_laoshi, about scenario1, is there a way to send 2 files at once? (I can't try that now but will try anyway soon with scp /file1 /file2 user@ip:/somepath. –  Apr 14 '17 at 13:29
  • @Benia, yeah, that should work. Or you could simply tar them and send the tar file. – b_laoshi Apr 16 '17 at 13:06
  • Using Scenario 2 I get this error: kex_exchange_identification: Connection closed by remote host – distante Aug 14 '20 at 18:17
3

If you need an easy way to browse the file system of a remote machine and copy certain files to the local machine (and vice versa) you can use SSHFS.

Description

  • From man sshfs:

    SSHFS (Secure SHell FileSystem) is a file system for Linux (and other operating systems with a FUSE implementation) capable of operating on files on a remote computer using just a secure shell login on the remote computer. On the local computer where the SSHFS is mounted, the implementation makes use of the FUSE (Filesystem in Userspace) kernel module. The practical effect of this is that the end user can seamlessly interact with remote files being securely served over SSH just as if they were local files on his/her computer. On the remote computer the SFTP subsystem of SSH is used.

  • From apt show sshfs:

    sshfs is a filesystem client based on the SSH File Transfer Protocol. Since most SSH servers already support this protocol it is very easy to set up: i.e. on the server side there's nothing to do. On the client side mounting the filesystem is as easy as logging into the server with ssh.

Installation

sudo apt install sshfs

Unlike this guide I haven't done anything other on my Ubuntu 16.04. There is no fuse user group.

Usage

  1. Create an appropriate mounting directory, for example:

    mkdir ~/sshfs-mount-point

  2. Mount a remote path:

    • Mount a remote path, when you using the default ssh settings:

      sshfs user@IP:/remote/path ~/sshfs-mount-point

    • Mount a remote path, when you using custom ssh settings:

      sshfs -o IdentityFile=/path/to/id_rsa,port=2222 user@hostname-or-IP:/remote/path ~/sshfs-mount-point

    • Mount a remote path, when you have properly configured ~/.ssh/config file:

      sshfs hostname:/remote/path ~/sshfs-mount-point

  3. Unmount the remote path. There are two ways:

    • fusermount -u ~/sshfs-mount-point

    • sudo umount ~/sshfs-mount-point

Usage according to the question

  • While you are ssh connected from machine A to machine B, and you are able to establish an ssh connection from B to A. You can use one of the above approaches to mount a folder from A on B. Then use cp, rsync or mc to copy your files.

  • While you are SSH connected from machine A to machine B, and you are not able to establish an SSH connection from B to A. You can create dedicated folder into machine B and copy your files into that folder. Mount this folder on machine A and move these files where you want. You can set cronjob or bash script which handle this task.

Community
  • 1
pa4080
  • 29,831
2

Without being in a SSH session you would want to use

scp user@remotehost:/file/to/copy /local/destination

If your local machine has sshd running and the port open, while in the ssh session you can 

scp /remote/file user@localmachine:/destination/file

This link has some workarounds https://unix.stackexchange.com/questions/2857/ssh-easily-copy-file-to-local-system

Edit: I apologize for any confusion, the easiest and most efficient way is going to be opening a second terminal and running the first scp command I mentioned.

Community
  • 1
nullmeta
  • 446
  • 1
  • 3
  • 9
  • 1
    I am looking for a way to do so from the SSH session... –  Apr 10 '17 at 01:13
  • if you have ssh enabled on your client while you're in the session you could try {scp /remote/file user@client:/destination/file} or use sftp or sshfs to mount the file system – nullmeta Apr 10 '17 at 01:21
  • On the client? Can you please edit the answer with an explanation on how you would do that in your end? –  Apr 10 '17 at 01:28
  • You're basically using the scp command in reverse. Rather than scp from remote to local, since you're already in the other machine you're "local" computer is now "remote" It was a suggestion based off of this post http://unix.stackexchange.com/questions/2857/ssh-easily-copy-file-to-local-system There's really no easy way to transfer files while in a SSH session. I would say it would be easier to open a second tab/terminal and use scp. Or in my case, I can SSH into my file server so do admin tasks, but for file stuff I have a NFS and a SMB share. – nullmeta Apr 10 '17 at 01:34
  • Sorry, I think I missed if you finally say it is possible or not. Please consider publishing a new answer or editing this one so it would explain and example scp from Y->X instead from X->Y. I also consider offering bounty over this. –  Apr 10 '17 at 01:38
1

To move files from computer to computer over a network, you use the scp utility (scp stands for secure copy). ssh is only used for remote login access.

Since you have already successfully logged in to another computer on your network, you can simply copy your files to your local machine from there, but you're going to need to get an ssh deamon running on your local machine. So, install it first:

$ sudo apt-get install openssh-server -y

Make sure that it's up and running (the green light thing shows that it is):

$ systemctl status sshd

enter image description here

Put all the files on the remote machine that you want to copy over to your local computer in a separate directory. Then, use this command:

$ scp -r [DIRECTORY] [USER]@[IP_ADDRESS]:~/Downloads

-r means that the directory along with all its contents is going to be processed recursively. In simple terms, this means that it's the option you're going to use every time you want to copy a directory containing files. [DIRECTORY] is the path to that directory. [USER] is the user on your local machine. [IP_ADDRESS] is the IP address of that machine. The stuff after the : is where you want your files to be saved on your local machine. In this case, it's the Downloads folder.

This is what this process looks like in reality:

enter image description here

misha
  • 952