Mount Remote Filesystems via SSH

← Back to Stories (view on slashdot.org)

Mount Remote Filesystems via SSH

Posted by michael on Sunday June 1, 2003 @04:20AM from the just-because-you-can dept.

eval writes "Ever wanted secure access to your files at work or school, but didn't have the necessary permissions or were thwarted by a firewall that allowed ssh access only? The SHFS kernel module allows you to mount directories from machines to which you have shell access. File operations are executed as shell commands on the server via SSH (or rsh). Caching keeps it reasonably fast, and remote commands are optimized based on the server's OS."

25 of 269 comments (clear)

Min score:

Reason:

Sort:

LUFS! by Santabutthead · 2003-06-01 04:26 · Score: 5, Informative

Big deal! I've been doing this for close to a year now, with lufs (http://lufs.sf.net). It's not really the easiest thing to automate but it sure works for day-to-day computing.
1. Re:LUFS! by TTimo · 2003-06-01 04:38 · Score: 5, Informative
  
  Well .. lufs is the main player in userland filesystem stuff really. It has had sshfs functionality for months. Very slick.
  
  The difference seems to be that SHFS does some amount of caching, which lufs doesn't do afaik. This has a good chance to improve performance.
2. Re:LUFS! by clump · 2003-06-01 04:57 · Score: 5, Informative
  
  LUFS deserves a lot of credit. I now use LUFS's SSHFS to mount my remote file volumes, whereas I previously used a tunneled NFS setup. The latter is a bear to setup but wonderful when operating. LUFS's SSHFS on the other hand requires zero setup on the server, no portmapper on either client or server, and is much easier to automate and control.
  
  I am looking forward to trying SHFS, but currently very much enjoy LUFS and the hard work put in by its authors. And that means your work on it too, TTimo ;)
3. Re:LUFS! by Erik+Hollensbe · 2003-06-01 08:57 · Score: 3, Informative
  
  It needs it because it's a filesystem driver. Somewhere along the chain, LUFS needs it too.
  
  BTW, if you really want to play with good ideas for kernel modules, get the cryptoAPI patches and compile openSSL to use them (which requires more patches, IIRC).
Another option by Guiri · 2003-06-01 04:28 · Score: 5, Informative

Just type fish://user@host in your Konqueror location bar ;). It works great!

--

DVD Ripping, Divx, VCD, SVCD under Linux
1. Re:Another option by Elbows · 2003-06-01 05:30 · Score: 3, Informative
  
  Implementing all of them in the kernel would bloat the kernel a lot. What KDE/Gnome should have done (and what LUFS, mentioned in another thread, seems to do), is have a small kernel module that calls a userspace daemon. All of the protocol code stays in userspace, but the kernel module makes the filesystem accessible to all programs. The overhead from the context switch doesn't matter when you're dealing with remote filesystems.
  
  It's a pretty slick idea, actually... maybe it will be integrated into the major DEs someday.
2. Re:Another option by Nucleon500 · 2003-06-01 05:32 · Score: 2, Informative
  
  That's what LUFS does. Someone just needs to either port the kioslaves and gnome-vfs libraries to LUFS or FUSE or rewrite them, whichever is easier. The only advantage of kioslaves and gnome-vfs is that they don't need mounting, so they are more convenient.
  I think the same thing could be done with LUFS, though. Using either automount or a specifically designed LUFS filesystem, make a filesystem where references to a protocol name would cause it to be mounted. For example,
  gqview ~/lufs/camera/pics
  When gqview asked for that dir, lufs-automount would mount the camera filesystem first, and unmount it when done. ~/lufs would be mounted on login.
  
  --
  Litigious bastards
3. Re:Another option by Spy+Hunter · 2003-06-01 05:43 · Score: 5, Informative
  I would say you're right, except the kernel does a lousy job of implementing filesystems in a user-friendly way. KDE IOSlaves are so much cooler for several reasons:
  
  They use URLs everywhere, which makes it easy to access local and remote files anywhere using any protocol from any application.
  
  New filesystems can be installed and activated by the user, you don't need a kernel module.
  
  You don't have to mount anything anywhere.
  
  Non-filesystem like protocols such as HTTP and POP3 can be easily implemented as IOSlaves and then used from any application.
  
  These features make IOSlaves much cooler than kernel filesystems IMHO.
  --
  main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
