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."
If 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? The computers at my school (a high school) won't let you access explorer (or at least you're not supposed to). I can see its use for machines at your job, though, because there you would be able to mount filesystems.
now exacly what is wrong with SFTP?
Putty (windoze ssh client) comes with a secure FTP client, and OpenSSH comes with a SFTP server.
It's a bit of a hassle to navigate (no command completion), and you have to copy the files to/from your local system, but still... this doesn't really add any new functionality.
This sounds like a bad idea to me, why allow remote mounting of filesystems, when ssh has a file transfer protocol built into it?
On any *nix with ssh, you can use either sftp or scp, and even on Win32 platforms, you have WinSCP , secure file transfers without the need for remote mounting.
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
I have been looking for something like this, however my computer is a windows 2000 box, and the computer I connect to is running ssh on RH8. I don't see any that do this for windows yet.
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.
Even if you only allow the user to mount in specially secured areas of the file system you would still have problems. Right now the Linux VFS places a lot of trust in the individual filesystems. A user-mounted file system could contain deliberate errors designed to confuse the Linux VFS. A thorough audit would be needed.
Finally! A year of moderation! Ready for 2019?
Currently, and indicated in the FAQ above, you cannot tunnel UDP. You can, however, tunnel NFSv3 so long as you make NFS run over TCP. This is precisely how you can tunnel NFS. Here is how I do it:
Server:
Put "/nfs_share_dir 127.0.0.1(rw,insecure,root_squash)" in
Ensure you are running Linux's NFS user server and portmap
Client:
rpcinfo -p remotehost
ssh -f -l username -L 3643:localhost:643 -L 3049:localhost:2049 remotehost.com sleep 500
mount -t nfs -o tcp,port=3049,mountport=3643 localhost:/nfs_share_dir
The system works well but as you can see, it can be cumbersome. The "mountport" changes, hence the need to run rpcinfo -p. I have been told you can force a consistent mountport however. Then you worry about tunnels and whatnot. It works, but its hairy.
Because of the above, I rejoice for having found LUFS's SSHFS, and now wish to try SHFS. With SSHFS, I merely run SSHD on my remote machine, and mount it like so:
lufsmount sshfs://username@remotehost.com
Compare that one step to all of the above for NFS.
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.
OS's trying to be all things to all people is stupid
I have plan9 machines on my network because they do very powerful things in such simple ways.
It would be like using scissors to cut the grass.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
But the problem is that "writing the equivalent kernel modules" would take a lot longer.
.ogg vorbis files).
The fact that KDE code uses the "large amount of KDE support infrastructure" is what makes it easy to build a new I/O Slave (such as fish:// or cooler yet cdaudio:// which is a virtual mount of your cd audio as named
So it's not a shortfall of KDE developers because KDE developers only have so much time, and building the equivalent kernel modules will be much more time consuming.
Is anyone aware of a similar utility that exists for *BSD systems?
The implementation would be: when the directory is searched, scan the TOC to get length info. Just estimate for the Ogg files. When a file is opened, spawn a pipeline with cdparanoia and any encoders, and on each read, get the data from that pipeline. On seek in a wav file, restart cdparanoia with a different range. For everything else, return an error.
Frankly, making everything a file is just plain cool, as well as being part of the unix philosophy. If you think audio CDs are bad for files, check out /dev and /proc! Your mouse is a file! None of the character devices support seeking, truncating, or locking; they're more similar to pipes or sockets (also files).
Litigious bastards
A few years back I did software-support, and ended up remotely logging in to our customer's machines, often over a firewall.
.tar.gz.uu file and either using cat & script to transfer them, or cutting and pasting between windows. What a pain!
When the firewall only allowed telnet access and I needed to transfer files, I'd either end up building a
At that time, I started to work on a tool to allow me to transfer files over telnet. What stopped me was an ethical problem - if a company only allows telnet through their firewall, and not ftp, then they don't want people tranferring files through the firewall.
I wonder if these extensions to ssh will run into a similar problem. That is, companies not allowing ssh access through the firewall because it can be used for more than just login sessions...