Mount Remote Filesystems via SSH

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."

Comments

LUFS!

[Santabutthead]

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.

Re:LUFS!

[TTimo]

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.

Re:LUFS!

[clump]

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 ;)

Another option

[Guiri]

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

Re:Another option

[Spy Hunter]

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:

1. They use URLs everywhere, which makes it easy to access local and remote files anywhere using any protocol from any application.
   
2. New filesystems can be installed and activated by the user, you don't need a kernel module.
   
3. You don't have to mount anything anywhere.
   
4. 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.

You might want to have a look at...

[yanestra]

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.

Re:If you don't have permissions...

[wowbagger]

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.

Some other project does this already

[vlad_petric]

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

Re:Some other project does this already

[mosch]

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...

[skurken]

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

[aldjiblah]

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.

Nothing new, been done before

[cce]

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

[tzanger]

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.

PPP over an http proxy

[Guiri]

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.