4. Re:Another option by Minna+Kirai · 2003-06-01 09:05 · Score: 2, Informative
  
  That's why you should never ever have dynamically linked setuid programs! (Or, if they do exist, they should give up root before calling any non-static functions. Some programs do that)
  
  This evil user could just set LD_PRELOAD to his own library, without needing to mess with new filesystems.
  
  A few years ago, several GNOME programs that were setuid were rearranged to no longer be root, because of this vulnerability. Xcdroast is one of the more famous ones.
  
  Additionally, in a system where normal users are allowed to mount their own filesystems, they should only be permitted to place them in ~/mnt.
5. Re:Another option by be-fan · 2003-06-01 11:31 · Score: 3, Informative
  
  KDE is an application framework. If you make things independent of each other, you loose a lot of the consistency and integration that makes an application framework so nice to program for in the first place.
  
  --
  A deep unwavering belief is a sure sign you're missing something...
You might want to have a look at... by yanestra · 2003-06-01 04:30 · Score: 5, Informative

avfs and lufs are much more common solutions to the "mount userland filesystems" problem. Yet, avfs makes it easy to construct your own whatever-you-want filesystem.
1. Re:You might want to have a look at... by SCY.tSCc. · 2003-06-01 06:26 · Score: 3, Informative
  
  Don't forget FUSE (filesystem in userspace) by the same author as AVFS. It recently hit version 1.0 BTW.
Re:If you don't have permissions... by wowbagger · 2003-06-01 04:31 · Score: 5, Informative

f you don't have permissions to use network connections other than SSH, are you going to have permissions to mount a filesystem on the computer?

Could be: for example, where I work I'm behind a corporate firewall, but I have admin rights on my workstation. As a result, I could very easily mount a remote file system via SSH. In fact, since I administer an FTP server that is outside the firewall, being able to mount it as a file system in a secure fashion would be quite useful.

Just because network ingress is controlled does not mean that your workstation is controlled. In many ways, this is no different than you burning a CD of your files at home and bringing that into work - the infection/cracking risk is the same. If you are not allowed to mount an external file system then you should not be allowed to mount a local file system.

However, just because you CAN access your home machine does not mean you SHOULD.

--
www.eFax.com are spammers
Some other project does this already by vlad_petric · 2003-06-01 04:33 · Score: 4, Informative

LUFS - userland filesystem. It's a userland "teleportation" of the VFS infrastructures (a kernel module sends all the queries to a userland daemon, which takes care of the protocol, etc).
The advantage of this approach is that adding a new filesystem type implies modifying a user-space daemon, not the kernel. LUFS includes, besides sshfs ftpfs, gnomefs, and gnutellafs and a few others

--
The Raven
1. Re:Some other project does this already by mosch · 2003-06-01 04:49 · Score: 4, Informative
  
  Not really. LUFS can access a machine which you have sftp access to whereas this project allows you to access the filesystem of a machine that you have true shell only access to, as is common especially in some university environments.
Re:Good idea but... by skurken · 2003-06-01 04:33 · Score: 5, Informative

No I think it's ment to be used the other way around. This way, I can mount my UN*X school account that allows shell access on my Linux computer at home (where you usually have root access). /S
Another option with SMB by aldjiblah · 2003-06-01 04:42 · Score: 4, Informative

An ssh connection forwarding the remote port 139 to 127.0.0.1:139, and then doing smbmount to //127.0.0.1/<mountpoint> - works great, and is practical considering Samba is often already running on the remote side.

--
sig sig sputnik
Nothing new, been done before by cce · 2003-06-01 04:51 · Score: 4, Informative

