On Fri, 24 Mar 2000, Ethan Benson wrote:
> 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!?!?!)
Ask Bill...
> 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)
I believe that a chroot'ed ftp may work well for you, as long as you do
not allow ssh users to log in the ftp, nor the ftp users log in the ssh.
> 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...
separate chroot'ed ftp, and user password changing via chroot'ed telnetd.
You setup the user's shell to /bin/passwd and that should be it. (Never
tested).
> 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.
You won't get security if users do not accept it. However, you can propose
them the solution I told you (chroot ftp+telnet/passwd), telling them that
they have NO security at all on their files stored there.
Install a good log-parser to analyze everything that happens, and if you
see something strange... well just analyze them yourself by hand ;)
Antonio
