• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Mounting an FTP server in Linux - possible?

FTP isn't very secure though. In fact it's a huge security hazard. I recommend strongly that you use something else if at all possible.

You see with FTP the username and password is transfered over the internet in PLAIN TEXT. That is anybody with a packet sniffer will see your user name and your password you type out very very very very easily.

If you have Linux (or a newer BSD with ssh with sftp support) then you can use 'sftp' which is a reasonable replication of FTP functions, but using ssh. Ssh is secure shell (obviously) and it supports various methods of authentication including password challenge response method and shared keys.

If you have ssh setup on the system your trying to access there are several methods you can use for accessing it as a file system..
http://fuse.sourceforge.net/sshfs.html

This is a 'FUSE' based file system. Fuse stands for 'file system in userspace' and it has been part of the 2.6.x series kernel for a while now. Any modern distro should have it as the 'fuse' module. Then you need to setup permissions for /dev/fuse and fusermount program. In Debian you do this by adding your using to the 'fuse' group.. I don't know about other distros.

I think sshfs is a improvement over the lufs stuff. But I never tried LUFS so I dont' know.


What that does is mount your sftp server as a directory in your file system. So it's usefull for all applications.

The nice thing about sshfs is that performance is very high even with the encryption overhead. It's faster then NFS on slower links. Also it requires no setup on the server end. Just as long as you have shell access over ssh and your ssh client supports sftp functions then it will work.

So once you get it all setup..
sshfs user@host:/directory ~/mountpoint

The downside is that it will hang if you loose your connectivity. To fix that you have to do a 'lazy' umount from a different terminal...
fusermount -uz ~/mountpoint


There are two other methods that I know of that is most usefull for when your using mostly KDE or Gnome apps.

Gnome has it's gnome-vfs stuff. You can access it either by openning up a nautilus window and hitting 'ctrl-l' and then going 'ssh://user@host'

Also you can go through the application menu in the 'places' section and choose 'connect to server'.

Doing that will add the ability to access the files on the ssh server via your gui's file dialog. Also this will work with FTP, Webdav and other protocols.


For KDE they have their KIO stuff. This allows you to do all sorts of neat psuedo file system stuff in konqueror.

The one dealing with ssh/sftp is 'fish'. So you would open up konqueror and go into the URL bar:
fish://user@host

Also they have support for ftp and other protocols.
 
Originally posted by: drag
FTP isn't very secure though. In fact it's a huge security hazard. I recommend strongly that you use something else if at all possible.

You see with FTP the username and password is transfered over the internet in PLAIN TEXT. That is anybody with a packet sniffer will see your user name and your password you type out very very very very easily.

If you have Linux (or a newer BSD with ssh with sftp support) then you can use 'sftp' which is a reasonable replication of FTP functions, but using ssh. Ssh is secure shell (obviously) and it supports various methods of authentication including password challenge response method and shared keys.

If you have ssh setup on the system your trying to access there are several methods you can use for accessing it as a file system..
http://fuse.sourceforge.net/sshfs.html

This is a 'FUSE' based file system. Fuse stands for 'file system in userspace' and it has been part of the 2.6.x series kernel for a while now. Any modern distro should have it as the 'fuse' module. Then you need to setup permissions for /dev/fuse and fusermount program. In Debian you do this by adding your using to the 'fuse' group.. I don't know about other distros.

I think sshfs is a improvement over the lufs stuff. But I never tried LUFS so I dont' know.


What that does is mount your sftp server as a directory in your file system. So it's usefull for all applications.

The nice thing about sshfs is that performance is very high even with the encryption overhead. It's faster then NFS on slower links. Also it requires no setup on the server end. Just as long as you have shell access over ssh and your ssh client supports sftp functions then it will work.

So once you get it all setup..
sshfs user@host:/directory ~/mountpoint

The downside is that it will hang if you loose your connectivity. To fix that you have to do a 'lazy' umount from a different terminal...
fusermount -uz ~/mountpoint