LUFS (Linux Userland Filesystem) already provides a nicely-developed interface to allow for userspace programs to implement filesystems over exotic protocols like SSH, FTP -- even Gnutella. Another project, FUSE (Filesystem in Userspace, part of AVFS) performs a similar task.
Moreover, the SHFS project website admits that it's "partially based" on FTPFS; but the FTPFS website says it's now obsolete and recomends using LUFS instead.
So the question: why did this merit an article? SHFS is just a proof-of-concept project for some kid's operating systems class, and I'll bet that despite the warning ("Warning: This is beta quality code. It was not tested on SMP machine. Backup data before playing with it!") tons of Slashdotters -- most without any kernel-hacking experience -- will have downloaded and perhaps installed it before I finish typing this post. This is dangerous.
So -- if you want to play with (and implement your own, it's remarkably easy!) fun filesystems, try LUFS or FUSE instead.
Re:Neato by tzanger · 2003-06-01 05:25 · Score: 4, Informative

I dunno, I run my NFS over IPSec and it seems to work just fine. A simple script to block any NFS access that isn't coming in on an ipsec interface and you're all set. rpcinfo and some awk, that's all it takes.
Re:When the SSH port is blocked by Anonymous Coward · 2003-06-01 06:38 · Score: 1, Informative

You think that's anal retentive? Last place I did contract work for blocked all outgoing traffic except for HTTP/HTTPS through an authenticating proxy server.

In order to utilize SSH I had to write a java sock5 server that would take local requests and tunnel them via CONNECT through the https proxy.
tab completion with scp by TobiasSodergren · 2003-06-01 08:07 · Score: 2, Informative

If you don't want to mount the filesystem, the bash completion project works quite nice with scp. By adding the public key on your computer to the server's authorized_keys file, you can use tab completion when traversing directories or copying files remotely. As a bonus, you get a lot of tab completions with other programs too.
PPP over an http proxy by Guiri · 2003-06-01 08:40 · Score: 4, Informative
I used to do that at the university. Here is gow:
1. Get Http tunnel. You have to install it inside the network with the proxy, and in another machine on the internet (outside that lan).
2. Create a tunnel from the first machine to the ssh server of the second machine (http tunnel creates a socket).
3. Do ssh-keygen on the first machine, and copy the .ssh/indentity.pub file from the first machine to .ssh/autorized_keys on the second host. That way you can login without password.
4. Now configure both machines to do PPP over ssh. I wrote the explanations here , look at the comment with a subject saying "PPP over SSH". It's in spanish, but you can translate it with babelfish, and at least you can get the scripts from there. If you don't manage, look in google for "ppp over ssh" or "firewall piercing".
5. Configure the first machine to use the second host as the default gateway (through this new ppp network device), and configure the second machine to do NAT for the first one.
There you go, you have unrestricted access to the internet through the most firewalled network in the world, and through a proxy ;).
You need to have root in both machines, but is worthwile, trust me! ];>> The first time it could look a little bit complicated, but afterwards you can just create a script to do the whole thing, so next time you'll only have to do "./create_tunnel" on the first machine to do the whole process.
--

DVD Ripping, Divx, VCD, SVCD under Linux
I think shfs is great ! by fea · 2003-06-01 09:27 · Score: 2, Informative

I think there are some unnecessary critism in this thread. shfs is exactly what I had been looking for for quite some time. I saw the article on nfs over ssh. This is sort of there, but requires knowledge of iptables, etc. Indeed, it took an entire article to explain how to use it. However, this package is very simple to use ! And it serves the purpose of being able to mount remote drives over ssh. After trying it out, I did have some suggestions which I plan to post to the developers.
Re:Windows? by 'Aikanaka · 2003-06-01 18:34 · Score: 2, Informative

There is a way to get UNIX/Linux functionality on your Windows box.

cygwin (www.cygwin.com) has a full implementation of OpenSSH (even includes sshd capability) - plus a whole pile of UNIX/Linux applications that will work ontop of Win2K.

HTH...
Emacs offers this already. by Anonymous Coward · 2003-06-01 19:06 · Score: 1, Informative

If I edit a file with the name /scp:user@hostname:localfilename, then this will be automatically fetched via scp. Heck, if I use Emacs' built-in eshell, I can do things like
cp /scp:user@hostname:localfilename ~/incoming
and other basic operations. Of course, directory listings and editing also work.

The package to use is tramp, it is part of the CVS Emacs, but also available separately.