Centos 6, stock installation, no additional repos added.
vsftp works fine in regular mode, going to ssl I got issues. I get as far as 'directory listing' and it dies. It times out and disconnects.
file: /etc/sysconfig/iptables-config added: IPTABLES_MODULES="ip_conntrack_ftp" (without this line, ftp normally fails, afraid it may be causing issues with the ssl)
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT again, normal ftp fine.
vsftp file below are the additional commands I entered to get ssl/tls up and running.
pam_service_name=vsftpd userlist_enable=YES tcp_wrappers=YES
ssl_enable=YES implicit_ssl=yes <--- tried with and without this and the port 21 below listen_port=21 <-- see above allow_anon_ssl=NO force_local_data_ssl=NO <-- set this to yes so I can still test normal functions force_local_logins_ssl=NO ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO rsa_cert_file=/etc/pki/tls/certs/vsftpd.pem ssl_ciphers=HIGH <-- this was added as I was using filezilla and it wanted different ciphers. without this it would have a tls fatal error, adding this absolved that issue.
Now I have tried playing with the settings and in all cases when it can connect it dies at directory listing. Implicit ssl wants 990, but the listen_port directive can tell it to go to 21. Again, full connect, changes folders, dies at trying to display contents of initial folder.
I have redone the pem a few times and even moved it in and out of the vsftpd folder just for kicks, no joy.
I tried opening port 990 and that made no difference at all (even changing listen_port or leaving it commented out)
so, cannot figure what is up. Most online notes are for non-centos 6 and/or generally follow this same set of commands. Most of the debug threads about this issue deal with plain connections and not tls/ssl.
I can find no solution yet, has anyone out there secured their vsftp server and wanna throw me a bone?
Only this and two other things prevent me from throwing out a nice video tutorial of how to go from a stock install to a fully armed and operational webserver, ssl everywhere, etc....
all nighter and no where with this one. At least not yet.
On 03/01/12 11:09 PM, Bob Hoffman wrote:
vsftp works fine in regular mode, going to ssl I got issues. I get as far as 'directory listing' and it dies. It times out and disconnects.
if you need secure file transfer, use sftp/scp, not ftp-over-ssl... ftp-over-ssl is a mess.
on /Fri Mar 2 02:34:21 EST 2012 /John R. Pierce wrote;
On 03/01/12 11:09 PM, Bob Hoffman wrote:
/ vsftp works fine in regular mode, going to ssl I got issues. I get as
/>>/ far as 'directory listing' and it dies. It times out and disconnects. /
if you need secure file transfer, use sftp/scp, not ftp-over-ssl... ftp-over-ssl is a mess.
Well, I got it working but not sure I want to leave it that way....
1- added these lines to vsftp.conf
listen_port=5000 ftp_data_port=4999 pasv_min_port=5001 pasv_max_port=5100 (hopefully these ports are not used by anything._)
commented out the line, diisabling it. #connect_from_port_20=YES
The above lines solve the issue of the ssl getting kind of lost since the iptable module conntrack cannot quite grasp ssl dealings in this regard. These lines set specific ports to be used for, well, for whatever the heck vsftp needs all those ports for. The min/max could be lower I guess, but what the heck.
IPTABLES required a nice bunch of junk too. -A INPUT -m state --state ESTABLISHED,RELATED -m tcp -p tcp --dport 4999 -j ACCEPT -A INPUT -m state --state NEW,ESTABLISHED -m tcp -p tcp --dport 5000 -j ACCEPT -A INPUT -p tcp --dport 5001:5100 -j ACCEPT
and of course you can kill the port 21 iptable listing as it will not work anymore. (could port 20 and 21 still be used? I guess so, did not test that).
I wonder how safe that is to make such a huge hole in your firewall...?
you can see where the numbers added in vsftp.conf correspond with the iptables set up.
To finalize, here is the additions to the vsftp.conf file
listen_port=5000 ftp_data_port=4999 pasv_min_port=5001 pasv_max_port=5100
ssl_enable=YES allow_anon_ssl=NO force_local_data_ssl=NO force_local_logins_ssl=NO ssl_tlsv1=YES ssl_sslv2=NO ssl_sslv3=NO rsa_cert_file=/etc/pki/tls/certs/vsftpd.pem ssl_ciphers=HIGH
so there you have it, ssl over ftp with centos 6. Not sure how safe the whole 100 ports open thing is (you need ports to be open depending on number of users I guess, I am gonna lower it to 20 I think)
On 03/01/12 11:49 PM, Bob Hoffman wrote:
so there you have it, ssl over ftp with centos 6.
good luck if the end user at the other end is behind a NAT of any sort (soho router, etc).
btw, active/port vs PASV is at the choice of the CLIENT, not the server. really makes a mess of this stuff, hence my statement that ftp-over-ssl was an abomination.
============================ John R. Pierce wrote /Fri Mar 2 03:01:21 EST 2012/
On 03/01/12 11:49 PM, Bob Hoffman wrote:
/ so there you have it, ssl over ftp with centos 6.
/
good luck if the end user at the other end is behind a NAT of any sort (soho router, etc).
btw, active/port vs PASV is at the choice of the CLIENT, not the server. really makes a mess of this stuff, hence my statement that ftp-over-ssl was an abomination.
============================== True that. I agree. I would rather ssh and I do. However many people want or need ssh and want it encrypted. They are just gonna have to do their own thing and figure it out on their end. This is all I am gonna do to work on it. It works.
I have no idea why ftp makes it like that. That whole range of ips it needs. Without adding those ips the ssl connection will die and get lost.
I agree it is a mess. And 5 hours later I am not gonna go any further. If they are behind something, they better learn about scp or putty... :)
On 03/02/12 12:14 AM, Bob Hoffman wrote:
I agree it is a mess. And 5 hours later I am not gonna go any further. If they are behind something, they better learn about scp or putty... :)
for the windows clients, `winscp` is quite handy. or filezilla, either are freeware GUI clients for scp/sftp.
john R Pierce wrote /Fri Mar 2 13:01:14 EST 2012/
On 03/02/12 12:14 AM, Bob Hoffman wrote: / I agree it is a mess. And 5 hours later I am not gonna go any further.
/>>/ If they are behind something, they better learn about scp or putty... :) /
for the windows clients, `winscp` is quite handy. or filezilla, either are freeware GUI clients for scp/sftp.
True and that is what I use. but this is in regards to people who are doing websites. They usually use a site builder like dreamweaver and the like. Using ssh with dreamweaver includes trying to tunnel through ssh which a basic user would be lost trying to do. Other free and paid ones have issues or cannot ssh at all. Thus, the need, as a webserver, to allow this if needed (ftp..and more securely ftp over ssl).
If they get in a situation where they cannot ftp then they will need to do ssh.
The site builders do automatic update/upload of files changed on the local disk to the remote web folder, thus programs like winscp and stuff are not useful to them.
AS an option, ssl over ftp is better than naught since they are going to be using it anyway. However, as you mentioned, there are situations where it will fail because of the ssl.
For a webserver there is little choice but to add ftp unless the user is very proficient at setting up ssh tunneling or other ssh options with a site builder program.
heck, I am just proud I was able to make the dang thing work. Hopefully soon ftp will die out and ssh only will be the way.
-bob
On Fri, 02 Mar 2012 13:59:48 -0500 Bob Hoffman wrote:
True and that is what I use. but this is in regards to people who are doing websites. They usually use a site builder like dreamweaver and the like. Using ssh with dreamweaver includes trying to tunnel through ssh which a basic user would be lost trying to do. Other free and paid ones have issues or cannot ssh at all. Thus, the need, as a webserver, to allow this if needed (ftp..and more securely ftp over ssl).
Have you looked at sitecopy? http://www.manyfish.co.uk/sitecopy/
It makes it pretty simple for end users to do this. I believe it's supposed to run under Windows, though I've never tried that.
-
Bob Hoffman -
Frank Cox -
John R Pierce