Mounting Remote Directories With SSHFS On Ubuntu 11.10 - Page 2

Want to support HowtoForge? Become a subscriber!
 
Submitted by falko (Contact Author) (Forums) on Sun, 2011-12-04 22:16. ::

4 Using SSHFS As A Regular User

server1:

I want to use the local user falko now and mount the remote directory /home/someuser/backup, owned by someuser, to the local directory /home/falko/backup.

Create the user falko, if it doesn't exist:

adduser falko

server2:

On server2, create the user someuser, if it does not exist:

adduser someuser

Then become someuser...

su someuser

... and go to someuser's home directory where you create the backup (/home/someuser/backup) directory - make sure it's owned by someuser (it should be anyway as you are running these commands as someuser):

cd
mkdir ~/backup
chown someuser ~/backup

You can leave the someuser account if you like:

exit

server1:

First add falko to the fuse group:

adduser falko fuse

Now go to the falko account:

su falko

Create the local /home/falko/backup directory and make sure it's owned by falko (it should be anyway as you are running these commands as falko):

cd
mkdir ~/backup
chown falko ~/backup

Then mount the remote /home/someuser/backup directory to /home/falko/backup (still as user falko) - you can either use a relative or the full path for the remote directory:

sshfs -o idmap=user someuser@192.168.0.101:backup ~/backup

or

sshfs -o idmap=user someuser@192.168.0.101:/home/someuser/backup ~/backup

-o idmap=user makes that it does not matter if the local and the remote system use different user IDs - files owned by the remote user are also owned by the local user. If you don't use this, you might get permission problems.

If you connect to the remote host for the first time, you will see a warning about the authenticity of the remote host (if you have connected to the remote host before using ssh or scp, you will not see the warning). In any case, you will be asked for the someuser password for server2:

falko@server1:~$ sshfs -o idmap=user someuser@192.168.0.101:backup ~/backup
The authenticity of host '192.168.0.101 (192.168.0.101)' can't be established.
ECDSA key fingerprint is a2:38:f3:df:7a:6c:b6:3c:d6:c3:9c:88:93:e2:f0:63.
Are you sure you want to continue connecting (yes/no)?
<-- yes
someuser@192.168.0.101's password: <-- server2 someuser password
falko@server1:~$

Let's check if the remote directory got mounted to /home/falko/backup:

mount

falko@server1:~$ mount
/dev/mapper/server1-root on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
root@192.168.0.101:/home/backup on /backup type fuse.sshfs (rw,nosuid,nodev,max_read=65536)
someuser@192.168.0.101:backup on /home/falko/backup type fuse.sshfs (rw,nosuid,nodev,max_read=65536,user=falko)
falko@server1:~$

df -h

falko@server1:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/server1-root
                       29G 1015M   27G   4% /
udev                  238M  4.0K  238M   1% /dev
tmpfs                  99M  212K   99M   1% /run
none                  5.0M     0  5.0M   0% /run/lock
none                  247M     0  247M   0% /run/shm
/dev/sda1             228M   24M  193M  11% /boot
someuser@192.168.0.101:backup
                       29G 1019M   27G   4% /home/falko/backup
falko@server1:~$

Looks good!

To unmount the share, run

fusermount -u ~/backup

or

fusermount -u /home/falko/backup

 

4.1 Creating A Private/Public Key Pair On server1

Of course, we don't want to type in a password every time we try to mount the remote share. Therefore we create a private/public key pair and transfer the public key to server2 so that we will not be asked for a password anymore.

server1:

Create a private/public key pair on server1.example.com (still as user falko):

ssh-keygen

falko@server1:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/falko/.ssh/id_rsa):
 <-- ENTER
Enter passphrase (empty for no passphrase): <-- ENTER
Enter same passphrase again: <-- ENTER
Your identification has been saved in /home/falko/.ssh/id_rsa.
Your public key has been saved in /home/falko/.ssh/id_rsa.pub.
The key fingerprint is:
d8:8f:2a:88:d4:7b:c7:81:18:a9:0c:ae:d4:56:de:cf falko@server1.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|    .            |
|.  o . o         |
|+ + = + S        |
| * = o o o       |
|+.... . = .      |
|o .... + E       |
|    ..o          |
+-----------------+
falko@server1:~$