There are two other methods that I know of that is most usefull for when your using mostly KDE or Gnome apps.

Gnome has it's gnome-vfs stuff. You can access it either by openning up a nautilus window and hitting 'ctrl-l' and then going 'ssh://user@host'

Also you can go through the application menu in the 'places' section and choose 'connect to server'.

Doing that will add the ability to access the files on the ssh server via your gui's file dialog. Also this will work with FTP, Webdav and other protocols.


For KDE they have their KIO stuff. This allows you to do all sorts of neat psuedo file system stuff in konqueror.

The one dealing with ssh/sftp is 'fish'. So you would open up konqueror and go into the URL bar:
fish://user@host

Also they have support for ftp and other protocols.

There is a LUFS-FUSE bridge; see the list of FUSE filesystems.

sshfs is no substitute for a true networked filesystem like NFS, SMB/CIFS, AFS, Coda, or Plan 9, unless all you're doing is moving, copying, or removing files, or unless the files are small.
 
sshfs works great. Well at least better then you think it does so I have to dissagree with you strongly there. I am a big fan of it. Makes my life easier.

I don't know when you used it but the version of sshfs using FUSE does large files very well. I know there is one for LUFS, but they aren't the same thing.

It supports seeking through files. I can play large media files over sshfs and I can seek through them with no problem.

And in benchmarks on my network it does all of this faster then NFS on network speeds of 100Mb/s (full duplex) or slower. If you get gigabit speeds then nfs is slightly faster. I don't know what I did with them, but I was moving around 700MB media files no sweat over sshfs.

And beleive me it seriously just kicked the ever living hell out of SMB/CIFS. Even in CPU usage. It was like half the time. Almost as fast as ftp transfer (running compression helps a bit with that, especially with text files).


Here is a example..

This is from my laptop to my server downstairs. It's over a 54Mb wireless connection.

~$ sshfs rocker.local: ~/query
password:

~$ cd query
~/query$ time hexdump /dev/urandom > cow.dump
(I hit ctl-c to kill it)
real 4m33.052s
user 2m2.632s
sys 1m33.476s

~/query$ ls -lh cow.dump
-rw-r--r-- 1 drag drag 402M Jul 14 18:17 cow.dump

~/query$ cd ..
~$ fusermount -u query
~$ sshfs rocker.local: query
~$ cd query
~/query$ time tail cow.dump
85cc4c0 bb95 9ff9 d21a cf3c f6df d0f8 b084 3f6c
85cc4d0 c54e 8923 4a1e 63ae bc53 d8fc d070 a995
85cc4e0 297f 9c0a 20cf 849c 8f40 c059 bc68 3b6f
85cc4f0 077d 127a a3db 2cc8 69ac 6736 426f b6aa
85cc500 9a3a 3ae1 2e41 36ff cf73 2fd5 af4d aff1
85cc510 3251 7b16 4091 aac1 841e 5420 787e 403f
85cc520 d488 ea60 46a5 29c3 5fa9 6180 5826 92fc
85cc530 7b00 f57d 3364 6f4e 2865 44fa 780c 16a3
85cc540 3d48 ae30 569c e781 85a9 5676 ab63 286b
85cc550 cf38 6e9
real 0m0.462s
user 0m0.004s
sys 0m0.004s

~/query$ time grep "bb95 9ff9" cow.dump
85cc4c0 bb95 9ff9 d21a cf3c f6df d0f8 b084 3f6c

real 3m4.415s
user 0m1.192s
sys 0m2.112s


So other then that I just used it for backing up my home directory on my desktop. That was 24gigs no problem. Just copied it right over.

I edit large file and do media playback. No problem.

And it possible to secure it (relatively) for when you have small amounts of users. You can use scponly with it's sftp support in a chroot environment to allow you to let people access file server space over the internet or whatnot.

How much success you get from using FUSE sshfs depends heavily on the sftp client. For instance success dealing with symbolic links varies on how old the server is.

