(linux_command_line)-> ssh hints and tips fuse sshfs
submited by Russell Wed 25 Jan 06|
Edited Tue 21 Apr 09
fuse-sshfs: really simple drive sharing using ssh connections.|
SSHFS: Super Easy File Access over SSH (linux journal) The beauty of this is that you don't need antthing specal on the server, you don't even need root access. All you need is a ssh login. just a few steps: (fedora 4, fedora 5, fedora 6 or lator )
One thing I really like about sshfs when compared to other options like samba and nfs, is that you seem to be able to unmount (umount) the drive even if it has open ( stalled) file access on it.
- Install Packages(as root)
yum install fuse-sshfsthat installs the packages needed. ( it will auto install fuse if you don't have it)
- grant privliges for the users you want to use sshfs.
The Above linked article gives the command
usermod -a -G fuse mattThis grants the user matt access to the fuse devices and commands. it didn't work for me. I found that I could manualy open the service with (as root):
chmod 4755 /usr/bin/fusermount
But this is probably a security problem even if you don't have a shared machine. Also because /dev is re-created each boot, the second command needs to be run each time you boot ( you could put it in /etc/rc.local ) and the other problem is that is you update fuse, you will need to update the change in permitions on fusermount.
chmod 777 /dev/fuse
The command below did work, atleast under fedora 6, I don't know if it's a bug.
/usr/sbin/usermod --append fuse --groups fuse matt
- Mount the drive
sshfs user@host:path localpath
it will ask for password as it would on a normal ssh connection, and mount the drive. It is just so easy. If you have the same username on both machines you can omit that , and if you have exchanged keys with the server, you don't even get the password request. ( so the command is scriptable) path is relitive to the user's home dir, unless you prefix it with / ( sshfs user@host:/media/cdrecorder localpath will mount the remote cdrecorder localy )
fusermount -u path drops the drive. It seems to be pretty bullet proof. Knowing the tranfers are encripted is just a bonus to me but I have used this to connecto to drives over the internet where security is more of a concern.
To avoid the "enter password" dialog ( so you can mount these automaticly in scripts) create and exchange keys with the remote server.
ssh-keygen -t dsa
creates a key pair. Don't supply a password, ( or else you won't be able to have scripts run unattended) . Once you have the pair, copy .ssh/id_dsa.pub from the local computer to ~/.ssh/authorized_keys on the remote computer. (append it to that file, if it already exists) ... If you don't know how do do that, you aren't advanced enough to be doing this. It is probably better that you get a "enter password:" prompt each time you ssh to the remote computer.
Once you have done this you can ssh from the local to the remote server without entering a password. sshfs,rsync and other programs that rely on ssh will also work without a password.
I got my info
from linux journal.
CLI Magic: OpenSSH + Bash
remote sync (rsync) with marked backup files (Russell)
Add comment or question...: