FTP with the SSL modules turned on
Essentially I need this command translated from HP-UX to Linux.
I want to use the core ftp built-in to the Redhat 6.5, not an aftermarket package like lftp. I got lftp working and connecting but the problem is, lftp does not play well with the mainframe I connect to and I cannot actually get any of the data sets. The commands are not the same. Can I use the standard ftp with the SSL modules enabled per below example? Linux ftp does not understand the -z option. Else, what are some other FTPS packages I can use on Linux? lftp hasn't really worked for me due to mainframe difficulties. ftp -p -z secure \ -z logfile=/var/tmp/ftps.log \ -z config=tls1 \ -z CApath=$FTPS/certs \ -z CAfile=$FTPS/certs/root_cert.pem \ -z rsacert=$FTPS/certs/client_cert.pem \ -z rsakey=/etc/ftpd/security/private/current.key $IP 800 |
No - there is no native way to do ftps (ftp with SSL) from Linux. Regular ftp works fine (but shouldn't be used due to lack of security unless you're gpg/pgp encrypting files). You have to use lftp to talk (or some other tool that would require even more work based on my past reading) if you want to reach an ftps target.
lftp is hard to work with but I've gotten it to work to various remote sites. You have to be cognizant of the setup of your target's ftps. Is it implicit or explicit ftps? Does it actually provide a CA verified certificate or is it maybe self-signed? If the latter or if you don't have root and intermediate certificates for the CA on the Linux system you might need to import those or self signed certificate. You want to get to know the various options supported by the ftps server. (e.g. those that allow you to ignore the certificate if you trust the site, or force the certificate, etc...) Using lftp with -dv options will make it give you a fair amount of verbosity and debugging output that will help. Command line that works for me to login: Code:
lftp -d -p <remote host port e.g. 21 or 20021> -u <userlogin ID on remote>,<password on remote host> <remote host name> Some script testing syntax that worked for me: Code:
REMHOST=<remote host name or IP> |
Quote:
|
Quote:
The destination machine, a mainframe does not have SSH (SFTP/SCP) support, otherwise I would use that for sure bypassing all this FTPS stuff. I got LFTP to work and connect. It still does not work very well. The problem is my destination machine is mainframe. And it does not play well with lftp. It works better with the regular ftp. When I 'cd' to a directory or get a 'file', what they call 'dataset', it's complicated. The syntax is not the same as with ftp. You have to give commands dataset.directory type format. So this is nowhere near as simple as a unix-unix or windows to unix type setup. I need a different FTP client on Redhat other than LFTP. Or get them to enable SSH on mainframe which is not happening. Or use ftp with the SSL package like in the example above, which is strangely not possible either on Linux (but possible on HP-UX). |
SFTP can be enabled on the remote host without also allowing access to an interactive shell. That'd be the way to go.
|
Quote:
Did you try doing "?" after attaching to the mainframe? Did you turn on debugging and verbosity as I suggested. It is important to note that lftp is a session tool. It is not staying logged in as you might think but rather issues new commands to the remote using the credentials you supplied when you started lftp. This caused me grief early on because I thought it logged in successfully when I started lftp and it was only after viewing debug/verbose output that I realized it was attempting and failing to login when I ran individual commands within it. You can try other tools such as wget but when I investigated doing that before it didn't seem like it was going to be easier than doing lftp. A link about doing wget (there are probably others you can find) is: https://stackoverflow.com/questions/...ssl-encryption |
Quote:
The remote host is a z/OS, a 64-bit operating system for IBM mainframes. I have no control over it. They just did an upgrade and could have included the SSH support but didn't. I wonder if it's a security guideline of some kind. They want to force users to use login/password. I am also aware that SSH keys are just as secure, if not more so. It's a half-technical, half political situation. |
Try ncftp or ncftpbatch instead then. lftp is not what you are treating it like.
|
Does ncftp support the SSL modules?
this is from the FAQ: Q. Does NcFTP support any secure FTP modes a la SFTP/SSL/SSH Tunnels? A. NcFTP does not have any built-in support for encryption or secure FTP of any type. We do not support any type of interaction with hacks such as FTP over SSH tunnels. We may implement a secure FTP mode at a future date, but please do not ask for an ETA. |
Sorry. It has been too long since I've used any of them. If you're still open to random suggestions, what about curl? It lists FTPS support and is usually easy to include in scripts.
|
Quote:
a) It may use implicit or explicit setup which are different. b) It may use atypical ports. c) It may require you to set other options like those I did in my working script: set ftp:ssl-force true set ftp:ssl-protect-data true set ssl:verify-certificate false Those 3 "set" commands are only a few of dozens of possible options you might need. |
Quote:
etcetera, does this pertain to uploading or downloading? If this is only about downloading it would be easier to use HTTPS. |
Quote:
I understand what you're trying to do, but if you got lftp to work, have you considered using an expect script to do what you need? Or use vsftpd which does support SSL? It's even in the Red Hat knowledgebase: https://access.redhat.com/solutions/3436 Since you're using RHEL 6, you can just type "yum install vsftpd"..providing you're paying for RHEL. https://access.redhat.com/documentat...nsfer_protocol |
Quote:
|
Quote:
Still, an expect/other script using lftp (which the OP says is working), might be a solution, since the OP's sticking point seems to be script-interaction is different between FTP and LFTP. The OP seems to also be hamstrung by wanting/needing to stay 100% RHEL, so no third-party solutions are on the table. And having dealt with mainframes before, I would NOT hold my breath on anything being even halfway 'modern'. Always blows my mind that they can't/don't support such basic things like SSH, NTP, or the like. |
All times are GMT -5. The time now is 03:26 AM. |