The only real limitations that I've run into is that if your disconnected from teh server it can hang. Also some types of special files aren't supported, such as named pipes... But I had the same problem when using OpenAFS.

NOW.. OpenAFS kicks ass, but THAT is not suitable for large files. OpenAFS is great for allowing access to users of files of up around several hundred megs over networks that are insecure and/or unstable. It has lots of heavy cache'ng mechanisms that allow you to edit files while temporarially disconnected. However this has a huge performance penalty if your using it over fast networks and/or large files.

I mean I've played Doom3 that was mounted on OpenAFS and that was ok. Took a long time to load up the first time, but after that it was as fast as local disk speed.. since it was running all out of disk cache. But as a home directory it was less then satasfactory. ACLs are only semi-POSIX compliant and special files like named pipes didn't work so hot. It has kerberos version 4 for the authentication mechanism, which is nice.

OpenAFS odd-ness however causes larger amounts of user and administrator effort overhead.

BTW I've played Doom3 over sshfs and that worked fine.. However I didn't have very good success with Ut2004. I think that Doom3 is more unix-friendly in how it's designed...

SMB/CIFS is good when you have a lot of users on a local LAN. Sshfs is realy most suitable for ad-hoc access to a file server or were security is most important.

It's slow however. This is it's worst thing about it. Samba folks are working on that by bypassing all the windows-compatability code if it's a Linux to Linux connection.

It's biggest advantage is that EVERYBODY supports it. This is due entirely to the success of Samba. Linux's NFS has compatability issues. OpenAFS only supports Linux realy well.. OS X is spotty and it is just plain crap on Windows.

But Samba does equally well on almost any sort of client. Works great with Apples, great with BSD's, great with Windows.


NFS is good for large files over fast local networks. It's major advantage is speed. Other then that it sucks because it's insecure. Securing it requires stuff like tunnels and such and if your doign that you might as well use something else.
NFS version 4 is suppose to help with that, but it's support is spotty and it is not enjoying much attention.

At least that's my impression. For my personal stuff sshfs rocks. I wouldn't use it with bunches of users though. The CPU overhead on the server would suck.



edit: BTW there is also FUSE bridges for KDE KIO stuff and Gnome-vfs stuff, I beleive.

edit:

Also one that I've playing around with is fun is BeagleFS. It's mounts a directory full of (symbolic links to) responses of a beagle query. Pretty snazy. Like that virtual folder stuff.
 
maybe. I've haven't had any crashes with it.

It'll get hung up if I loose connectivity, to umount it then you have to do lazy umount.
fusemount -uz whatever

(z is lazy mount)

That way you can umount stuff that still has proccesses accessing it. Aside from that I haven't had any problems.

Keep in mind that LUFS has it's own sshfs that is not what I am talking about. (just want to make sure). Maybe it's the version you were using?
$ sshfs --version
SSHFS version 1.6
FUSE library version: 2.5.3
fusermount version: 2.5.3
using FUSE kernel interface version 7.5
 
Originally posted by: drag
maybe. I've haven't had any crashes with it.

It'll get hung up if I loose connectivity, to umount it then you have to do lazy umount.
fusemount -uz whatever

(z is lazy mount)

That way you can umount stuff that still has proccesses accessing it. Aside from that I haven't had any problems.

Keep in mind that LUFS has it's own sshfs that is not what I am talking about. (just want to make sure). Maybe it's the version you were using?
$ sshfs --version
SSHFS version 1.6
FUSE library version: 2.5.3
fusermount version: 2.5.3
using FUSE kernel interface version 7.5

It was most definitely not LUFS that I used.

Actually, to be honest, I don't remember what exactly happened, but I remember sshfs on FUSE barfing on something...

Oh wait! Now I remember! It was a torrent that produced all the problems. That kind of access pattern seems like a true torture test for any network filesystem anyway.
 
Back
Top