Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!uw-beaver!zephyr.ens.tek.com!tektronix!nosun!tessi!onion!jeff
From: jeff@onion.pdx.com (Jeff Beadles)
Newsgroups: comp.unix.questions
Subject: Re: Problems with FTP and null passwords
Message-ID: <1990Jul31.163718.10168@onion.pdx.com>
Date: 31 Jul 90 16:37:18 GMT
References: <1364@necis.UUCP> <EMV.90Jul26234412@urania.math.lsa.umich.edu>
Distribution: usa
Organization: Little to none
Lines: 41

In article <EMV.90Jul26234412@urania.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
:>In article <1364@necis.UUCP> adamm@necis.UUCP (Adam S. Moskowitz) writes:
:>
:>   I have several machines on a private network used exclusively for
:>   testing.  Since they're just test machines, we don't bother with
:>   passwords. However, ftp doesn't grok null passwords. It seems to me
:>   that with a /etc/passwd entry such as "adamm::5006:. . ." ftp
:>   shouldn't even ask for a password. Since it does, it should be
:>   smart enough to recognize the null password the user gives.
:>
:>I think what you mean is not "null password" but "no password required".
:>Or perhaps "any password acceptable".  
:>
:>Looking at RFC 959 (FTP) for clues, which you should do, it appears
:>that according to the protocol the dialog should look like
:>	
:>	USER adamm
:>	230 User logged in, proceed.
:>
:>rather than
:>
:>	USER adamm<CRLF>
:>	331 User name okay, need password.
:>	PASS <CRLF>
:>	230 User logged in, proceed.
:>	
:>cause it looks from the grammar in section 5.3.2 that a password 
:>is a "string" of length at least 1.
:>
:>--Ed
:>
:>Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
:>comp.archives moderator


In all implimentions of ftpd that I've seen, they go out of their way to 
block no-password ftp attempts.  Why, I'm not sure.

	-Jeff
-- 
Jeff Beadles		jeff@onion.pdx.com