FTP won't display prompt

mikey777

Member


Messages: 40

I have 2 11.3 and 1 12.1 box running, and on one of the 11.3 boxes, ftpd won't cooperate. It won't display a prompt, it says "Connected to ..." but nothing after that, it just sits there. I can't find anything wrong, can't find any difference between the one that works and the one that doesn't. Both boxes are set to local-auth, PAM is off.
 

gpw928

Well-Known Member

Reaction score: 122
Messages: 367

I have to start by saying that scp(1) has so many virtues that I have not chosen to use ftp(1) in living memory...

Is ftpd enabled in /etc/rc.conf:
Code:
grep ftpd /etc/rc.conf
ftpd_enable="YES"
Is the ftpd process running:
Code:
ps auxwww | grep ftp | grep -v grep
root       737   0.0  0.1  7304  3432  -  Is   13:18    0:00.00 /usr/libexec/ftpd -D
Is it listening:
Code:
lsof | grep -i ftp | grep -i listen
ftpd      737       root    5u    IPv6 0xfffff80023678000                0t0    TCP *:ftp (LISTEN)
ftpd      737       root    6u    IPv4 0xfffff80023677830                0t0    TCP *:ftp (LISTEN)
Does the file /var/run/nologin exist? It disables ftpd.

Have you checked /etc/ftpusers? It lists users disallowed any ftp access.

Have you tried setting "ftpd_flags=-d" in /etc/rc.conf (then check syslog).
 
OP
M

mikey777

Member


Messages: 40

Yes, and I've checked all that. But instead I used ftpd -ld in inetd.conf which i thought started ftpd(IIRC).
I will keep on looking.
 

gpw928

Well-Known Member

Reaction score: 122
Messages: 367

Yes, and I've checked all that.
Is the problem is specific to ftpd, or is it generic?

Do other services work as expected? Use lsof -i TCP to see what's listening, and then poke the port with nc(1).

If there's nothing listening apart from ftpd, then enable sshd, start it, and see if you can connect from another host with ssh -v.
 
OP
M

mikey777

Member


Messages: 40

I found the problem, along with the difference between working and not. And I found that ftp doesn't actually fail, it just takes 45s for the username prompt to appear. Reason ?
Just like ssh not working (FreeBSD standard install) due to UseDNS, DNS is the culprit again. More (useless) security via stupidity. When I installed one box, I added 2 DNS servers, IPv4 & 6. The other, working ? None. That's the reason.for the 45s wait.
I have figured out that the DNS servers are in resolve-something, but not how to disable this insanity. I have been in networking since 1990 +/- depending on how you count. and reverse lookups are about as secure as sticking my head in the sand. utter stupidity IMHO. This is true useless security and should never be a default for any OS.
Is it inetd that 'controls' ftpd (and sshd) ? How do Ifix this ?
While I'm asking, why does sshd work when it is commented in inetd.conf ?
 

Zirias

Aspiring Daemon

Reaction score: 391
Messages: 868

The inetd(8) daemon is a relic from the past.
There are different opinions on that matter and I'd bet you'd get a lot of objections if you suggested its removal :) And admittedly, it might make sense for small services that are rarely used and it's a simple way to offer any stdio program as a network service.

But I'd agree that actual usage of inetd became increasingly uncommon. I personally only use it on a single host for its integrated identd, to make an IRC server happy ;)
 

gpw928

Well-Known Member

Reaction score: 122
Messages: 367

why does sshd work when it is commented in inetd.conf ?
As others have mentioned, inetd(8) is largely deprecated.

Services are started from rc scripts in /etc/rc.d and /usr/local/etc/rc.d.

They are enabled and configured by setting environment variables in/etc/rc.conf.

In some cases you will need to inspect the rc script to work out how to configure it.

The name will often be enough to find it:
Code:
[ritz.318] $ ls -lad /etc/rc.d/ssh* /usr/local/etc/rc.d/ssh*
ls: /usr/local/etc/rc.d/ssh*: No such file or directory
-r-xr-xr-x  1 root  wheel  1596 Jul  5  2019 /etc/rc.d/sshd
If the name of the script is not obvious, look for the service name in all the scripts:
Code:
[ritz.321] $ grep -l sshd /etc/rc.d/* /usr/local/etc/rc.d/*
/etc/rc.d/sshd
And you enable the service like this:
Code:
[ritz.322] $ grep sshd /etc/rc.conf                     
sshd_enable="YES"
 
OP
M

mikey777

Member


Messages: 40

Ok, so i will go back and try to make sense of it all again.
How do i turn off reverse lookups for ftpd ? I didnt' see any switches for ftpd in the man page.
 

gpw928

Well-Known Member

Reaction score: 122
Messages: 367

There is ftpd.conf(5), for the optional ftp/tnftpd, but I can't see any options there to disable reverse lookups.

If the ftp client hosts are known to you, you could try putting them into /etc/hosts on the ftp server, and telling the resolvers to use files first:
Code:
[ritz.156] $ grep hosts /etc/nsswitch.conf
hosts: files dns
 

gpw928

Well-Known Member

Reaction score: 122
Messages: 367

I want to keep it simple, I want to turn off reverse lookups off, for all services.
That's not feasible. It's also not sensible. Applications expect and require reverse lookups to work.
 
OP
M

mikey777

Member


Messages: 40

Well, we can disagree at least. I've only been in Network Security for 35 years, so maybe there's more to know about how much security there is in a reverse lookup that doesn't even fail, it just waits. I suppose that's some security.
 

Zirias

Aspiring Daemon

Reaction score: 391
Messages: 868

I've only been in Network Security for 35 years
If this was true, it's sad. Reverse lookups are often used for logging, sometimes as a security measure like e.g. with SMTP servers which typically require the forward and reverse lookups to match. In any case, a network without proper reverse lookups is just broken. As is a network where connection attempts must wait for timeouts instead of receiving an appropriate ICMP immediately.
 
OP
M

mikey777

Member


Messages: 40

In my spare time I'm still researching how ftpd (and sshd) asks for resolve (?) for DNS queries. Are there no switches to turn this off ? I can't find any.
 

Zirias

Aspiring Daemon

Reaction score: 391
Messages: 868

So, you have to research that, after 35 years in network security? Awesome! They try to connect to whatever is set as the nameserver in /etc/resolv.conf, and you probably have some broken "firewall" config in place that just drops these packages silently.
 
Top