Mount Remote Filesystems via SSH 269
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."
Great! (Score:5, Funny)
If you don't have permissions... (Score:2, Interesting)
Re:If you don't have permissions... (Score:5, Informative)
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.
Re:If you don't have permissions... (Score:3, Interesting)
I have an account at the university [fys.ku.dk], and I like to work with the files there from home. (or the other way round). It's annoying to scp my files back and forth. (Even though konqueror can show sftp://me@my-uni as "just another folder"). If I can have it completely integrated, I'm all for it - then I could keep the relevant files at my nightly-backed-up university account, and it would seem like a folder on my harddrive at home. (slightly "W
LUFS! (Score:5, Informative)
Re:LUFS! (Score:5, Informative)
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! (Score:5, Informative)
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
Re:LUFS! (Score:2, Insightful)
Comment removed (Score:4, Informative)
Shell over SMTP (Score:5, Funny)
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
Re:Shell over SMTP (Score:2, Funny)
Back in my days, we used to eat gravel for breakfast. Cold gravel, out of a septic tank!
And our dad would beat us to death with his belt every evening!
(Credit where credit is due: Monty Python.)
Re:LUFS! (Score:2)
What am I doing wrong?
Good idea but... (Score:3, Insightful)
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.
Re:Good idea but... (Score:5, Informative)
Not that this is the typical way to use it... (Score:2)
Another option (Score:5, Informative)
Re:Another option (Score:5, Insightful)
Filesystems should be handled by the operating system, not the window manager.
Re:Another option (Score:4, Interesting)
Why arn't all the kioslave protocols in the kernel?
camera:\\
ftp:\\
http:\\
fish:\\
etc....
Re:Another option (Score:3, Informative)
It's a pretty slick idea, actually... maybe it will be integrated into the maj
Re:Another option (Score:2, Informative)
I think the same thing could be done with LUFS, though. Using either automount or a specifically designed LUFS filesystem, make a filesystem where references to a protocol name would cause it to be mounted. For example,
W
Too much windows in your life (Score:3)
camera://
ftp://
http://
fish://
Which is a very good thing since it works on all the platforms KDE works on without having to have 5 or 6 different "kernel level" implementations of every filesystem out there.
A kernel should be small. Why pile everything into a kernel if it can be handled in user space?
Re:Another option (Score:5, Interesting)
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.
Re:Another option (Score:4, Insightful)
If someone were to implement all of these systems in the kernel, then KDE/GNOME, etc. can already them. In the mean time, this seems to be the best compromise between functionality and portability.
Re:Another option (Score:2)
And what good does that do? Yes, I can run KDE on all of those, but each non-KDE application on those platforms is going to see a different file system from KDE applications. So, you have a desktop that integrates poorly on a lot of platforms, as opposed to one that integrates well with the system on a single platform.
Re:Another option (Score:4, Informative)
Re:Another option (Score:2)
Yes. Too bad that KDE doesn't use the standard application framework on Linux: the Linux kernel and X11.
Fast KDE development (Score:2, Interesting)
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.
Re:Another option (Score:5, Insightful)
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 (Score:3, Interesting)
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 e
Re:Another option (Score:3, Insightful)
You'd have to have rules on how the mounting would be done: only mounting on directories owned by the user for example (to stop people doing things like mounting over /lib). And you'd have to place restrictions on the permissions in the mounted FS - like no SU
Re:Another option (Score:2)
This is already commonly done, with the /net automount. Every Linux distribution comes with software to handle this.
Then I, the evil user, mount my own /lib and invoke a suid dynamically linked program, say /bin/passwd.
You don't give every user access to mount filesystems at any location. Such filesystems would also obviously be mounted nosuid and nodev, just like /net automounts always have been.
Right now the Linux VFS places a l
Re:Another option (Score:3, Informative)
This evil user could just set LD_PRELOAD to his own library [securityfocus.com], without needing to mess with new filesystems.
A few years ago, several GNOME programs that were setuid were rearranged to no longer be root, because of this vulnerability. Xcdroast is one of the more famous ones.
Additionally, in a system where normal users are
Re:Another option (Score:2)
Re:Another option (Score:3, Insightful)
kioslaves and gnome-vfs are not bloat, really. (Score:2)
I'm talking about the cdburning drag+drop, digital camera browsing, play-list "mounting", etc.
These things make sense inside the window management space because they are useful abstractions for use inside a graphical file manager. However, they are probably not too useful for the general unix environment (i.e. command line, generic VFS calls, some of which may have no translation... fcntl on a candidate for including on a blan
Note: the cameras are already supported... (Score:2)
There is no need for LUFS in that case. It is already transparent.
Mounting audio CDs has also been done (both as a discrete filesystem and UFS layers), however there are certain "issues" which then become clear why LUFS may not be the right option. For example, it is currently not possible (and isn't possible really according to the standard) to arbitrarily seek into a track reliably. Some drives allow for sector p
Re:Note: the cameras are already supported... (Score:2, Interesting)
The implementation would be: when the d
Everything is a file... (Score:4, Insightful)
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.
(replying to self) (Score:2)
It would make sense if it was implemented as follows:
Mounting the cdrom through cddafs presents the user with a listing of
Each file is a character device that when read begins extracting the data via CDDA from the appropriate track AND reading other tracks simultaneously engages some
Re:Another option (Score:5, Informative)
These features make IOSlaves much cooler than kernel filesystems IMHO.
Re:Another option (Score:2)
Re:Another option (Score:5, Interesting)
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.
Re:Another option (Score:3, Insightful)
Re:Another option (Score:2)
You use the IOSlave's methods for getting directory listings and changing permissions, of course.
Consider FTP: do you make a new connection for each URL, or do you keep the connection open for a while in hopes of getting another?
The second way. Also I think that the way IOSlaves work, the application can decide for itself when to open and close connections if it wants.
Re:Another option (Score:2)
You might want to have a look at... (Score:5, Informative)
Re:You might want to have a look at... (Score:3, Informative)
What's with the... (Score:5, Funny)
Some other project does this already (Score:5, Informative)
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 (Score:5, Informative)
Re:Some other project does this already (Score:2)
If the admin refuses to install ssh, have him fired. If this doesn't work, install your own copy. It need not run on the default port.
Re:Some other project does this already (Score:2)
You don't need sftp to transfer files... Just cat the file on the remote end and redirect the output to a file on the local end, or vise-versa.
Yet another option (Score:5, Interesting)
Been there before (Score:3, Interesting)
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:
/etc/exports
Server:
Put "/nfs_share_dir 127.0.0.1(rw,insecure,root_squash)" in
Ensure yo
Re:Yet another option (Score:2)
Slashdot requires you to wait 20 seconds between hitting 'reply' and submitting a comment
It's been 18 seconds since you hit 'reply'!
Another option with SMB (Score:5, Informative)
Re:Another option with SMB (Score:2)
Maybe it's just me, but I've tried this and gave up. Yes, it works, but performance was horrible, even for a WAN link. SMB was just never designed for WAN work. TCP, OTOH, is a different story.
Re:Another option with SMB (Score:2)
I thought SMB run over TCP...
It can (and often does). However, there is only so much room for data inside each TCP packet, and, IMHO, SMB is very wasteful of that space. Therein lies the problem. Wasteful -> more packets -> slower speed.
Or... (Score:5, Insightful)
Re:Or... (Score:2)
Yes, but:
1) This is FAR more difficult than just inserting a kernel module and calling "mount" with the appropriate parameters.
2) It's a total overkill if all you want to do is mount a remote filesystem securely, or through a strict firewall.
Re:Or... (Score:2)
2) True but if you're that much of a power user, that much is never enough.
The down side to this is that if your home machine is compromised, the secure network becomes open to attackers. Network administrators don't like that. So you must put a lot of effort into
Re:Or... (Score:2)
it's affected by FAR more things
What if you are behind a NAT box or proxy that won't allow you to use most VPN software?
What if you don't have remote superuser access?
etc..etc... etc...
This is so you can mount anything you have ssh shell access to... that is a WORLD different than setting up a ssh/ppp vpn.
As for "network adminsitrators" not liking it.. if we don't like it, we don't let you VPN into our secure netowrks in the first place.
Windows? (Score:3, Interesting)
Re:Windows? (Score:2, Informative)
cygwin (www.cygwin.com) has a full implementation of OpenSSH (even includes sshd capability) - plus a whole pile of UNIX/Linux applications that will work ontop of Win2K.
HTH...
Nothing new, been done before (Score:4, Informative)
Moreover, the SHFS project website admits that it's "partially based" on FTPFS; but the FTPFS website [sourceforge.net] says it's now obsolete and recomends using LUFS [sourceforge.net] 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 (Score:4, Insightful)
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.
Re:Nothing new, been done before (Score:2)
Better Implementation idea... (Score:5, Interesting)
This is the protocol that scp uses to read and write files and is already part of ssh.
macos x (Score:3, Interesting)
ah well. I can dream.
h.
Re:macos x (Score:2)
big deal (Score:5, Interesting)
from the ssh man page [bell-labs.com]:
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
Re:big deal (Score:4, Funny)
tools for the job (Score:3, Interesting)
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.
Good experience with LuFS (Score:2)
I have used LUFS http://lufs.sourceforge.net/lufs/ [sourceforge.net] for a few weeks and I have found it to be a very nice solution for LAN file sharing. It does not perform so well over high latency links, and I am not yet completely convinced that it behaves well under heavy IO loads although I have not proven the contrary either. So in a nutshell, LuFS is good for general purpose file sharing in a LAN environment and it is giving me entire satisfaction - goodbye Samba !
Need LUFS and GNOME/KDE people to talk (Score:3, Insightful)
I had forgotten, of course, that I had Nautilus turned on to do all its previews, subdir counting, etc. on local files - which of course it was treating this mount point as. And I cursed gnome-vfs2 for not automatically sensing the "remoteness", by reading the list of system-wide mount points and detecting which filesystem was handling the directory into which I'd gone.
KDE faces a similar problem, ultimately. Until we see "kdesh" or some sort of LD_PRELOAD to offer ioslaves to traditional UNIX utilities, there will be a rift between the well-integrated solutions that KDE and GNOME offer, but which don't interact with lower-level utilities, and the kernel/hybrid solutions which don't provide information to any layer higher than they are (or worse, which are ignored by that higher layer, because of NIH syndrome).
SHFS is not the wrong answer. If it has caching and LUFS lacks it, maybe some of that code will migrate into LUFS. That's the entire point of open source, people - let the better project win, not just the more established one. But ultimately, neither project is the answer I favor, until the people at work on these various layers of VFS switching start to accept that other peoples' work may be running on the same system their code is.
Another option (Score:2)
Re:Another option (Score:2)
Re:Another option (Score:2)
It wouldn't use port 139
tab completion with scp (Score:2, Informative)
I think shfs is great ! (Score:2, Informative)
Goodbye Tramp? (Score:2)
Damn. I have been using tramp [nongnu.org] for the last few years to do this with emacs. I'll have to try this and lufs out to see which method I like better.
Will this hurt ssh? (Score:2, Interesting)
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 th
Re:Will this hurt ssh? (Score:4, Interesting)
Re:Will this hurt ssh? (Score:2)
Re:Will this hurt ssh? (Score:2)
If a company'
No SSH port (Score:2)
Maybe I should just tunnel somehow?
Re:what's the point? (Score:5, Insightful)
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.
Re:what's the point? (Score:2)
Re:what's the point? (Score:3, Insightful)
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 arca
Re:My beef with firewalls.. (Score:5, Funny)
It's a bitch to get SMTP to work over 23, too.
Re:My beef with firewalls.. (Score:2)
Re:LUFS (Score:2)
LUFS only works with OpenSSH. When using commercial SSH, it fails miserably.
Re:LUFS (Score:2)
Or commercial SSH fails miserably.
Re:Snooze.. (Score:2)
Have a look at other people's comments.
Re:What's Wrong with SCP? (Score:2)
If might be convenient for some people to use local apps with the remotely mounted directory, I suppose. I could see that.
--Richard
Re:Neato (Score:4, Informative)
Don't you remember hacking a school lab? (Score:5, Interesting)
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 (Score:4, Informative)
- Get Http tunnel [nocrew.org]. 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 [bulmalug.net] , 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.
Re:PPP over an http proxy (Score:2)
Re:Gonna try to stay on topic... (Score:2)