It is important that you do not enter a passphrase otherwise mounting will not work without human interaction so simply hit ENTER!

Next, we copy our public key to server2.example.com:

ssh-copy-id -i $HOME/.ssh/id_rsa.pub someuser@192.168.0.101

Now check on server2 if server1's public key has correctly been transferred:

server2:

cat /home/someuser/.ssh/authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCuhRw7+mXRkdSVNUKSlp3WMxG/uk33TVl6DYOYqBLa1bmgfY7M/YOY6OEgKzZ89FXYBu8VXe/LGN8/zGj2veMo+vbHd7N+M1j5dkubGz8/ISRQNj2sVwecwkMdiwHiDCxC5MSE/8wCQbITjGszZ8sb0P8imVMr9JAkqj8CGLkmgw40cYFiJU9ki6hBR1ie+cb5aplZNs8BoS5z5cc6fI+QIwJpM4FHeyYC5sSpHCjJdltYinhf0pdGXRiPA7Mu623HSB/EIOx/wLc5IXksxyyiY1AtrHFD/4TxCtvdxlv/CiMqOlZd9MuEldBT8GsoFOH5xxxWfXQCTfwwVakuCmD falko@server1.example.com

Now back on server1, try to mount the remote share again as user falko (make sure it's unmounted before you run the command):

server1:

sshfs -o idmap=user someuser@192.168.0.101:/home/someuser/backup ~/backup

If all goes well, you should not be prompted for a password:

falko@server1:~$ sshfs -o idmap=user someuser@192.168.0.101:/home/someuser/backup ~/backup
falko@server1:~$

 

4.2 Mounting The Remote Share Automatically At Boot Time

server1:

If you don't want to mount the remote share manually, it is possible to have it mounted automatically when the system boots (provided you have followed chapter 4.1 because otherwise an automatic mount is not possible because you will be asked for a password). Normally we would modify /etc/fstab to achieve this, but unfortunately the network isn't up yet when /etc/fstab is processed in the boot process, which means that the remote share cannot be mounted.

To circumvent this, we simply add our mount command to /etc/rc.local, which is the last file to be processed in the boot process, and at that time the network is up and running.

You need root privileges to edit /etc/rc.local, so become root first:

su

vi /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/usr/bin/sshfs -o idmap=user root@192.168.0.101:/home/backup /backup
cd /home/falko && su -c "/usr/bin/sshfs -o idmap=user someuser@192.168.0.101:/home/someuser/backup /home/falko/backup" falko
exit 0

As you see, I've added the command

cd /home/falko && su -c "/usr/bin/sshfs -o idmap=user someuser@192.168.0.101:/home/someuser/backup /home/falko/backup" falko

instead of just

/usr/bin/sshfs -o idmap=user someuser@192.168.0.101:/home/someuser/backup /home/falko/backup

because the sshfs command must be run by falko, not root!

You can test now by simply rebooting your system:

reboot

After the reboot, you can check with

mount

and

df -h

if the remote share got mounted.

 

5 Links


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Bob Bowles (not registered) on Tue, 2012-06-19 13:37.
Hi, Many Thanks for this thread. I have 2 questions (BTW I am using Ubuntu 12.04 LTS on both local and remote machines, not 11.10):

1) As root, I found the process does not work because in Ubuntu the root password is locked. It does not seem to be possible to use this way of mounting unless the root password has been unlocked, thus removing a significant security feature. How did you succeed using this method? Was server2 using a different distro?

2) As an ordinary user I found that the ownership of the mount point was changed by the sshfs mount process. The mount point was always reset to ownership by root, so I am unable to use the mount as a normal user, even though I performed the mount as the ordinary user. Is there something I am doing wrong, or is this a bug somewhere in sshfs?


Submitted by Evaggelos Balaskas (not registered) on Tue, 2011-12-06 11:50.

I am using a socks proxy on my office. This of course isnt a bug but a feature!

This is how i've managed to use sshfs with a socks proxy

sshfs-behind-a-socks-proxy-aka-write-your-own-fstab-script