vsftpd - sftp works fine, ftp freezes

Hello,

Recently I've set up vsftpd, everything's running fine, however I was asked to allow the ftp connections also, as I was informed that it wasn't working at all.
So I ftp'd to 127.0.0.1 and got:

Connected to 127.0.0.1 (127.0.0.1).

And it's sitting there, doing nothing. No 200, no nothing. I have to Ctrl+Z out of it. The process is getting created but that's it. I've created new users, changed paths, tried so many thing I lost count. I can't even diagnose what's happening, because nothing is being written to the logs (except for sftp.log, which is for sftp and doesn't help me in any way).

I've adjusted sebools (ftpd_use_nfs, ftpd_full_access, use_nfs_home_dirs) but then I've just switched it to permissive so I could narrow down what's the culprit, so SELinux can be taken out from the equation.

Xfer.log, vsftpd.log and sftp.log are all in the same path (nfs). Homedirs are on a separate nfs. Permissions are set so the jail would work properly. Socket for each user is created to get info about the connections.

Here are my configs:

sshd_config

Subsystem sftp internal-sftp -f LOCAL3 -l VERBOSE
	Match Group root
		PubkeyAuthentication yes
	Match Group ftpusers
		AllowTCPForwarding no
		AuthorizedKeysFile   .ssh/authorized_keys
		Banner none
		ChrootDirectory /sftp_path/chroot_%u/
		ForceCommand internal-sftp -f LOCAL3 -l VERBOSE
		PubkeyAuthentication yes
		PubkeyAcceptedKeyTypes=+ssh-dss
   Match User *,!root,!emm
		Banner /etc/sftp_banner_nosftp
		ForceCommand /bin/false

rsyslog.conf

$AddUnixListenSocket /sftp_path/chroot_username ## a lot of those, one per user

local3.* /var/log/log_archive/servername/sftp.log

vsftpd.conf

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=NO
ftpd_banner=Welcome to ABC sFTP service.
chroot_local_user=YES
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/userlist_allow
secure_chroot_dir=/sftp_path
allow_writeable_chroot=YES
listen=YES
listen_ipv6=NO

pam_service_name=vsftpd
userlist_deny=NO
userlist_enable=YES
userlist_file=/etc/vsftpd/userlist_allow
dual_log_enable=YES
vsftpd_log_file=/var/log/log_archive/servername/vsftpd.log
xferlog_file=/var/log/log_archive/servername/xfer.log
log_ftp_protocol=YES
syslog_enable=NO

Welcome.

OpenSSH provides SFTP support, so vsftpd has nothing to do with that. If SFTP is working fine, then you can (and should) uninstall vsftpd from the system. By the way, your SSH server configuration file seems misconfigured to allow DSA keys. That line ought to be removed. If there are still any DSA keys floating around in 2021, they should be found and replaced with Ed25519 if possible. If compatability with legacy systems is required then RSA is another option but, either way, DSA should be removed and replaced.

What problem were you trying to solve that FTP even came up in conversation?

sftp and ftp are entirely different protocols..
If sftp is working then you don’t need ftp at all IMO
…
(Turbocapitalist and I are apparently both awake in the middle of the night)

Hello Gentlemen,

The thing is, I was asked to allow some users to use ftp service too. Rumor has it that it's due to some old APIs that support only ftp transfers and I'm in no position to question that, unfortunately.
It's internal server, so I'm not concerned about security issues and the like.

DSA keys are allowed because there are RHEL6 jumphosts connecting to that server (management). Until the transition finishes, it'll remain as it is.
I agree and I'm not happy with the way it is set up now but I just play the hand I was dealt.


Turning to the merits - I might've provided too much info, granted. In short - when I try to ftp to that server, I get the said "connected to [IP]" and it stops at that. Right now I'm clueless how to troubleshoot/diagnose that.

Originally Posted by emm386 DSA keys are allowed because there are RHEL6 jumphosts connecting to that server (management).

That's when you use the RSA keys. :/

Anyway, about FTP, there are darn few legitimate uses for it these days and setting it up remains a great pain. Maybe SFTP was meant but "FTP" was said by mistake. That does happen occasionally. Since most projects have deployed SFTP support long ago, I wonder which programs still claim to need FTP?

However, all that aside, there is one important clarifying question: Which distro is this FTP server (vsftpd) going to be installed on? Please, include the version. That determines where the log files will be and whether SELinux is involved.

Originally Posted by Turbocapitalist That's when you use the RSA keys. :/

The thing is, I cannot change the keys just like that. They have to remain the same. Hence the workaround.

Originally Posted by Turbocapitalist Maybe SFTP was meant but "FTP" was said by mistake.

Unfortunately no. They even dropped some screencaps where it can be seen that on previous server (running on RH6) ftp connection was used and while sftp works fine, ftp does not.

Originally Posted by Turbocapitalist However, all that aside, there is one important clarifying question: Which distro is this FTP server (vsftpd) going to be installed on? Please, include the version. That determines where the log files will be and whether SELinux is involved.

RHEL 8.3
vsftpd 3.0.3-32

As I've mentioned in the original post, SELinux has been set to permissive. Should the ftp start working fine, I'll deal with policies and any other things later.

Okay, for anyone interested, I started from scratch and it looks like that if the path for either vsftpd log or xferlog are on an NFS (v3), everything will hang upon login as I've described.
Setting rights to 777 and overall messing with the filesystem doesn't change a thing here. No matter what I did, I couldn't make it work.

In the end, I went for storing the logs in the /var/log and making links to those on an NFS so that logrotate will do its job daily and I'll have archival logs stored on the NFS.