[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:	DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:	Welcome to the Digital UNIX Conference
Moderator:	SMURF::DENHAM

Created:	Thu Mar 16 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	10068
Total number of notes:	35879

9325.0. "ftp in ONCE then access denied" by CSC32::PITT () Fri Mar 28 1997 10:11

    
    
    3.2f. 
    
    Customer ftps into his system and it works fine ONCE. Subsequent logins
    fail with 'access denied'. For the last couple of weeks, he has just
    been adding a new user every time he wants to ftp a file!!!!
    Telnet works fine to same users that just failed thru ftp. 
    
    He was running C2, I had him run setup and select 'BASE'. Rebooted and
    problem still exists. /etc/ftpusers file doesn't contain any of the
    users in question. Nothing in the log files. /etc/passwd shows all
    users are configured generically, no out of the ordinary shells or 
    anything! 
    
    ???????????

T.R	Title	User	Personal Name	Date	Lines
9325.1	possibilities	NETRIX::"[email protected]"	Ann Majeske	`Mon Mar 31 1997 12:31`	15
	I looked at the source code for ftpd and a few possibilities struck me. First, I get the feeling that if the ftpd process is left handing around, instead of being started each time from from inetd.conf, that it might cause problems. Second, ftpd checks the user's shell, so maybe there is something strange about the shell the customer is using (maybe the customer is resetting it somehow?). Third, Enhanced security sets your umask to be more restrictive. If after going back to Base security the customer just retried the accounts created while in Enhanced security, maybe the umask has something to do with it. Lastly, there were alot of changes made to ftpd between V3.2* and V4.0. If you can get your customer to upgrade the problem may just disappear. [Posted by WWW Notes gateway]
9325.2		finder.uvo.dec.com::COFFEYJ	La Feline Flooz - a unix cat	`Tue Apr 01 1997 07:46`	26
	I just had a customer call on this and the basic checks as detailed in the ftp man pages sorted it - the shells line again... might help here. Try debugging with yoru ftp command to see where it gets refused? How's the original ftp being closed off etc... ********** The ftp command also provides for security by sending passwords to the remote host and permits automatic login, file transfer, and logoff. When the ftp command connects to the remote host, ftp then prompts for the username and password before displaying the ftp> prompt again. ftp fails if no password is defined at the remote host for the specified username. If the $HOME/.netrc file or autologin entry does not exist, ftp prompts you for a username and password. This occurs whether or not the hostname is entered on the command line. In some cases (for example, when the required password is not listed in an autologin entry), ftp prompts for the password before displaying the ftp> prompt. Once ftp completes the autologin process, ftp executes the init macro if the macro is defined in the autologin entry. If the init macro does not exist or does not contain a quit or bye command, ftp then displays the ftp> prompt and waits for a subcommand. The remote username that you specify either at the prompt or in a $HOME/.netrc file must exist and have a password defined at the remote host or ftp fails. In addition, the remote user's shell must be listed in the /etc/shells file. ****************