Transferring files to someone else via sftp

file-transferscpsftp

Someone else is giving me a dataset that is too large to send via email, Dropbox, etc., so I'm thinking we can use sftp or scp. But how will she be able to do this without my giving her the password to my machine? This is a one-time transfer of data, so I'd rather not go through a lot of trouble — if it's too much work I'll just give her my password and then change it when she's done transferring the files.

Best Answer

Is your machine accessible over the Internet?

The first hurdle is that your machine may not be accessible over the Internet at all!

Most client machines cannot be accessed directly over the Internet because they don't have a public IP address. It's like having a phone that can call out, but can't be called. This came about mainly because there's a limited supply of IP addresses; unless your ISP supports IPv6 or you have a very atypical configuration, you have a single IP address at home, and that's the address of your home router. Your computers can make outgoing connections because the home router provides NAT functionality.

Most home routers can be configured to allow incoming connections to be routed to a particular machine on the local network. To allow incoming SSH connections, route port 22 to your computer. See your router's documentation for how to do this.

If you're unlucky and your ISP doesn't give a public IP address, you won't be able to make incoming connections. To check whether you have a public IP address, connect to your router's administrative interface and check whether its external address is in the private range (internal addresses are in the private range except in atypical configurations).

Giving shell or file access to your machine

The (relatively) easy way to give someone access to your machine is to create a user account for them. With an ordinary user account, they'll be able to see a lot of things, but they won't be able to modify your files (unless you went out of your way to make them world-writable), and they won't be able to see the files that are in a private directory (drwx------ permissions).

For better security, configure the account to be usable only to manipulate files in a particular directory over SFTP. This is a bit more difficult (I kind of expected OSX to provide an easy-to-use GUI for that, but apparently not); see Create a remote only user in OS X? or How to set up an SFTP server on a Mac & then enable a friend to upload files to it from their iPhone, iPad, or other iDevice for instructions.

You'll need to enable remote access. There is an OSX knowledge base entry for that. Enable only the one user who is supposed to have remote access. Do not enable remote access for an account that may have a weak password!

Set a random password on the account and tell them to copy-paste it and save it in a file. Don't expose a machine with weak, human-chosen passwords to the Internet. You can use the following command to generate the password:

</dev/urandom tr -dc A-Za-z0-9 | head -c 16; echo

Transfering files piece by piece

So yeah, sending files over the Internet is still difficult.

The low-tech solution is to use one of the many file sharing websites. They make their money through ads, so don't even think of visiting one without an ad blocker, and be very careful where you click because they're likely to try to serve you malware. After downloading a file, check that it's the right file: calculate its SHA-2 checksum with

sha -a256 /path/to/file

on OSX, sha256sum /path/to/file on Linux.

How to know where the file is?

a) Use SSH in another terminal

Just open a second terminal, SSH to bar, find your file and copy/paste the path to the first one.

b) Use SFTP

SFTP (not related to FTP nor FTPS in any way!) is implemented in OpenSSH and is available by default. Just SFTP to the server and use the FTP-like commands to find you files and get them.

c) Use a GUI

Filezilla or Nautilus for instance can browse remote SFTP/SSH shares.

d) Set up certificates

When you set up certificate connection, you can do tab completion on the local side as well as on the remote side! For instance, with your buzz example, you can do:

bob@foo$ scp bob@bar:/guest/[tab][tab]

and wait a little for the list of files contained in the remote /guest/ folder.

How to set up SSH with certificates?

a) If not already done, generate your personal RSA key pair

If you've installed OpenSSH client, you can do it by typing

bob@foo$ ssh-keygen -t rsa

(look at the manual or online for all the available options). It may ask you for a password. This is not your local account password but an optional password that can be used to encrypt the private key you are about to generate.

Actually, you will generate 2 files:

/Users/[yourusername]/.ssh/id_rsa
/Users/[yourusername]/.ssh/id_rsa.pub

The first one, *id_rsa* ought to be private. By default, ssh-keygen will do everything it can to avoid making it public (using filesystem access permission). That's why it will also ask you for an (optional) password. Don't be too paranoid with that, but just remember *id_rsa* == personal key == private. This key should never ever leave your computer.

The second one is public. It requires a huge amount of computer power to get back your private key from this public certificate (I really mean HUUUUUUGE). This is perfectly safe to share it with the whole world. Even in the very unlikely event that the NSA or the likes really want to spend millions of dollars cracking your public key, your macbook will still be safe … (or not. Thinking about it, if someone wants to spend that much, you are in trouble :)

This public certificate is actually what you will put on the remote server bar.

b) How do I put my public certificate on the server?

Two options.

Use ssh-copy-id if available: bob@foo$ ssh-copy-id bob@bar. Done.
If it is not, copy ~/.ssh/id_rsa.pub to bar:

bob@foo$ sftp ~/.ssh/id_rsa.pub bob@bar:pub_cert

(here, you copied your public cert id_rsa.pub from .ssh/, in your personal ~ folder to the remote computer bar in the home folder of the user bob. This is the default. Also note that id_rsa.pub has been renamed to pub_cert in the process. I used sftp just to show you that it can be used exactly as scp).

Now, we shall copy this certificate to the right location:

bob@foo$ ssh bob@bar

Now you are in bob's personal folder in bar.

bob@bar$ cat pub_cert >> .ssh/known_hosts

(here, you displayed the content of pub_cert with cat. But instead of printing it to the screen, you redirect this output to a file: .ssh/known_hosts. Note that a redirection with > would mean "replace the content of the file with this stream" while >> means "append the stream at the end of the existing file").

c) Result?

Now you can scp/sftp/ssh to bar as much as you want without having to provide a password. You can also autocomplete local and remote paths using the [tab] key.

d) What about my mac security?

With this way of doing this, you don't even need a running SSH server on your computer. Only an SSH client (the scp/sftp/ssh programs). This is safe for you even if bar is compromised.

e) What did I do exactly with these keys/certificates?

First you generated a couple of files: a private key and a public certificate. You can do a lot of things related to security and authentication with them. But in our case, with a fair bit of simplification, these are used this way:

When you try to connect to bar, you will advertise that you've got a certificate that you can use for the connection. bar will inspect various locations in the system, including ~/.ssh/known_hosts. It will find the certificate that you advertised and use it to send you encrypted data.

Actually, public certificates can encrypt stuff!

Now this is great, but how can foo understand that? Using your private key.

Private keys can decrypt stuff encrypted with the corresponding public certificate!

This is what is called asymmetric encryption.

Then, basically, the server will send a complicated password to you encrypted with your public certificate. You will receive it, decrypt it with your private key and start to use it to encrypt data with the server both ways.

Now, what if you really really want to do the things your way and SCP back to foo?

You are just asking for troubles. But to mitigate the effect of a possible compromission, you can set up a chrooted SFTP-only server. scp and ssh won't work any more, but sftp, Filezilla and stuff are gonna work.

ref: https://www.allthingsdigital.nl/2013/05/12/setting-up-an-sftp-only-account-with-openssh/