LFTP can't connect to Proftpd server (hangs)

guzabi · 11-28-2010, 06:13 AM

I'm using ProFTPd as my FTP server on a CentOS 5 box. Since updating to version 1.3.3c, I seem to have very specific problems. Connections work quite fine with about any FTP client out there, including the basic ftp command from the Linux prompt. However, when trying to connect to that server with LFTP, things go wrong.

When connecting, all I get is [Connecting] then [Logging in...] and then nothing. I have to add that SSL is forced off in lftp.conf (I read it could be the problem). I sometimes get a counter for reconnection, but it never works.

The command I use in lftp is : open -u <user>,<pass> <server_ip>, the ls for lftp to establish the connection.

I don't see anything at all in the server's log. I just see "FTP session opened" and "FTP session closed" in /var/log/messages" and nothing in /var/log/secure. I can give you a strace if needed.

Please keep in mind that the server WORKS with anything but LFTP and NCFTP (which I also tried). This is driving me crazy. Please help !

Here's my LFTP config (comments stripped) :

Code:

alias dir ls
alias less more
alias zless zmore
alias bzless bzmore
alias reconnect "close; cache flush; cd ."
alias edit "eval -f \"get $0 -o ~/.lftp/edit.tmp.$$ && shell \\\"cp -p ~/.lftp/edit.tmp.$$ ~/.lftp/edit.tmp.$$.orig && $EDITOR ~/.lftp/edit.tmp.$$ && test ~/.lftp/edit.tmp.$$ -nt ~/.lftp/edit.tmp.$$.orig\\\" && put ~/.lftp/edit.tmp.$$ -o $0; shell rm -f ~/.lftp/edit.tmp.$$*\""

set prompt "lftp \S\? \u\@\h:\w> "
set sync-mode/ftp.idsoftware.com on
set sync-mode/ftp.microsoft.com on
set sync-mode/sunsolve.sun.com on
set auto-sync-mode "icrosoft FTP Service|MadGoat|MikroTik"
set ftp:passive-mode off
set ftp:ssl-allow off
set xfer:max-redirections 10

