Talk:Very Secure FTP Daemon

From ArchWiki
Jump to: navigation, search


pam no longer provides (as of 1.1.8-3). The part concerning virtual user no longer works. What is the recommended workaround ?

I've added a new section to the wiki. A simple option is to use Another improvement is how passwords are generated and stored. -- KimTjik (talk) 14:06, 27 February 2014 (UTC)

What is the advantage of using the xinitd approach over adding vsftpd to the Daemon list?

And also, # pacman -S xinitd xinitd: not found in sync db

What is xinitd?

^ xinitd is a typo. xinetd is the real deal.

I've updated this section. As briefly explained xinetd provides enhanced monitoring and controlling capabilities. It can handle a lot of connections, makes extensive logs. I added however a, maybe, subjective opinion that it's not necessary for a basic vsftpd configuration. It's frequently used though in production environments. I believe though that most users here choose vsftpd for its simplicity and performance. -- KimTjik (talk) 22:09, 28 February 2014 (UTC)

Could one add a column that explains the security in /etc/hosts.allow like there is in the ssh wiki page:


# let everyone connect to you
vsftpd: ALL

# OR you can restrict it to a certain ip

# OR restrict for an IP range

# OR restrict for an IP match
vsftpd: 192.168.1.

--Burra 17:11, 11 June 2008 (EDT)

/etc/hosts.allow / deny

Starting vsftpd from xinetd and solo tells me that the /etc/hosts.allow / deny are only used when the vsftpd is started from xinetd.

My addition about "PAM with 'virtual users'"

I don't even know if I've done it the right way, and its the first time ever I do something like this. Hence please give feedback on the quality of it, and let me know if I've done some mistakes.

-- KimTjik

If your intention was to create a hashed password user database to do the PAM authentication then it is not correct. db_load does not handle password hashing by itself, it merely creates a binary database file from the input. A user needs to specify what type of database dump the input to db_load is (hashed, Btree, queue or recno). To show that db_load does not hash passwords you can use the 'strings' command on your database file. It will translate the binary file back into strings and you will be able to read your passwords (password and username have switched places though). For instance place the following into test.txt


Then do

# db_load -T -t hash -f test.txt test.db
# strings test.db

this should exactly print the following on your command line


Thus no password hashing has happened and Someone that obtained the right to access the database could thus read all passwords.

Neburski (talk) 19:05, 7 December 2013 (UTC)

As you can see I've updated this section. As I wrote above it's mainly because PAM doesn't provide anymore. I choose this method because it's not complicated and at the same time I think it addresses the issue about security. -- KimTjik (talk) 22:04, 27 February 2014 (UTC)

Examples for configuring vsftpd

I'm running a private ftp-server here which has some additional features which might not be needed for everyone, like PAM with postgres as backend, IP-based-rules and per-user-settings. Would it make sense to add instructions for this to the wiki, or is it too special?

--IncredibleLaser 08:53, 31 January 2009 (EST)

ip_conntrack_ftp module

I found that I need to load ip_conntrack_ftp module so I can connect to the server in Passive Mode and with iptables running.

If iptables is configured in a stateful firewall manner, then some connections in FTP won't be allowed. I found that loading the ip_conntrack_ftp module on the kernel workder.

--Jstitch 17:35, 1 June 2011 (EDT)