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."
I love SSH its one of the best ways deliver stuff to your server I am running mine with Mac OS X. I like the speed and dependibility, and also its more secure then FTP. In the Matrix Reloaded they use SSH to access the buildings power which I find to be very accuarte.
Now my web hosting company will probably take away ssh access. Thanks Linux hackers!
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.
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.
..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
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.
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
In any case, yes, I did think about that, but it's really funnier if I mount it from windows98 to linux. I mean, hey, most linux distro's come with the BSd games, but windows? Pfeh, Hearts. whoopdi-fucking-do.
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?
I think you mean 23 (telnet) not 25 (smtp).
This mounts the file system at the OS level. That way emacs, vi, gnome programs, etc. have access to the filesystem, not just KDE.
PHP is the solution of choice for relaying mysql errors to web users.
Yeah, that's pretty stupid.
It's a bitch to get SMTP to work over 23, too.
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.
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.
After listing the contents once the directory should be buffered making subsequent listings faster.
-- I speak only for myself.
Haven't there already been other projects with similar design goals, like the Self-certifying file system? The authors of SHFS say it's a hack, which has a few drawbacks -- e.g., in generic write operations on non-Linux machines, a separate write() system call is used for each byte! Can anyone comment on the relative merits/demerits of the alternatives?
LUFS has done this for more than a year, and not just through ssh
LUFS only works with OpenSSH. When using commercial SSH, it fails miserably.
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
Maybe you shouldn't snooze so much - you totally missed the point.
Have a look at other people's comments.
At the office I'm working at (contract job) they are extremely anal retentive. They disallow most outgoing connections, SSH included. People are pretty much limited to web browsing. Not a problem, however, since they allow a secure connection on 443. I just configured my router to redirect 443 to 22 and I can connect to my server.
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.
Yes I did ;-)
SCO employee? Check out the bounty
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.
We've had something superior to this for about five years now, it's called NFS [faqs.org], the Novell Files Shared. Get with the times people. A horse and buggy can get you to the library....I'll take the Porsche Boxer. A birch canoe can get you to the other side of the Atlantic...I'll take a muti-level cruise ship. A pile of twigs and some stones can start a fire...I'll use my bic and some gasoline. A gilrfirend can pleasure you to no avail...I'll use my Judy X-321 Prototye Stimulator with Turbo Suck 2000.
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.
I have used LUFS http://lufs.sourceforge.net/lufs/ 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 !
It's called SNFS. The method is different, but the idea is the same; mounting drives over ssh. I played with this over a year ago.
http://www.math.ualberta.ca/imaging/snfs/
I may be WAY wrong here, but since no one else seems interested in answering the question and providing some good information besides "I did this back on my amiga when we had to create IP tunnels with our TEETH. So there."
/. and millions of people come crawling out of the woodwork to declare that indeed, they were using just such a system back in '91 when there was no png standard and all the p0rn was ascii.
The most common network mount types for regular joe users is NFS for running linux->linux or Samba(SMB) for linux->windows boxes. Neither of these systems are inherently very secure, either in terms of user authentication, or data encryption. Generally they are used on internal networks behind a firewall from the internet at large. This at least prevents any hacker with a port scanner from getting direct access to a box running an NFS or SMB server.
So, this leaves a big problem for those of us that want to mount our huge troves of mp3s and oggs, errr, I mean data for work that we have on our boxes at home for listening, I mean use at work. So, you can't really do that with standard ftp, since you can only download the files, which we don't want to do, we want to access them directly off the drive they are on. And since leaving a box running NFS or SMB out on the internet is like running up and down the street waving a giant flag and saying "Come one and all! Hack my data!" then a solution had to be made.
So in comes some folks who said, hey why don't we take ssh, which is pretty secure, and create some sort of tool that we can mount shares with that works on ssh? And so, some students post thier progress on creating just such a tool on
Such is the way of the world here...
hope that helps.....
1400x1250 in a 640x480 world...
I thought only the place I worked was that stupid (though they finally fixed this a few years ago). Infuriating.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
I set up LUFS last night, and blithely opened a Nautilus window to a mount-point I'd created (to a VERY remote SSHFS-mounted machine). Big mistake.
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.
Nothing worth doing is worth doing today.
This idea seems somewhat ineficient and more complicated than it has to be... why not simply tunnel port 139 via ssh and mount the remote filesystem via SMB?
Skiers and Riders -- http://www.snowjournal.com
Couldn't the same task be accomplished via a script that calls scp foo bob@fred:~/ssh bob@fred -t "rm foo"/etc?
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.
Those slashes should be forwards
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?
i know, i know, don't feed the troll...
with that said, question: are there any ways to access remote winxp directories using winxp other than SMB (and any other method available on linux that just so happens to be available on windows as well)?
answer: no. there are countless methods of accessing files on a linux machine. a good number of them are available in some shape or form for windows as well. google is your friend.
Xfce: Lighter than some, heavier than others. Just right.
If you don't want to mount the filesystem, the bash completion project works quite nice with scp. By adding the public key on your computer to the server's authorized_keys file, you can use tab completion when traversing directories or copying files remotely. As a bonus, you get a lot of tab completions with other programs too.
LUFS only works with OpenSSH. When using commercial SSH, it fails miserably.
Or commercial SSH fails miserably.
Have you got your LWN subscription yet?
- 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
It looks like the module is only installed on the client. The server only needs to have sshd running, and that's what makes this so nice.
Feed WHAT troll?
I cant ask my questions here because they get knocked off topic (rightly so) very quickly.
I dont know of a good IRC chan that I can actually use.
What is so wrong about that?
I was hoping that MAYBE just MAYBE I could get secure access to some of the linux routers Ive setup and vice versa!
Calling someone a troll is so 1997.
The ultimate network admin tool needs HELP!
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
I think there are some unnecessary critism in this thread. shfs is exactly what I had been looking for for quite some time. I saw the article on nfs over ssh. This is sort of there, but requires knowledge of iptables, etc. Indeed, it took an entire article to explain how to use it. However, this package is very simple to use ! And it serves the purpose of being able to mount remote drives over ssh. After trying it out, I did have some suggestions which I plan to post to the developers.
Damn. I have been using tramp 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.
the good ground has been paved over by suicidal maniacs
Well... Because a lot of corporations have clauses in their IS/Internet agreements (which you agree to by signing with the company) that say "we can and do monitor any traffic on our network and reserve the right to restrict access blah blah blah...", it may be perfectly valid for them to block out SSH completely. Once you negotiate your connection via SSH, even snooping the traffic won't tell you much, so your sysadmin can't see that you're perhaps scp-ing files that you shouldn't be over to the competition. On the other hand, it would be pretty obvious if you were doing that via FTP, Kermit, etc. Just the flip side on that... devil's advocate if you will.
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
This is most definately *not* a troll. The moderator saw "winxp" and his trigger finger twitched. Anyway, as for your question, you can also use NFS. There are NFS clients available for Windows, although I don't know of any free ones. There is a product called PC NFS Pro that runs about $40 dollars. All you have to do is create an NFS share on your Linux system, and you can mount it through the NFS client on the XP system.
A deep unwavering belief is a sure sign you're missing something...
Boobies!
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.
As noted by another poster, the main point of this type of thing is to be able to access your remote shell accounts from home. Not necessarily the other way around. However, I'd like to note that I've been working on a version of Knoppix that includes the LUFS lkm and userland deamons, the next step is to get LUFS to automatically setup key-exchange when knoppix boots (set the remote server as boot options), then use the remote server as your /home/dir in Knoppix. I haven't gotten it working perfectly yet, but when it's done I should have a secure environment available on any PC.
put the what in the where?
Is anyone aware of a similar utility that exists for *BSD systems?
make a stab at being polite in showing the advantage of whatever you're talking about.
slashdot is a free ad space. most of the cool things i find are not from topics, but from comments. of course 90% of the comments insist that theirs is better than the competition, sliced bread and complimentary presedential blow jobs all rolled together, and that everyone else is a fop, while neglecting to mention the prealpha status and lack of docs.
like so much in the world, balance is key. humility helps too. by all means, be heard, but you're just a jerk if you have to shout.
As long as the purpose only makes sense inside the window manager environment...
/mnt/lufs/proto/host/path
/mnt/lufs/proto/user:auth@host/path)
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 blank CD, whaaaa?)
Some of those abstractions are rather nifty. Others (like SSHFS) are probably overkill or not low-level enough to be truely useful to be implemented at such a high level.
Question... does LUFS support automatic protocol in the path? I'm talking about doing something like this:
Which might come back with an error if you need to ssh-agent, or klog, or something like that. (I wouldn't advocate
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
You can make your camera automount through, well, automount, the usb-storage module and vfat.
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 positioning, but not all. This is because audio tracks do not contain positioning information in each block. Jitter can be expected, and the file metaphor could be somewhat broken on a less-than-perfect CD when two consequetive reads of the same audio chunk aren't identical; one has to think of some clever caching schemes in that case.
It is much easier to read and deal with problems when processing the entire track at once from beginning to end. Hence cdparanoia. Making it into a file may seem interesting, but it isn't incredibly useful (since it's not reliable, and that implication shouldn't be implied by forcing the file system metaphor on top of it).
The same can be said of making virtual encoded versions of audio available through the same interface. The stream cannot be completed at arbitrary seek points; OGG's bit allocation protocol makes breaks at certain (but not obvious) points for framing information. MP3s (unless at constant bitrate) have the same issue. The file really has to be already be encoded in a straight shot, kept in RAM, and then it can be read arbitrarily.
So why not write a script to do that? It's not hard; there's only about 14,000 projects on freshmeat that do exactly that, CDDB tie-ins and all.
The filesystem metaphor shouldn't be forced onto abstractions that don't support arbitrary seeking, reading, writing, truncating, updating, locking.
Otherwise, why make it into a filesystem?
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
You can use SFTP to transfer files between Linux and Windows. These Open Source folks are nice enough to write programs even for operating systems they hate, but you might be labeled a Troll if you mention any of them here.
"I assumed blithely that there were no elves out there in the darkness"
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
Let me revise my comments on the idea of a cdda-filesystem. I realized I don't disagree really with what you said.
.wav files (or .raw files, depending on mount options), both with information from the TOC and possibly CDDB.
/dev/cdrom which allow it to seek within the track, etc. A mount option would transform them into block files capable of seeking but only reading in sector sized chunks.
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 complex locking and wait-queueing to prevent contention and increase performance.
Each character device allows it to receive ioctls similar to
File oriented-software wouldn't choke on that (but the driver wouldn't have to work too hard)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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...
If I edit a file with the name /scp:user@hostname:localfilename, then this will be automatically fetched via scp. Heck, if I use Emacs' built-in eshell, I can do things like /scp:user@hostname:localfilename ~/incoming
cp
and other basic operations. Of course, directory listings and editing also work.
The package to use is tramp, it is part of the CVS Emacs, but also available separately.
But if the sysadmin has root access to the computer you are SSH'ing to, he or she can run any kind of logging/file monitoring software he or she likes.
:-) )
But it won't necessarily work if your ssh'ing from your corporate computer to one the sysadmin can't log. (although of course, if they're *really* paranoid, they can install keyloggers onto the computers
data transfer can be optimized a lot by using rsync or something equivalent.
btw a cute idea (but based on HTTP rather than SSH) is Zero Install
Maybe I should just tunnel somehow?
Berto
I just installed this, width poor results. I am able to mount the remote file system, although the performance is slow, compared to ssh directly. A question though, what is the benefit of running the filesystem like this. Is the program executed on the server or the client?
think before you write, it'll save me moderator points.
Oh, whoops. Misunderstood
I'm not sure what your issue is but wildcards work fine on my sftp servers.
There are some shells that have worked on supporting tab completion (zsh, etc.) but that is a spotty solution at best. There are several GUI clients that support sftp and the completion issue is non-existant that way. This still only solves a small part of the issue. There was also a patch to put that functionality into OpenSSH but not much seems to have come of that (yet).
You can use the yafc ftp client since it uses sftp and has tab completion. The commands aren't exactly like ftp but it is very similar. I prefer using scp/sftp for transfering files in conjunction with the scponly shell.
I've used Alliare ColdFusion Studio (which Macromedia now owns) and Macromedia Dreamweaver to do web development. These tools worked GREAT for remove development in either Windows or Linux/Unix systems. In Windows, you just mapped your drive or used CF Studio or Dreamweaver's configuration to copy files when you save them. OR, which is what this story really reminds me of, is the use of SSH. Yes, I had to copy files back and forth over SSH when I wanted to see my changes, but Dreamver had this feature to work the SSH and automatically copy files back and forth all with the simple use of the project file navigation window. The user, me, never felt like I was working on a remote system, but felt like I was doing all the work locally. My co-workers were amazed that this feature was buried deep in the applications.
There is a fairly straightforward and intuitive HOWTO at http://www.math.ualberta.ca/imaging/snfs
I use this at work to access files across the firewall. Very useful. Much better than any other VPN hacks I've seen. Definitely worth a look.
Do it for da shorties
sshnet doesn't present a remote filesystem as local
plan9 does that all over but certainly not via a remote machines SSH server afaik
What one could do though it sshnet into the remote machine (M) and utilise M's TCP stack.
Now all network commands for this process group only will use M's TCP stack.
Then we use ftpfs to present M's ftp service as files in our tree for this process group.
No kernel modules required
And any processes that get forked from our group will have those those remote files available via SSH and they won't have to even know anything about ftp or ssh or squat didly about anything except manipulating files.
Putting something in the kernel that is manipulated by third parties seems a bit too trusting for my liking.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
bloat the kernel, like ALSA the usb device drivers and NVidia's binary driver, what are you going on about, do you know what bloat is?
I don't think the extra hooks would bloat the kernel that much, infact they would introduce less bloat than your suggestion.
thank God the internet isn't a human right.