Slashdot Mirror
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."
Now my web hosting company will probably take away ssh access. Thanks Linux hackers!
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.
This is a good idea, however there is one problem with the way that the problem is presented above:
If you're at work or school, are you really going to be able to insert a kernel module on the machine you're on? Generally I would think that you do not have sufficient permissions on the local machine.
A new feature is just a bug waiting to happen. And vice versa.
Just type fish://user@host in your Konqueror location bar ;). It works great!
DVD Ripping, Divx, VCD, SVCD under Linux
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.
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
..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
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
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.
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
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
Create VPN with freeswan or ppp over ssh, mount remote host from VPN.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Yeah, that's pretty stupid.
It's a bitch to get SMTP to work over 23, too.
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.
I just have to reply...
/.???
Having come from the world of satan (windows) and now firmly embedded in the world of linux I feel qualified to make this observation:
This is EXACTLY "what is wrong with open source". Not the software, not the thousands of dedicated people who contribute countless hours doing something as a labor of love. But the attitude that usability and ease-of-use are STUPID and not worthy of anyone's time.
To paraphrase: "If you're too lazy to do it using the extremely flexible but very arcane tool we have developed for you, you don't deserve to use linux."
Aside from the fact that this actually makes it easy to do something WITH the files, it also makes it substantially easier to get the files in the first place.
Also, anyone that knows anything about security knows that one of the main reasons security is circumvented is because of inconvenience. This removes that possibility.
Seriously, if you don't want to use it fine. But why take shots at it for the sake of looking l33t on
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.
It would be nice if this worked with Macos X and apple-type file systems. SSH works well on Macos X and I could do with an alternative to webdav and netatalk. Yes, I know that there are "issues" with apple file resources, but I wish they would just *disappear into* the shell so I didn't have to worry about them :-)
ah well. I can dream.
h.
Patriotism is a virtue of the vicious
we've been doing this with Plan 9 since 2000.
/net), optionally posting a 9P service descriptor for the new file system as /srv/service.
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
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.
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.
- Get Http tunnel. You have to install it inside the network with the proxy, and in another machine on the internet (outside that lan).
- Create a tunnel from the first machine to the ssh server of the second machine (http tunnel creates a socket).
- 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.
- 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".
- 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 proxyYou 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
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
OR... a pipe or socket.
/dev/uld/cdda:scd0.raw /dev/uld/cdda:scd0.a
/dev/uld/cdda:scd0.a
/lib/modules/streams/vorbisenc.so -oq=5,oggwrap /dev/uld/cdda:scd0.a
/dev/uld/cdda:scd0.a > "KMFDM - Waste.ogg"
But as to not being seekable, etc: that's why we have the distinction in the first place!
For things that aren't like a file, they shouldn't be a file. We need appropriate metaphors for things that are not flat and seekable.
Duh character devices aren't seekable, that's the POINT. In fact, upon further reflection: the reason why a CD-filesystem is a bad idea is because only one process can use it at a time!!! (^_^;;;) Making some resource a filesystem implies that it can deal with at least concurrent access, right? I'm not saying you can't do it, but I don't think it's a good idea because it doesn't really get you anything special.
After further reflection, the cd-extraction "device" almost begs to be a character file. Send it an ioctl (with a silly little command line util), then start slurping it into oggenc. The "cdparanoia" device... you might use it like this:
$ cddactl --extract 1[1:30]-3[4:00]
oggenc [ some stuff ]
In this case, cdda:scd0.raw is the file that accepts the ioctls, and cdda:scd0.a is a magically created char device corresponding to your request to read a range from the CD, and data will only start appearing from there once all other requests have been fulfilled (otherwise you get EAGAIN on read()). I pretend that uld is a filesystem exported by a magic kernel module that allows user-space libs to do some grunt work and provide device files as needed.
Perfect way to queue up a bunch of jobs; just spawn a bunch of oggencs in parallel on the file requests, and let the kernel wake up the right process to do it.
Or you could do something evil like this:
$ streamctl --push
Then:
$ cat
That is definitely in the spirit of Unix!
And whatever happened to STREAMS? That would be a perfect way to take cdparanoia + ogg and roll it into a OS abstraction.
I'm talking about generic "uber-character devices" for asyncronously and syncronously available data, and a way to get at their individual ioctls without having to write whole C programs.
Some kinda standard for that would kick a large amount of ass, especially if its easily accessible from user space.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
My experience has been that if a network is configured in an idiotic way (such as allowing telnet and not FTP), it's not because its operators have made careful and well-considered decisions about what to allow and disallow, but simply because they're idiots. That sort of eliminates the whole ethical dilemna. :-)
My Web Page