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."
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
That's a shortfall of the kernel not KDE.
Why arn't all the kioslave protocols in the kernel?
camera:\\
ftp:\\
http:\\
fish:\\
etc....
thank God the internet isn't a human right.
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
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.
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:a lue¶m2=value2
http://user:password@host.com/search.pl?param=v
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.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
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.
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