1

Background

I am not a Linux or really even a command line person, but I've been tasked with setting up a Linux server for a company intranet.

I've set up a CentOS 7 installation in HyperV on Windows 10. I then got the AMP stack set up inside, and I got internet from the network passing through Win10 into CentOS. And I got the CentOS web server have it's own IP address and be accessible from the outside network.

I am now trying to get FTP working, so that when I move the VM to it's eventual real server, which isn't on my desktop, I can move files to it via FTP. I have followed numerous tutorials centered on vsftp. I have installed it, I have added FTP access to firewall-cmd. I have messed with iptables, and then found out that apparently CentOS uses firewalld, not iptables?

Settings

In /etc/vsftp/vsftp.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_file=/var/log/xferlog
xferlog_std_format=YES
chroot_local_user=YES
allow_writeable_chroot=YES
listen=NO
listen_ipv6=YES
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
userlist_deny=NO
userlist_file=/etc/vsftpd.userlist

The contents of /etc/vsftpd.userlist:

tester

Status of vsftpd:

enter image description here

Problem

When I try to connect via FTP, I see:

enter image description here

Question

What am I doing wrong?

Community
  • 1
Kelderic
  • 125
  • 6

1 Answers1

1

Given the fact that your FTP client there is showing "Connection refused", I believe that your firewall is configured properly but vsftpd simply isn't listening on the address you're attempting to connect to (192.168.15.101). That message happens when the service is either not running on the destination server, or isn't listening on the address you're attempting to connect to. As seen on my test server in both such situations:

[root@host ~]# telnet 192.168.122.173 21
Trying 192.168.122.173...
telnet: connect to address 192.168.122.173: Connection refused

If it were a firewall issue, your error message would be "no route to host" instead:

[root@host ~]# telnet 192.168.122.173 21
Trying 192.168.122.173...
telnet: connect to address 192.168.122.173: No route to host

A few things I would confirm:

  • Is vsftpd listening on that address? If you see the following, then it should be listening on all available IPv4 and IPv6 addresses - if you see something else, then that might be your problem:

    [root@ftpsrv ~]# ss -pln|grep -i ftp
tcp    LISTEN     0      32       -->:::21<--                   :::*                   users:(("vsftpd",pid=1636,fd=3))

  • Is the address you're connecting to the same server that vsftpd is on? ip ad will tell you - never hurts to double-check. You can also try telnetting to vsftpd from the server it's running on just to make sure it's working locally.

SFTP is another option as @Sven mentioned, though that doesn't use vsftpd, but rather your OpenSSH server. It's actually enabled by default in many systems - just check your /etc/ssh/sshd_config file for something like:

Subsystem       sftp    /usr/libexec/openssh/sftp-server

man 8 sftp-server can give you more information about that.

Adam V
  • 188
  • 1
  • 10
  • I checked on both things you mentioned. It looks like 21 is being listened to, but I don't really understand the output of `ip ad`. https://i.stack.imgur.com/hNCaW.png. I don't see the IP address that is showing outside in the `ip ad` output though. – Kelderic Jan 24 '18 at 18:13
  • There's your problem right there I think - vsftpd is indeed listening, but your `ip ad` output shows that the only IP's assigned to that server are `192.168.122.1` & `192.168.1.11`. The IP you've been attempting to connect to as per your ftp client screenshot - `192.168.15.101` - apparently goes to another machine. If you try connecting to either the `122.1` or `1.11` IP's, you'll probably get a reply. – Adam V Jan 24 '18 at 18:20
  • Yes indeed, that is it! It apparently the IP assigned to it had changed since I started this a few weeks ago. Now I think the only thing to fix is the file permissions on the user list. Thanks, mate! – Kelderic Jan 24 '18 at 18:48