Tag Archives: mapped drive

Mapping Remote Storage Securely over the Internet with SSHFS

Sharing Datacenter Storage with Your Desktop

Let’s start with why you would want to map disk storage in a remote datacenter to your desktop or local server.  Some common benefits include:

1. Remote storage provides off site geographically different redundancy or backups in case of data loss (drive crash, fire, flood, etc.)
2. Datacenters usually have much faster bandwidth more suitable for doing large downloads, website mirroring, intelligence gathering, etc.
3. Remote disk storage in a datacenter gives you flexibility of accessing your data from anywhere in the world.
4. Remote disk storage mapped with SSHFS can be used just like a local drive (with some considerations for performance limitations1)
5. You can leave your important files safely on remote storage to prevent loss, theft or damage that is very common with portable devices (notebooks, tablets, smartphones, etc.)
6. When used in conjunction with a remote desktop computing environment, you can access data in simple way from your remote desktop environment.

Encryption – Keeping Your Data Secure

SSHFS transports data over an encrypted channel.  Your data is secured from prying eyes.  The encryption does have math computation overhead, so transfers typically will not be as fast as insecure transports like HTTP or FTP.

You want encryption to prevent theft of your data and generally to keep things private.  Many standards for professions require secure handling of corporate data, and protection of your customer’s data.  Plain text transfers therefore are not ever recommended.

What You Need to get SSHFS Running

1. A remote dedicated server or VPS (must have FUSE enabled2)
2. Debian Linux (others Linux varieties will work with some slight modification)
3. openssh-server (included and installed normally by default)
4. ssh-keygen (included with the ssh package)
5. sshfs
6. Root access

Terms:

localhost = the desktop I am working from
192.168.1.66 = the ‘remote’ server (in this case another computer on the same local area network (LAN) )

We will be mapping:
/media/remotestorage on localhost
to
/media/share on the remote server (192.168.1.66)

Becoming Root and Why to Limit Your Time as Root

Root is the supreme all controlling account in Linux.  Root has access to everything and can entirely destroy your server if misused.  Root access is needed to install software, add a user on the remote server and initiate the SSHFS connection.  In this tutorial, we will run sshfs as root as a proof of concept and so complexity is reduced. It is possible to get SSHFS operating as normal user, but that is further complexity. We note that anything with root access is a potential security issue.

To become root, find the terminal program and from within it:
localhost$ su
(then provide the root password)

If you do not have root access or cannot access such, we may be able to help you, please submit a support ticket to tmzVPS for assistance.

Create Your Public and Private Keys on Your Local Computer

Since we want to emphasize the security aspect of this, we are going to create a 4096-bit SSH key which is longer than default key size.  This creates crytographic complexity and is less likely to be vulnerable to security attacks (shorter key sizes are reported to be vulnerable from computation attacks)

localhost$ ssh-keygen -t rsa -b 4096
This creates a RSA key with a length of 4096.

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
f1:fb:9e:7a:30:1d:2f:06:e2:d0:f0:cc:ec:dd:af:df root@localhost
The key’s randomart image is:
+–[ RSA 4096]—-+
|                 |
|      .          |
|       B.        |
|      . Bo. .    |
|       +So.+ o   |
|        o +.= .  |
|          .+ o   |
|           ….. |
|          .+=o. E|
+—————–+

Step 2: Copy the public key to remote-host using ssh-copy-id

localhost$ ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.1.66

The authenticity of host ‘192.168.1.66 (192.168.1.66)’ can’t be established.
ECDSA key fingerprint is 66:d5:54:fd:4c:65:57:60:a9:eb:df:cf:d4:02:c2:5b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.1.66’ (ECDSA) to the list of known hosts.
root@192.168.1.66’s password: [provide your password here]

Step 3: Login to remote-host without entering the password

localhost$ ssh 192.168.1.66
Last login: Sun Aug 17 12:22:00 2014 from
[Note: SSH should NOT ask for password.]

root@192.168.1.66$ exit (to quit and return to the local computer)

Step 4: Create Local Directory to Map the Remote Storage To

root@localhost$ mkdir /media/remotestorage

Step 5: Mounting Remote Disk Storage over SSHFS

root@localhost$ sshfs username@remotehost:/media/share /media/remotestorage -o reconnect,compression=no,auto_cache,cache_timeout=5,transform_symlinks,allow_other,idmap=user,ServerAliveInterval=60,ServerAliveCountMax=3,StrictHostKeyChecking=no

DONE!

Now you are ready to work with your remote storage as-if it were local.  You can use common desktop tools including the file manager, rsync, cp, mv and rm.

When you are done using the drive or when it ceases to function properly, you will need to unmount the drive:
root@localhost$ umount /media/remotestorage

(sometimes this will fail due to other programs having that disk open, if that occurs: umount -l /media/remotestorage)

If you want to reconnect to your remote storage you do this:
root@localhost$ sshfs username@remotehost:/path/ /media/remotestorage -o reconnect,compression=n,auto_cache,cache_timeout=5,transform_symlinks,allow_other,idmap=user,ServerAliveInterval=60,ServerAliveCountMax=3,StrictHostKeyChecking=no

Future Related Blog Posts for SSHFS Use

We will add some posts in the future with common Linux tools usage included in major distributions that will enhance your use of remote storage and SSHFS. These will include rsync, duplicity, midnightcommander (mc), and basic command line file manipulation.


 

1 Remote disk storage will be limited to the bandwidth throughput between the local computer and the remote server.  Large data like audio and video will work for playback.  Editing of such will be extremely slow and may fail.

Typical text files, programming code and average office style documents will work usually very similar to local disk.

2 VPS environments in particular, OpenVZ requires your provider enables FUSE for SSHFS to work.

To enable FUSE: localhost$ modprobe fuse

Then check to see if it is enabled and working:
localhost$ lsmod | grep fuse

Output:
fuse                   52144  1

If FUSE is not enabled, ask your VPS provider to enable it and send them here:
link: http://wiki.openvz.org/FUSE