Red Hat Bugzilla – Bug 844631
Corrupted files after login failure
Last modified: 2014-11-09 17:35:51 EST
Description of problem:
Login failure due to incorrect password, followed by a correct login in the same session, results in corrupted file upload (at least for certain files).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a gzipped tar file from a directory by calling "tar cf..." and then "gzip..." on the tar file.
2. Connect to VsFTPd using default Linux command line FTP client (e.g., Fedora 17). Enter a correct username and incorrect password (login will be rejected). Without closing the session, enter "user <username>" (where <username> is the same username that have failed to log in) and then, when prompted, the correct password.
3. Upload the tar.gzip file by calling "put ...tar.gz"
4. Check the size and MD5 of local and remote files.
The file sizes and the MD5 checksums differ.
The file sizes and the MD5 checksums should be the same (the Linux console client has "bin" mode on by default).
1. If you log in properly at the first attempt, same file is transferred correctly. No need to specify "bin" mode explicitly.
2. If you log in at the second attempt, but at some point issue a "bin" command, then all following file transfers are correct.
3. Depending on the file contents and type, the uploaded file is sometimes _larger_ than the original one, which makes the initial suggestion that, for whatever reason, "ascii" mode is in effect, probably incorrect (ASCII mode should result in smaller, not larger, file).
thanks for reporting.
I'd like to ask you if you tested another FTP client. I recommend lftp.
Thanks & Best regards
I have not tested with other FTP client for a reason - not many FTP clients have an interactive shell; in particular, lftp only logs onto the remote server after you actually try to upload/download something, so the situation as I described it cannot be repeated with lftp.
However, before reporting here I did test against different FTP server in order to check whether this is client's or server's fault. Same FTP client and same test case against NcFTPd (www.ncftpd.com) produces properly uploaded file.
For the sake of completeness, I think I have somewhere a copy of RH7 (Guinness), which used wu-ftpd - I might try this too :)
I'm not able to reproduce it. The ftp hangs after the second password insertion. Please, could you provide me an output of this grep:
# grep -v '^#\|^$' /etc/vsftpd/vsftpd.conf
Do you have a content in the file ~/.netrc on your client system? If so I'd like to see it.
The recommended lftp works fine for me. So It would be helpful to provide me an output of 'lftp -du <username> <server>' too.
Still 100% reproducible for me (clint is now ftp console client on F18 since F17 was long time ago).
As I wrote: attempt logon once with wrong password, then (when prompt returns) force a second logging by sending the 'username xxx' command and enter your correct password when prompted. Upload a file, then download it (first is the original file, second is what I get after uploading and downloading it; filesystem is the same):
File before uploading:
[root@archimed ~]# ls -l rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
-rw-r--r-- 1 root root 2745140 Feb 27 19:59 rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
File on the server:
227 Entering Passive Mode (217,75,128,2,186,204)
150 Here comes the directory listing.
-rw-r--r-- 1 558 558 2755620 Apr 28 16:59 msttcorefonts-2.5-1.noarch.rpm
226 Directory send OK.
File after downloading:
[root@archimed ~]# ls -l msttcorefonts-2.5-1.noarch.rpm
-rw-r--r-- 1 root root 2755620 Apr 28 19:59 msttcorefonts-2.5-1.noarch.rpm
No even need to md5 as files are clearly of a different size.
Can't help you with the vsftpd.conf as I no longer have SSH access to the server (SSH access is restriced by IP address). From what I see, some for of virtual chroot is configured as I cannot get up my home directory.
I have no .netcr in my home directory (dedfault hoem directory as created by the 'adduser' on Fedora 17 and 18).
lftp even with debug does not reveal anything to me:
[root@archimed ~]# lftp -du assen server.domain.com
lftp may somehow be mitigating the issue but, as I wrote before, it is 100% reproducible by using yet another client, the NcFTP client. Can't buy the idea of only using lftp against vsftpd.
as I wrote I'm currently not able to reproduce it. So I need more data that will lead to identifying the issue. Please, do understand my recommendation to use lftp at least as a workaround to be able to get files correctly.
You "can't buy the idea of only using lftp ..." but I didn't read if lftp works fine for you without any issue. Please, do clear me up this question.
I'd like to see debug logs from 'lftp -du assen server.domain.com'. Entering a password doesn't produce logs. You have to continue putting commands (ls, get, etc.). The logs could help me to reproduce the issue. I'm not able to do anything without reproducer. If the lftp works fine we can't predicate vsftpd is buggy.
There are no answers to comment #5, no vsftpd.conf. I don't have enough data to investigate. So I'm going to close this bug.
You can reopen it when the difficulties persist and the desired data is available.