LinuxQuestions.org - LFTP can't connect to Proftpd server (hangs)

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - LFTP can't connect to Proftpd server (hangs) (https://www.linuxquestions.org/questions/linux-server-73/lftp-cant-connect-to-proftpd-server-hangs-847009/)

LFTP can't connect to Proftpd server (hangs)

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>

Quote:

Originally Posted by guzabi (Post 4173370)

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 (Post 4173370)

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 (Post 4173370)

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 (Post 4173370)

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

Quote:

Originally Posted by unSpawn (Post 4188613)

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 (Post 4188613)

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 (Post 4188613)

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 (Post 4188613)

...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...

Quote:

Originally Posted by guzabi (Post 4189623)

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.

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...

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.

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.

Quote:

Originally Posted by guzabi (Post 4192198)

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 (Post 4192198)

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 (Post 4192198)

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>

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! :)

Quote:

Originally Posted by guzabi (Post 4193647)

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

Any news?

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!