Hi All,
After upgrading to FC 28 from FC 27, my customer's vsftpd server stopped allowing ftp logins from anywhere.
# systemctl status vsftpd
shows it running and happy (I tried stopping and restarting several times)
There is no complaining in
# journalctl -f
when I attempt to make a connection.
I just get told something is wrong with the username or password.
SELinux alerts are quiet.
What the heck ????
-T
On 05/23/18 13:53, Todd Chester wrote:
Hi All,
After upgrading to FC 28 from FC 27, my customer's vsftpd server stopped allowing ftp logins from anywhere.
# systemctl status vsftpd
shows it running and happy (I tried stopping and restarting several times)
There is no complaining in
# journalctl -f
when I attempt to make a connection.
I just get told something is wrong with the username or password.
SELinux alerts are quiet.
What the heck ????
Well, I had an F27/Gnome VM to which I installed vsftp and tested it.
I then upgraded to F28 and it continues to work just fine.
I see this in the journal when I use a good un/pw.
May 23 18:50:08 f27gq.greshko.com audit[1585]: USER_ACCT pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success' May 23 18:50:08 f27gq.greshko.com audit[1585]: CRED_ACQ pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_listfile,pam_shells,pam_unix acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success'
And this when I give a bad un/pw.
May 23 18:49:34 f27gq.greshko.com vsftpd[1580]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=myang rhost=::ffff:192.168.1.18 May 23 18:50:08 f27gq.greshko.com audit[1585]: USER_AUTH pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_listfile,pam_shells,pam_unix acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success'
Are you saying you don't even see these sorts of messages?
-T _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/...
On 05/23/2018 03:53 AM, Ed Greshko wrote:
On 05/23/18 13:53, Todd Chester wrote:
Hi All,
After upgrading to FC 28 from FC 27, my customer's vsftpd server stopped allowing ftp logins from anywhere.
# systemctl status vsftpd
shows it running and happy (I tried stopping and restarting several times)
There is no complaining in
# journalctl -f
when I attempt to make a connection.
I just get told something is wrong with the username or password.
SELinux alerts are quiet.
What the heck ????
Well, I had an F27/Gnome VM to which I installed vsftp and tested it.
I then upgraded to F28 and it continues to work just fine.
I see this in the journal when I use a good un/pw.
May 23 18:50:08 f27gq.greshko.com audit[1585]: USER_ACCT pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success' May 23 18:50:08 f27gq.greshko.com audit[1585]: CRED_ACQ pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_listfile,pam_shells,pam_unix acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success'
And this when I give a bad un/pw.
May 23 18:49:34 f27gq.greshko.com vsftpd[1580]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=myang rhost=::ffff:192.168.1.18 May 23 18:50:08 f27gq.greshko.com audit[1585]: USER_AUTH pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_listfile,pam_shells,pam_unix acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success'
Are you saying you don't even see these sorts of messages?
I don't see anything. I do see things like this when I su, so I know journalctl is working correctly.
Maybe the firewall is blocking it and vsftp never sees the traffic?
Are you running SELinux?
On 05/24/18 05:59, ToddAndMargo wrote:
On 05/23/2018 03:53 AM, Ed Greshko wrote:
On 05/23/18 13:53, Todd Chester wrote:
Hi All,
After upgrading to FC 28 from FC 27, my customer's vsftpd server stopped allowing ftp logins from anywhere.
# systemctl status vsftpd
shows it running and happy (I tried stopping and restarting several times)
There is no complaining in
# journalctl -f
when I attempt to make a connection.
I just get told something is wrong with the username or password.
SELinux alerts are quiet.
What the heck ????
Well, I had an F27/Gnome VM to which I installed vsftp and tested it.
I then upgraded to F28 and it continues to work just fine.
I see this in the journal when I use a good un/pw.
May 23 18:50:08 f27gq.greshko.com audit[1585]: USER_ACCT pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success' May 23 18:50:08 f27gq.greshko.com audit[1585]: CRED_ACQ pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_listfile,pam_shells,pam_unix acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success'
And this when I give a bad un/pw.
May 23 18:49:34 f27gq.greshko.com vsftpd[1580]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=myang rhost=::ffff:192.168.1.18 May 23 18:50:08 f27gq.greshko.com audit[1585]: USER_AUTH pid=1585 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_listfile,pam_shells,pam_unix acct="egreshko" exe="/usr/sbin/vsftpd" hostname=::ffff:192.168.1.18 addr=::ffff:192.168.1.18 terminal=ftp res=success'
Are you saying you don't even see these sorts of messages?
I don't see anything. I do see things like this when I su, so I know journalctl is working correctly.
Maybe the firewall is blocking it and vsftp never sees the traffic?
You said you get a message about a bad username or password. What is the exact error? You can check the firewall quite easily with firewall-config.
Are you running SELinux?
Yes.
On 05/23/2018 03:33 PM, Ed Greshko wrote:
On 05/24/18 05:59, ToddAndMargo wrote:
You said you get a message about a bad username or password. What is the exact error?
Nothing. No motion at all.
I do get motion from other things. But dead quiet when Windows (Cobian Backup add Windows Explorer) is trying to log in.
You can check the firewall quite easily with firewall-config.
I will. I will try to log in from localhost first
Thank you for all the help!
On 05/23/2018 06:59 PM, Todd Chester wrote:
On 05/23/2018 03:33 PM, Ed Greshko wrote:
On 05/24/18 05:59, ToddAndMargo wrote:
You said you get a message about a bad username or password. What is the exact error?
Nothing. No motion at all.
When this happens, can you log in from a CLI console? If so, there should be something in the journal about a failed login attempt.
On 05/23/2018 08:09 PM, Joe Zeff wrote:
On 05/23/2018 06:59 PM, Todd Chester wrote:
On 05/23/2018 03:33 PM, Ed Greshko wrote:
On 05/24/18 05:59, ToddAndMargo wrote:
You said you get a message about a bad username or password. What is the exact error?
Nothing. No motion at all.
When this happens, can you log in from a CLI console? If so, there should be something in the journal about a failed login attempt.
Oh yes. CLI, SSH, xRDP, Thunar (sftp). The only thing now working beautifully is vsftp.
On 05/24/18 11:18, Todd Chester wrote:
On 05/23/2018 08:09 PM, Joe Zeff wrote:
On 05/23/2018 06:59 PM, Todd Chester wrote:
On 05/23/2018 03:33 PM, Ed Greshko wrote:
On 05/24/18 05:59, ToddAndMargo wrote:
You said you get a message about a bad username or password. What is the exact error?
Nothing. No motion at all.
When this happens, can you log in from a CLI console? If so, there should be something in the journal about a failed login attempt.
Oh yes. CLI, SSH, xRDP, Thunar (sftp). The only thing now working beautifully is vsftp.
Did you mis-type? Did you mean to say "The only thing *not* working beautifully is vsftp?".
Did you try
ftp localhost?
On 05/23/2018 08:20 PM, Ed Greshko wrote:
On 05/24/18 11:18, Todd Chester wrote:
On 05/23/2018 08:09 PM, Joe Zeff wrote:
On 05/23/2018 06:59 PM, Todd Chester wrote:
On 05/23/2018 03:33 PM, Ed Greshko wrote:
On 05/24/18 05:59, ToddAndMargo wrote:
You said you get a message about a bad username or password. What is the exact error?
Nothing. No motion at all.
When this happens, can you log in from a CLI console? If so, there should be something in the journal about a failed login attempt.
Oh yes. CLI, SSH, xRDP, Thunar (sftp). The only thing now working beautifully is vsftp.
Did you mis-type? Did you mean to say "The only thing *not* working beautifully is vsftp?".
Oops. Yes it was a mistype.
Did you try
ftp localhost?
Just did and I got right in. I ssh in and then did "ftp localhost". Ahh Poop! the "user" command tells me I am not connected
`firewall-config` is loading over `ssh -X` as I write this. It is having a devil of a time scrolling. And it just crashed. I did get to see that ftp was not checked off
On 05/24/18 11:31, Todd Chester wrote:
Just did and I got right in. I ssh in and then did "ftp localhost". Ahh Poop! the "user" command tells me I am not connected
`firewall-config` is loading over `ssh -X` as I write this. It is having a devil of a time scrolling. And it just crashed. I did get to see that ftp was not checked off
I did not realize you were doing this remote from the server.
You should then ssh into the system running the vsftp and do something along this line....
[root@f27gq ~]# firewall-cmd --get-active-zones FedoraWorkstation interfaces: enp0s3
to verify what zone is being used.
[root@f27gq ~]# firewall-cmd --info-zone=FedoraWorkstation FedoraWorkstation (active) target: default icmp-block-inversion: no interfaces: enp0s3 sources: services: dhcpv6-client ssh samba-client mdns ftp ports: 1025-65535/udp 1025-65535/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
note that services shows "ftp".
If not....
firewall-cmd --zone=FedoraWorkstation --add-service=ftp
firewall-cmd --permanent --zone=FedoraWorkstation --add-service=ftp (to make it permanent)
On 05/23/2018 08:56 PM, Ed Greshko wrote:
# firewall-cmd --info-zone=FedoraWorkstation FedoraWorkstation (active) target: default icmp-block-inversion: no interfaces: enp0s3 sources: services: dhcpv6-client ssh samba-client mdns ftp ports: 1025-65535/udp 1025-65535/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
note that services shows "ftp".
Ah Ha!
# firewall-cmd --info-zone=FedoraWorkstation FedoraWorkstation target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client ssh samba-client ports: 1025-65535/udp 1025-65535/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
# systemctl status vsftpd ● vsftpd.service - Vsftpd ftp daemon Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; enabled; vendor pres> Active: active (running) since Tue 2018-05-22 21:42:26 PDT; 24h ago Process: 13218 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exite> Main PID: 13219 (vsftpd) Tasks: 1 (limit: 4915) Memory: 1.3M CGroup: /system.slice/vsftpd.service └─13219 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
May 22 21:42:26 server.storall.local systemd[1]: Stopped Vsftpd ftp daemon. May 22 21:42:26 server.storall.local systemd[1]: Starting Vsftpd ftp daemon... May 22 21:42:26 server.storall.local systemd[1]: Started Vsftpd ftp daemon.
Systemd sure thinks it is a service
# firewall-cmd --zone=public --add-port=21/tcp --permanent Warning: ALREADY_ENABLED: 21:tcp success
# firewall-cmd --zone=public --add-port=20/tcp --permanent Warning: ALREADY_ENABLED: 20:tcp success
# firewall-cmd --zone=public --add-port=10090-10100/tcp --permanent Warning: ALREADY_ENABLED: 10090-10100:tcp success
On 05/24/18 12:55, Todd Chester wrote:
On 05/23/2018 08:56 PM, Ed Greshko wrote:
# firewall-cmd --info-zone=FedoraWorkstation FedoraWorkstation (active) target: default icmp-block-inversion: no interfaces: enp0s3 sources: services: dhcpv6-client ssh samba-client mdns ftp ports: 1025-65535/udp 1025-65535/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
note that services shows "ftp".
Ah Ha!
# firewall-cmd --info-zone=FedoraWorkstation FedoraWorkstation target: default icmp-block-inversion: no interfaces: sources: services: dhcpv6-client ssh samba-client ports: 1025-65535/udp 1025-65535/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
# systemctl status vsftpd ● vsftpd.service - Vsftpd ftp daemon Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; enabled; vendor pres> Active: active (running) since Tue 2018-05-22 21:42:26 PDT; 24h ago Process: 13218 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exite> Main PID: 13219 (vsftpd) Tasks: 1 (limit: 4915) Memory: 1.3M CGroup: /system.slice/vsftpd.service └─13219 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
May 22 21:42:26 server.storall.local systemd[1]: Stopped Vsftpd ftp daemon. May 22 21:42:26 server.storall.local systemd[1]: Starting Vsftpd ftp daemon... May 22 21:42:26 server.storall.local systemd[1]: Started Vsftpd ftp daemon.
Systemd sure thinks it is a service
There is *no* connection between vsftpd and the firewalld. They are both "services" as far as systemd is concerned.
# firewall-cmd --zone=public --add-port=21/tcp --permanent Warning: ALREADY_ENABLED: 21:tcp success
# firewall-cmd --zone=public --add-port=20/tcp --permanent Warning: ALREADY_ENABLED: 20:tcp success
# firewall-cmd --zone=public --add-port=10090-10100/tcp --permanent Warning: ALREADY_ENABLED: 10090-10100:tcp success
You need to be certain what zone is actually being used.
That is why I asked you to run...
firewall-cmd --get-active-zones
Are you certain the "public" zone is assigned to the interface?
I have one system here running KDE and for sure the active interfaces are in the "public" zone.
[root@meimei ~]# firewall-cmd --get-active-zones public interfaces: enp2s0 wlp0s29u1u2
but on my Gnome VM ....
[root@f27gq ~]# firewall-cmd --get-active-zones FedoraWorkstation interfaces: enp0s3
So, what is your output of.... "firewall-cmd --get-active-zones"
It would make no sense to make "ftp" available on the "public" zone if the interface is using a different zone.
Also, I wouldn't use manual method of opening ports when it comes to ftp. The reason is that I'm not certain that doing it that way will cause the module nf_conntrack_ftp to be loaded.
On 05/23/2018 10:13 PM, Ed Greshko wrote:
You need to be certain what zone is actually being used.
That is why I asked you to run...
firewall-cmd --get-active-zones
Are you certain the "public" zone is assigned to the interface?
I have one system here running KDE and for sure the active interfaces are in the "public" zone.
# firewall-cmd --get-active-zones public interfaces: br0 eno1
Yup, that is the Ethernet card and the bridge for qemu-kvm
On 05/24/18 13:28, Todd Chester wrote:
On 05/23/2018 10:13 PM, Ed Greshko wrote:
You need to be certain what zone is actually being used.
That is why I asked you to run...
firewall-cmd --get-active-zones
Are you certain the "public" zone is assigned to the interface?
I have one system here running KDE and for sure the active interfaces are in the "public" zone.
# firewall-cmd --get-active-zones public interfaces: br0 eno1
Yup, that is the Ethernet card and the bridge for qemu-kvm
And, from a remote system, what do you get when you
telnet vsftphost 21 ?
You should get something like...
[egreshko@meimei ~]$ telnet 192.168.1.107 21 Trying 192.168.1.107... Connected to 192.168.1.107. Escape character is '^]'. 220 (vsFTPd 3.0.3)
On 05/23/2018 10:32 PM, Ed Greshko wrote:
telnet 192.168.1.107 21
$ telnet 192.168.202.10 21 Trying 192.168.202.10... Connected to 192.168.202.10. Escape character is '^]'. 500 OOPS: tcp_wrappers is set to YES but no tcp wrapper support compiled in Connection closed by foreign host.
And "tcp_wrappers is set to YES but no tcp wrapper support compiled" was that same error message Cobian Backup reported
On 05/24/18 13:56, Todd Chester wrote:
On 05/23/2018 10:32 PM, Ed Greshko wrote:
telnet 192.168.1.107 21
$ telnet 192.168.202.10 21 Trying 192.168.202.10... Connected to 192.168.202.10. Escape character is '^]'. 500 OOPS: tcp_wrappers is set to YES but no tcp wrapper support compiled in Connection closed by foreign host.
And "tcp_wrappers is set to YES but no tcp wrapper support compiled" was that same error message Cobian Backup reported
Ahhhh..... You got that error message before and just now telling the list about it?
Go to /etc/vsftpd and remove all references to tcp_wrappers.
FWIW, I don't use tcp_wrappers.
On 05/23/2018 11:07 PM, Ed Greshko wrote:
On 05/24/18 13:56, Todd Chester wrote:
On 05/23/2018 10:32 PM, Ed Greshko wrote:
telnet 192.168.1.107 21
$ telnet 192.168.202.10 21 Trying 192.168.202.10... Connected to 192.168.202.10. Escape character is '^]'. 500 OOPS: tcp_wrappers is set to YES but no tcp wrapper support compiled in Connection closed by foreign host.
And "tcp_wrappers is set to YES but no tcp wrapper support compiled" was that same error message Cobian Backup reported
Ahhhh..... You got that error message before and just now telling the list about it?
It came from Cobian Backup and Cobian's errors are typically meaningless. Sorry.
Go to /etc/vsftpd and remove all references to tcp_wrappers.
mine is /etc/vsftpd/vsftpd.conf
And that fixed it. Thank you! I owe you one!
FWIW, I don't use tcp_wrappers.
I was just using the defaults
On 05/24/18 14:25, Todd Chester wrote:
On 05/23/2018 11:07 PM, Ed Greshko wrote:
On 05/24/18 13:56, Todd Chester wrote:
On 05/23/2018 10:32 PM, Ed Greshko wrote:
telnet 192.168.1.107 21
$ telnet 192.168.202.10 21 Trying 192.168.202.10... Connected to 192.168.202.10. Escape character is '^]'. 500 OOPS: tcp_wrappers is set to YES but no tcp wrapper support compiled in Connection closed by foreign host.
And "tcp_wrappers is set to YES but no tcp wrapper support compiled" was that same error message Cobian Backup reported
Ahhhh..... You got that error message before and just now telling the list about it?
It came from Cobian Backup and Cobian's errors are typically meaningless. Sorry.
Go to /etc/vsftpd and remove all references to tcp_wrappers.
mine is /etc/vsftpd/vsftpd.conf
And that fixed it. Thank you! I owe you one!
Good.
Where do I go to collect? :-) :-)
FWIW, I don't use tcp_wrappers.
I was just using the defaults
Also, tcp_wrappers support was removed in January.... From the changelog
* Fri Jan 05 2018 Ondřej Lysoněk olysonek@redhat.com - 3.0.3-16 - Disable tcp_wrappers support - Resolves: rhbz#1518796 - Fix default value of strict_ssl_read_eof in man page
On 05/23/2018 11:30 PM, Ed Greshko wrote:
On 05/24/18 14:25, Todd Chester wrote:
On 05/23/2018 11:07 PM, Ed Greshko wrote:
On 05/24/18 13:56, Todd Chester wrote:
On 05/23/2018 10:32 PM, Ed Greshko wrote:
telnet 192.168.1.107 21
$ telnet 192.168.202.10 21 Trying 192.168.202.10... Connected to 192.168.202.10. Escape character is '^]'. 500 OOPS: tcp_wrappers is set to YES but no tcp wrapper support compiled in Connection closed by foreign host.
And "tcp_wrappers is set to YES but no tcp wrapper support compiled" was that same error message Cobian Backup reported
Ahhhh..... You got that error message before and just now telling the list about it?
It came from Cobian Backup and Cobian's errors are typically meaningless. Sorry.
Go to /etc/vsftpd and remove all references to tcp_wrappers.
mine is /etc/vsftpd/vsftpd.conf
And that fixed it. Thank you! I owe you one!
Good.
Where do I go to collect? :-) :-)
This would be a good place
:-)
I am a jack of all trades. it astounds me some of the stuff I know.
FWIW, I don't use tcp_wrappers.
I was just using the defaults
Also, tcp_wrappers support was removed in January.... From the changelog
- Fri Jan 05 2018 Ondřej Lysoněk olysonek@redhat.com - 3.0.3-16
- Disable tcp_wrappers support
- Resolves: rhbz#1518796
- Fix default value of strict_ssl_read_eof in man page
That explains it.
<editorial comment> Ah [expletive deleted] !!! </editorial comment>
On 05/22/2018 10:53 PM, Todd Chester wrote:
Hi All,
After upgrading to FC 28 from FC 27, my customer's vsftpd server stopped allowing ftp logins from anywhere.
# systemctl status vsftpd
shows it running and happy (I tried stopping and restarting several times)
There is no complaining in
# journalctl -f
when I attempt to make a connection.
I just get told something is wrong with the username or password.
SELinux alerts are quiet.
What the heck ????
-T
Follow up:
Just posted:
RFE: give us a clue about tcp_wrappers not being supported https://bugzilla.redhat.com/show_bug.cgi?id=1582672
Dear Fedora,
$ rpm -qa vsftpd vsftpd-3.0.3-22.fc28.x86_64
From the changelog
* Fri Jan 05 2018 Ondřej Lysoněk olysonek@redhat.com - 3.0.3-16 - Disable tcp_wrappers support - Resolves: rhbz#1518796 - Fix default value of strict_ssl_read_eof in man page
This causes both "telnet ip 21" and Cobian Backup to give the following error:
500 OOPS: tcp_wrappers is set to YES but no tcp wrapper support compiled in Connection closed by foreign host.
The cure is to remove tcp_wrappers from /etc/vsftpd/vsftpd.confg
GUYS!!!! NOT FUN TO TRY TO FIGURE OUT !!!!!
Request for Enhancement: when starting vsftpd and "tcp_wrappers" is found to be set to "YES", please consider WRITING AN ERROR MESSAGE to the system journal! If it is not supported, vsftpd startup SHOULD COMPLAIN!
Many thanks, -T
On 05/26/18 06:13, ToddAndMargo wrote:
Request for Enhancement: when starting vsftpd and "tcp_wrappers" is found to be set to "YES", please consider WRITING AN ERROR MESSAGE to the system journal!
You should file a BZ. Making an RFE in a mailing list will get you nowhere.
On Fri, May 25, 2018, 5:36 PM Ed Greshko ed.greshko@gmail.com wrote:
On 05/26/18 06:13, ToddAndMargo wrote:
Request for Enhancement: when starting vsftpd and "tcp_wrappers" is
found to be set
to "YES", please consider WRITING AN ERROR MESSAGE to the system journal!
You should file a BZ. Making an RFE in a mailing list will get you nowhere.
-- Conjecture is just a conclusion based on incomplete information. It isn't a fact.
I would humbly suggest not using FTP, at all, ever. I will leave reading of the implicit security concerns as an excercise for the reader, but most all FTP clients should be SFTP capable and in most cases the difference is completely transparent to end users. sshd provides SFTP functionality suitable for many situations with no extra configuration.
-- Pete
On 05/25/2018 03:48 PM, Pete Travis wrote:
I would humbly suggest not using FTP, at all, ever. I will leave reading of the implicit security concerns as an excercise for the reader, but most all FTP clients should be SFTP capable and in most cases the difference is completely transparent to end users. sshd provides SFTP functionality suitable for many situations with no extra configuration.
-- Pete
Hi Pete,
This is an internal ftp server on an internal network. There is not outside access to it. (The firewall kills any attempt to get at it deader than a door nail.)
It is used with Cobian Backup to backup up data files from Windows machines. The reason being is that it messes with Ransonware pretty big time, especially if I decide to make the directories write only.
Cobian Backup has not sshd capability. Windows backup programs leave a lot to be desired.
-T
-
Ed Greshko -
Ed Greshko -
Joe Zeff -
Pete Travis -
Todd Chester -
ToddAndMargo