Expose FTPS on a RHEL system to a z/OS mainframe client
yum install -y lftp openssl vsftpd
sudo mkdir /etc/ssl/private
openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem
This will result in the certificate and the key being in the same file. Just alert your z/OS recepient that your file might not be copy/paste. That was all it took in my use case.
anonymous_enable=NO
local_enable=NO
write_enable=NO
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
ssl_ciphers=HIGH
In our use case, we had some discussion about ciphers, but ultimately, HIGH was fine.
From the RedHat Knowledge Base
ssl_request_cert=no
require_ssl_reuse=no
xferlog_enable=YES
xferlog_std_format=NO
log_ftp_protocol=YES
xferlog_enable=YES
This will create a /var/log/vsftpd.log file to support troubleshooting the remote connection (as is quite likely).
listen=YES
listen_ipv6=NO
listen_address=0.0.0.0
userlist_enable=YES
userlist_deny=NO
This combination limits incoming ftp access to a list of users that you
explicitly allow within /etc/vsftpd/user_list. You can review the
contents of that file for more information.
There is a much simpler setup available for you if you are on VSFTPD 3.
In our use case, we were on RedHat 6.10, which had VSFTPD 2.2. With version 3, you can use a local user approach, which we will outline below. With version 2.2, you need to use virtual users, which is an entirely seperate process.
This clipping of a RedHat support article walks through this process.
The fundamental idea includes four components:
- A
virtftplocal user - A root directory to contain files (e.g.
/home/ftpbut it's operator taste where to mount it) - An authentication scheme that creates a directory of 'virtual' usernames and passwords that
vsftpd(andpam.d) can auth against - A per-user configuration file that provides user-specific configuration sufficient to authorize FTP activities.
You should be aware of this security bulletin
regarding the dangers of adding "bad" shells to /etc/shells
chroot_local_user=YES
allow_writeable_chroot=YES
In particular the last setting is only available in vsftpd 3.
The lftp client that you installed in a previous section can be configured
with a file containing these commands to help you.
set ftps:initial-prot "";
set ftp:ssl-force true;
set ftp:ssl-protect-data true;
set ssl:verify-certificate no;
set dns:order "inet inet6";
With this file stored in /tmp/lftp-test.commands, start an lftp process
and provide this at the prompt:
source /tmp/lftp-test.commands
open -u ftpuser,whatever-password-you-picked ftps://127.0.0.1:21/
In our use case, this had to do with including implicit_ssl in the
vsftpd config. When this was removed, the connection proceeded.
The client needs the certificate, since it's self-signed and not a part of the trust chain. Getting to this roadblock before you circulate the certificate is fine.
In our use case, this was because neither the client nor the server was originally set up to use the ports set aside at the firewall layer for PASV mode connections.
- After checking out your setup from the server itself via 127.0.0.1, check your setup from another machine. You will find other items.
- SELinux output: