On Fri, Mar 24, 2000 at 09:31:25PM +0100, Antonio Fiol Bonnín wrote: > <snip> > > I want to have easy freedom in limiting user access. I have killed > > telnetd, and only sshd. I want to allow some users access through ssh, > > some through ftpd, and some through samba. How can I turn off user > > access through ssh, but keep their account, and allow them access > > through ftp? Can I allow users access to shares through samba, and > > allow them to ftp in, but not ssh or telnet? > > Just a note there: > > I imagine that if you install and make your users use ssh, it's because > you do not want the passwords of the users to be visible through the net, > isn't it? > > Other than that, you propose the use of ftp, which uses non-ciphered > communication. Well, all the passwords that were not visible with ssh are > now visible with ftp.
this is a very good point, but as far as i have been able to find, there is no suitable, secure, replacement for ftp (why!?!?!) the only solutions i see are: 1) force users with ssh access to exclusivly use scp. problem with this is some ssh clients on broken platforms either do not have scp, or have very crappy/clumsy implementations. you also have to enter a password over and over again (afait) perhaps this can be delt with by using ssh-agent (i need to get around to looking at that..) but only on *nix platforms. and if you have say a win* or worse macos user, telling them they can't use there purdy drag and drop ftp client will get you shot. and finally if you don't want to give ftp users ssh access this is not an option. (though for those you can put them in a chroot jail and minimize the risks) 2) use ssh to tunnel the ftp connection. I may be doing something wrong but i have never managed to get this to work. this is also a somewhat obscure solution to propose to the clients. it also (again afaict) requires the user to have a interactive ssh account. again this won't work for ftp only users. 3) I think there is SSLized ftp but this would require a SSLized client which are probably not avaiable on macos. (if you have mac users this is a problem) and if the user likes thier more purdy insecure client better you have the problem in 1)... 4) IPsec or some other VPN that encrypts the whole damn thing all the way down to pings. but this is a rather complicated solution, especially with the macos/win* user problem. (or simply lots of users in general) so what can you do? maintain a separate passwd file for ftp? you still have a fairly large breach if someone gets into the ftp account, and the user cannot change this password (i assume using pam_pwdfile) you also get annoyed users having to remember two password and likely just setting the ssh password the same, eliminating any advantage... ftp seems to be an evil that is very hard to eliminate, it has no cross platform secure replacement (yes i have heard of sftp with ssh2, 2 words: no clients and 1(2?) more: non-free) if all your users actually care about your security there are solutions (user gets a *nix OS and uses scp+ssh-agent ;-)) but for most users who don't care about your security if it interferes with there ability to use the purdy insecure macos/win* client software your screwed... I would like nothing better then to be proven wrong on this one! i dare you! show me a solution that solves the problem of convenient file transfer from stubborn users who insist on ease of use over security (purdy GUI drag and drop ftp client over a clumsy scp client on their broken OS) as well as ftp only accounts without promisquous password blabbing across the net. -- Ethan Benson http://www.alaska.net/~erbenson/
