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

Great!

[Anonymous Coward]

Now my web hosting company will probably take away ssh access. Thanks Linux hackers!

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

[mosch]

fish is a great idea, implemented in the completely incorrect location. This kernel module gets it right.

Filesystems should be handled by the operating system, not the window manager.

Re:Another option

[sfraggle]

While I'm not a huge fan of microkernels, this is one area where a system like the Hurd has advantages over Linux.

In the Hurd all the filesystems are done by userspace programs called "translators". So to access your local filesystem you have an ext2 translator which accesses it. You can write your own translators - I believe they have a system to access remote systems via FTP.

Both fish/gnome-vfs and the kernel module system seem wrong to me. With kernel modules you have to be root to load them, but on the other hand its bad to be remaking the wheel by rewriting the filesystem in user space (plus, it only works with programs that are designed to use it).

It would be nice if the kernel module was added to the main kernel and offered as a "standard" system where nonprivileged users can mount their own filesystems from userspace daemons - Linux is kind of paranoid about non-root users mounting FSes. It would appear to provide the advantages that the Hurd approach brings, while keeping the higher performance of a monolithic kernel (having all FSes in user space like Hurd does seems like a bad idea performance wise)

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.

Re:Another option

[Spy Hunter]

LUFS is pretty neat, but I think IOSlaves are nicer. LUFS is still tied to the Unix filesystem, which is great for managing local files, but was never designed for anything else. Creating magic directories that cause gnutella searches to be performed is not my idea of a nice interface. IMHO, automount has always been an ugly kludge, and mapping URLs onto the Unix filesystem is not a great solution. How would you handle a URL like:
http://user:password@host.com/search.pl?param=va lue&param2=value2
And how would you handle HTTP caching? How would you send POSTs and other types of HTTP requests? Even if you could add all these features to LUFS, it would start getting more and more unweildy to use. And that's just for HTTP.

Re:Another option

[73939133]

No, it's a shortfall of KDE developers: instead of spending time on writing Konqueror modules, they could be writing the equivalent kernel modules.

But that isn't really anything new: a lot of the KDE effort could be written as more independent, stand-alone functionality, useful to lots of non-KDE software. Instead, KDE produces tightly integrated C++ modules that only work if you are running a large amount of KDE support infrastructure.

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.

What's with the...

[Xpilot]

..margerine box at the bottom? Is it what the programmers ate during the creation of shfs? Like that apocryphal Java-drinking sessions at Sun? Does margerine have magical caffiene-like properties too?

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

Re:what's the point?

[kcurrie]

What are you talking about? This makes a remote filesystem appear local, and all local commands work accordingly (i.e. edit a file, play an mp3, etc). With sftp you'd have to sftp a file down to do an operation on it, and then sftp it back up again afterwards, etc/

I've used lufs with the sshfs and it works great, I've even done compiles on a remote filesystem this way-- you simply cannot do that using just sftp/scp.

Yet another option

[BlueEar]

This seems to be beta quality code. Thus you might want to try Secure NFS via SSH Tunnel, which provides, accoding to the author Secure NFS (SNFS) via SSH2 tunneling of UDP datagrams, as suggested in the SSH FAQ.

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.

Or...

[Greyfox]

Create VPN with freeswan or ppp over ssh, mount remote host from VPN.

Re:My beef with firewalls..

[Ian the Terrible]

Yeah, that's pretty stupid.

It's a bitch to get SMTP to work over 23, too.

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:Nothing new, been done before

[Donald Knuth]

Why does any software announcement that's posted here always bring out a bunch of elitist trolls? Oh, that's right - because it's not good enough unless it's yours.

Do you know the authors of shfs, their ages, and what classes they're taking? Have you even downloaded the driver? Compiled it? Actually used it? Have you tested it, exprienced crashed, and therefore empirically come to the conclusion that it's "dangerous"? Or do you just like to play the role of Slashdot nanny?

Wait, don't answer that. I really don't care.

*You* should care, however, that you come off looking like a frustrated little prick by shitting on other people's work - for no reason other than to hear your own voice. Nobody wants to read your little pride-ridden, hyper-competitive, and overtly paternalistic little diatribes, no matter how much you think you enjoy writing them.

Anyway, lighten up and take the post for what it is. And in the future, if you can't say at least one reasonably positive thing about someone else's hard work - do the world a favor and just shut the bloody fuck up.

Better Implementation idea...

[Polo]

I think a better implementation of this might use the sftp protocol on the server side. This has been recently implemented with SSH v2. It's a subsystem within SSH (sftp-server) that supports all the common filesystem operations (open, close, read, write, seek, stat, etc...).

This is the protocol that scp uses to read and write files and is already part of ssh.

big deal

[F2F]

we've been doing this with Plan 9 since 2000.

from the ssh man page:

Sshnet establishes an SSH connection and, rather than execute a remote command, presents the remote server's TCP stack as a network stack (see the discussion of TCP in ip(3)) mounted at mtpt (default /net), optionally posting a 9P service descriptor for the new file system as /srv/service.

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.

Don't you remember hacking a school lab?

[iamacat]

The authors might not have admin access to the server to configure secure NFS. Or for that matter an installed compiler to install samba and tunnel it over ssh. Just shell access and instructions on using pine. And a sysadmin who will need a shot of brandy after hearing about students/employees running a remote filesystem. He might even be right, considering how NFS lets clients pick a userid to access files or uses inode numbers as handles.

There are a lot of projects like this. Linux used to have term and later a user-level PPP daemon to forward socket calls over a serial line, when the admin could have easily installed the real thing. At one point I had to write a rather complicated tool to forward incoming requests from the internet to a host inside an http-only firewall because that was the only way to test it with a client running on a cell phone.

Now if someone wrote a daemon to run PPP (or PPPOE) over an HTTP proxy, we could all just use it and stop reinventing the wheel.

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.

Shell over SMTP

[NoOneInParticular]

Big Deal! Back in my day, we ran a filesystem over smtp: sent your commands per email, have it executed remotely, and send the results back to the sender. Imagine:

To: user+bash@host.com

ls /usr/bin

And get the result back by email. The tricky part was to do (insecure) copy: cat piped to uuncode etc.

To paraphrase: it's not really the easiest thing to automate but it sure worked for day-to-day computing