I got 2 more response to my question which corrected my problem/summary. I included everything so we can trash the first summary
thanks to all
> This is most likely an easy one...I had users logging into a 2100
> (3.2g) system FTPing files. After I moved to enhanced security they
> could no longer FTP. The ftpusers file has only root and uucp. Where
> else do I look?
___________________________________________________
Hi,
We have a menu script for users as well and ftp is ok. I think you will
find that ftp only works if the shell/script is listed in /etc/shells
Leon
-------------
Leon Troeth
lanks_at_yoyo.cc.monash.edu.au
http://www-personal.monash.edu.au/~lanks/
___________________________________________________
don't know if my answer applies, but maybe your problem has nothing to
do with enhanced security (which I don't use and I'm not familiar with)
but be a silly one. Excuse me if this sounds TOO silly.
If the user shell is defined to be an executable other than a standard
shell (sh chs ksh), or even if you point it to a shell which you may
have installed (tcsh bash ...), ftp won't run, unless you "register"
the new shell into file /etc/shells. See man ftpd.
----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)
----------------------------------------------------------------------------
Fuscim donca de Miragn E tornem a sta scio' in Bregn
Che i fachign e i cortesagn Magl' insema no stagn begn
Drizza la', compa' Tapogn (Rabisch, II 41, 96-99)
___________________________________________________
Sylvain Robitaille syl_at_alcor.concordia.ca
We had a similar problem when we switched to enhanced security. The
"problem" is that with enhanced security, a user _could_ have a password
that's more than 8 characters long. If you allow your users to use long
passwords, you must be sure that all the programs they can log in with
will accept a long password and properly encrypt it, without truncating
any of it. (the crypt(3) function only uses the first 8 characters)
In our case, we had most of the password aware programs only consider
the first eight characters, (we switched to enhanced security mostly for
the shadow password file). This would be consistent with other Unix
systems our users might be in touch with and avoid confusion from their
point of view. I happened to upgrade our FTP server and compiled it to
be aware of the enhanced security. After all, it would need to be able
to look into the authorization database.
A few of our users "thought" they were using passwords with nine
characters. I say "thought" because the passwd program is a locally
written one which checks a candidate password through cracklib to ensure
users don't use insecure passwords, and this passwd program only
recognizes the first eight characters, (it uses crypt).
Anyway, to make a long story short, (I know -- too late!), the ftp
server was not using the same crypt function to compare passwords as the
programs were that were writing to the password file. I suspect in your
case, this is also the problem, but in reverse. ie.: Your FTP server is
likely still using crypt, rather than crypt16. I suspect you need
to recompile the ftp server so it's aware of the switch to enhanced
security.
Hope that helps...
___________________________________________________
John Helmich [jhelmich_at_abilnet.com]
Once you switched over to Enhanced Security each user should have been
prompted to change their password upon their next logon. Are your users
only using FTP so that they wouldn't see this message that normally is
generated during a telnet session? It's the only thing I can think of off
the top of my head that might cause the problems other than a damaged
password database. I upgraded a 3.2G box to enhanced security a while back
and didn't experience the problems you are describing.
Good luck,
John
Received on Fri May 29 1998 - 17:18:01 NZST