set cmd:term-status/*screen* "\e_\T\e\\"
set cmd:term-status/*xterm* "\e[11;0]\e]2;\T\007\e[11]"
set cmd:term-status/*rxvt* "\e[11;0]\e]2;\T\007\e[11]"

And proftpd.conf (comments stripped)

Code:

ServerName                      "(blah) - Unauthorized access/use prohibited (and we WILL sue you!)"
ServerIdent                     on "(blah)"
ServerAdmin                     (blah)
ServerType                      standalone
DefaultServer			on
AccessGrantMsg                  "User %u logged in - Unauthorized access/use prohibited."
RootLogin off

VRootEngine			on
DefaultRoot			~ !adm
VRootAlias			etc/security/pam_env.conf /etc/security/pam_env.conf

AuthPAMConfig			proftpd
AuthOrder			mod_auth_pam.c* mod_auth_unix.c

UseReverseDNS			off

User				nobody
Group				nobody

MaxInstances			20

UseSendfile			off

LogFormat			default	"%h %l %u %t \"%r\" %s %b"
LogFormat			auth	"%v [%P] %h %t \"%r\" %s"


<IfDefine TLS>
  TLSEngine			on
  TLSRequired			on
  TLSRSACertificateFile		/etc/pki/tls/certs/proftpd.pem
  TLSRSACertificateKeyFile	/etc/pki/tls/certs/proftpd.pem
  TLSCipherSuite		ALL:!ADH:!DES
  TLSOptions			NoCertRequest
  TLSVerifyClient		off
    TLSLog			/var/log/proftpd/tls.log
  <IfModule mod_tls_shmcache.c>
    TLSSessionCache		shm:/file=/var/run/proftpd/sesscache
  </IfModule>
</IfDefine>

<IfDefine DYNAMIC_BAN_LISTS>
  LoadModule			mod_ban.c
  BanEngine			on
  BanLog			/var/log/proftpd/ban.log
  BanTable			/var/run/proftpd/ban.tab

        BanOnEvent			MaxLoginAttempts 2/00:10:00 01:00:00

    BanControlsACLs		all allow user ftpadm
</IfDefine>

<Global>

      Umask				022

    ListOptions "-a"

    AllowRetrieveRestart		on
  AllowStoreRestart		on

    AllowOverwrite		yes
  <Limit ALL SITE_CHMOD>
    AllowAll
  </Limit>

</Global>

<IfDefine ANONYMOUS_FTP>
  <Anonymous ~ftp>
    User			ftp
    Group			ftp
    AccessGrantMsg		"Anonymous login ok, restrictions apply."

        UserAlias			anonymous ftp

        MaxClients			10 "Sorry, max %m users -- try again later"

        
            DisplayLogin		/welcome.msg
    DisplayChdir		.message
    DisplayReadme		README*

        DirFakeUser			on ftp
    DirFakeGroup		on ftp

        <Limit WRITE SITE_CHMOD>
      DenyAll
    </Limit>

            <Directory uploads/*>
      AllowOverwrite		no
      <Limit READ>
        DenyAll
      </Limit>

      <Limit STOR>
        AllowAll
      </Limit>
    </Directory>

        WtmpLog			off

        ExtendedLog			/var/log/proftpd/access.log WRITE,READ default
    ExtendedLog			/var/log/proftpd/auth.log AUTH auth

  </Anonymous>
</IfDefine>

unSpawn · 12-12-2010, 07:50 AM

Quote:

Originally Posted by guzabi

I'm using ProFTPd as my FTP server on a CentOS 5 box. Since updating to version 1.3.3c, I seem to have very specific problems.

I hope you got the clean version, right? See http://www.linuxquestions.org/questi...ibuted-847916/ .

Quote:

Originally Posted by guzabi

when trying to connect to that server with LFTP, things go wrong.
When connecting, all I get is [Connecting] then [Logging in...] and then nothing.

How about adding a full protocol debug statement to your ~/.lftprc?
Also my version of 'lftp' was compiled without ftps:// support. Check yours?

Quote:

Originally Posted by guzabi

I don't see anything at all in the server's log.

Just to make sure: there's nothing in your {tls,ban,access,auth}.log right?
Did you try TraceLog?
* BTW temporarily adding iptables "-j LOG" rules could show if the client hits port TCP/990 (FTPS) and not TCP/21.

Quote:

Originally Posted by guzabi

Code:

<IfDefine TLS>
  TLSEngine			on
  TLSRequired			on

...and you can't expect to force TLS to be ON on the server side and force it OFF in your lftp.conf, can't you?

//NTLB

guzabi · 12-13-2010, 05:53 AM

Quote:

Originally Posted by unSpawn

I hope you got the clean version, right? See http://www.linuxquestions.org/questi...ibuted-847916/ .

Dunno. Was from a Virtualmin repo.
Reinstalled just in case.

Quote:

Originally Posted by unSpawn

How about adding a full protocol debug statement to your ~/.lftprc?
Also my version of 'lftp' was compiled without ftps:// support. Check yours?

Don't understand that, sorry (don't know what .lftprc is and I don't have that file on either machine).
Here are the compile options for LFTP (it's on a Gentoo box) : net-ftp/lftp-4.0.10 USE="nls ssl -gnutls -socks5"
I just added gnutls to the compile options and recompiled (libtasn1 and gnutls were added as dependencies) but it did not change anything.

Quote:

Originally Posted by unSpawn

Just to make sure: there's nothing in your {tls,ban,access,auth}.log right?
Did you try TraceLog?
* BTW temporarily adding iptables "-j LOG" rules could show if the client hits port TCP/990 (FTPS) and not TCP/21.

I may be thick, but I don't see any of {tls,ban,access,auth}.log on my system.
There's no trace of the transaction in /var/log/secure or in /var/log/xferlog, though.
Enabling a full tracelog showed absolutely no trace of the transaction either.
And I'm not good enough with iptables to understand what -j LOG will do and how I use it.

Quote:

Originally Posted by unSpawn

...and you can't expect to force TLS to be ON on the server side and force it OFF in your lftp.conf, can't you?

Absolutely. Except there was a "IFDEFINE" in the config and TLS is NOT defined in the startup script. Plus other FTP clients connect without problem, so I guess while this looks strange, the truth must be elsewhere (as the man once said)

I nevertheless changed the "required" part to "off". I also opened port TCP/990 in iptables, which was closed. I did not changed anything either.

I'd be happy to try something else...

unSpawn · 12-13-2010, 10:17 AM

Quote:

Originally Posted by guzabi

Absolutely. Except there was a "IFDEFINE" in the config and TLS is NOT defined in the startup script.

My bad for not reading well enough. Sorry.

Let's see if debugging helps. Run 'lftp -d -p portnumber -u username hostname' where port is number 21 for regularly weak FTP and 990 once you enabled SSL on the server. If that doesn't display enough debugging information create a ~/.lftprc file with only these contents:

Code:

set cmd:trace yes
set cmd:verbose yes
set ftp:passive-mode on
set ftp:ssl-allow on
set ftp:ssl-protect-data on

and run 'lftp -d -p port -u user host' again.

guzabi · 12-14-2010, 03:24 AM

Code:

# lftp -d -p 21 -u ***username*** **x.x.x.x**
Password:
lftp ***username***@**x.x.x.x**:~> ls
---- Connecting to **x.x.x.x** (**x.x.x.x**) port 21
---> FEAT                  
<--- 220 ***site_name***                 
<--- 211-Features:
<---  MDTM
<---  MFMT
<---  TVFS
<---  UTF8
<---  MFF modify;UNIX.group;UNIX.mode;
<---  MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
<---  LANG zh-CN;ko-KR;bg-BG;en-US;fr-FR*;ru-RU;zh-TW;ja-JP;it-IT
<---  REST STREAM
<---  SIZE
<--- 211 Fin
---> LANG
---> OPTS UTF8 ON
---> OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
---> USER ***username***
<--- 200 Utilisation de la langue par d?faut : fr_FR
<--- 200 UTF-8 activ?
<--- 
200 OPTS MLST modify;perm;size;type;UNIX.group;UNIX.mode;UNIX.owner;
<--- 331 Mot de passe requis pour ***username***
`ls' at 0 [Connecting...]

then less than a second later the last line reads

Code:

`ls' at 0 [Logging in...]

and this lasts forever, co I ctrl-c it and get this :

Code:

Interrupt                    
---- Closing control socket
lftp ***username***@**x.x.x.x**:~>

The messages are in french, sorry. The 331 message means "Password required for user". But password was sent. I guess this points us to an error in sending/receiving the password... but I have no clue for investigating further

seems like lftp is not sending the password...

unSpawn · 12-14-2010, 08:50 AM

Only thing I can conclude from this is it indeed dislikes something about the password however I doubt if that's a lftp thing. If you try the same again, if that's not too much trouble, but in another window do something like 'echo Trace DEFAULT:10 >> /etc/proftpd.conf; touch /var/log/proftpd/trace.log; service proftpd restart; tail -f /var/log/proftpd/auth.log /var/log/proftpd/access.log /var/log/proftpd/ban.log /var/log/proftpd/tls.log /var/log/xferlog /var/log/secure /var/log/proftpd/trace.log' we would have a view of both the client and server side.
* And please clean up the host names in your existing and future posts. No need for anyone to come moseying over.

guzabi · 12-15-2010, 06:52 AM

On the client, output is unchanged.

Server-side, errr.. ouch! it's long!
Having stripped what was not relevant (i.e. other connections, because this is a production server with lots of websites on it) I see this :

1. Error with one of the commands :

Code:

# echo Trace DEFAULT:10 >> /etc/proftpd.conf; touch /var/log/proftpd/trace.log; service proftpd restart; tail -f /var/log/proftpd/auth.log /var/log/proftpd/access.log /var/log/proftpd/ban.log /var/log/proftpd/tls.log /var/log/xferlog /var/log/secure /var/log/proftpd/trace.log

tail: Can't open `/var/log/proftpd/auth.log' en lecture: No such file or directory
tail: Can't open `/var/log/proftpd/access.log' en lecture: No such file or directory
tail: Can't open `/var/log/proftpd/ban.log' en lecture: No such file or directory
tail: Can't open `/var/log/proftpd/tls.log' en lecture: No such file or directory

2. The only logs that are therefore followed by tail are /var/log/xferlog, /var/log/secure and /var/log/proftpd/trace.log -- Apart from successful logins and transfers by known users (server is in production), I seea repeating pattern in /var/log/secure :

Code:

Dec 15 11:43:31 **Server_name** proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No file or folder with that type
Dec 15 11:43:31 **Server_name** proftpd: pam_succeed_if(proftpd:session): error retrieving information about user 0
Dec 15 11:43:31 **Server_name** proftpd[19189]: **server_ip** (::ffff:127.0.0.1[::ffff:127.0.0.1]) - FTP session closed.

However, I read somewhere (on the web, because Google is my friend, whatever) that this error was normal on a CentOS 5.5 machine, so I'm not too worried about it. What's more important is that I don't see any sign of activity at the ip or username I'm using on the client in any of the logs. Just as if the connection never existed.

Two more things :

1. I tried the same client with the same options on another server (running Pure-FTPd on Debian Lenny) and it works fine. Another proof that the issue is on the server, not the client.

2. We're now officially seraching for the glory of science, because this specific server will be turned off by the end of the month. I nevertheless (maybe because I'm proud, or because I've got other servers with the same setup) would like to figure out WHY the damn thing is acting so strangely.

Cheers.

unSpawn · 12-15-2010, 08:12 AM

Quote:

Originally Posted by guzabi

this is a production server

Hmm. Maybe it would be better if you duplicated the configuration and ran it as a test server on another port?

Quote:

Originally Posted by guzabi

I don't see any sign of activity at the ip or username I'm using on the client in any of the logs. Just as if the connection never existed.

Use 'iptstate -S $IPADDRESS', 'lsof -Pwnlp $PIDOFPROFTPD -a -i @$SERVERIP:21' or iptables "-j LOG" rules (not tcpdump on a production server)?

Quote:

Originally Posted by guzabi

I tried the same client with the same options on another server (running Pure-FTPd on Debian Lenny) and it works fine. Another proof that the issue is on the server, not the client.

Lets recap. Connecting to the FTP daemon on this server:
- apparently works for other users, # not a TCP/20-21 problem
- works for this user except the password gets rejected, # due to PAM errors?
What's different about this user in comparison with others?
What's the difference between 1.3.3c and the previous version?
What does your /etc/pam.d/proftpd look like anyway?
Comment out any "auth required pam_env.so" lines in your /etc/pam.d/proftpd (or comment out includes if they use it)?
Maybe try again with PAM auth completely disabled?:

Code:

<IfModule mod_auth_pam.c>
    AuthPAM off
</IfModule>

guzabi · 12-16-2010, 11:13 AM

No time to try all this right away (will try later this week) but there's one thing incorrect in your recap. Logging in *with the same user* but using a different FTP client (for instance the regular FTP command) does work. So it's not a user-related issue, more of a client-server relationship problem. Oh, and the problem is the same with ncftpget. And finally, I'm really sorry but I don't have a server farm, so I'm unable to replicate this config on another server (I might setup a VM to do so, but once again, I don't have enough time right now). I'll keep you posted with my other tries. Thanks for helping, anyway!

unSpawn · 12-27-2010, 06:52 PM

Quote:

Originally Posted by guzabi

I don't have enough time right now). I'll keep you posted with my other tries.

Any news?

guzabi · 12-28-2010, 04:17 AM

Well, well... I did different things, including setting up a VM with exact same config (ie CentOS 5.5 with ProFTPd) and still get the exact same result, not knowing why this happens. I thought it might be a firewall issue (iptables is active on the machine, in both cases) but disabling iptables does not change anything, and disabling SELinux (also active bu default) does not change anything either.

I gave up. Sorry for the community, but the server has been disabled and I'm now using a Debian machine with PureFTPd and things work smoothly with LFTP so I have no urgent need to solve that problem. Sorry not to be more resilient, but hey, that's life ;-)

Thank you unSpawn for your help, anyway!