Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mount Remote Filesystems via SSH

Posted by michael on 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."

15 of 269 comments (clear)

  1. Great! by Anonymous Coward · · Score: 5, Funny

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

  2. LUFS! by Santabutthead · · 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 · · 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 · · 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. Another option by Guiri · · 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 Spy+Hunter · · 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:
      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.
      --
      main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
  4. You might want to have a look at... by yanestra · · 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.

  5. Re:If you don't have permissions... by wowbagger · · 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
  6. What's with the... by Xpilot · · Score: 5, Funny

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

    --
    "Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
  7. Re:Good idea but... by skurken · · 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

  8. Re:what's the point? by kcurrie · · Score: 5, Insightful

    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.

    --
    -- I speak only for myself.
  9. Yet another option by BlueEar · · Score: 5, Interesting

    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.

    --
    A religious war is an adult version of a fight over who has the best imaginary friend
  10. Re:My beef with firewalls.. by Ian+the+Terrible · · Score: 5, Funny

    Yeah, that's pretty stupid.

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

  11. Don't you remember hacking a school lab? by iamacat · · Score: 5, Interesting

    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.

  12. Shell over SMTP by NoOneInParticular · · Score: 5, Funny
    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