Drobo

DroboPorts proftpd-1.3.3d FTPS error

I have set up the proftpd-1.3.3d package from DroboPorts.com. FTP is working correctly, but when I try to connect with FTPS (FTP with TLS/SSL), I get an “Operation not permitted” error in retrieving the first directory listing.

The contents of proftpd.log are identical for a successful FTP session and a failed FTPS session, so I’m stumped.

Here’s the full session transcript:Transmit 3.6.9 Session Transcript LibNcFTP 3.2.1 (August 13, 2007) compiled for UNIX Uname: Darwin|mythril.local|10.7.4|Darwin Kernel Version 10.7.4: Mon Apr 18 21:24:17 PDT 2011; root:xnu-1504.14.12~3/RELEASE_X86_64|x86_64 Remote server is running ProFTPD. 220: ProFTPD 1.3.3d Server ready. Connected to drobo-fs.local. Cmd: AUTH TLS 234: AUTH TLS successful error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol Remote server is running ProFTPD. 220: ProFTPD 1.3.3d Server ready. Connected to drobo-fs.local. Cmd: AUTH TLS 234: AUTH TLS successful Cmd: USER ftpuser 331: Password required for ftpuser Cmd: PASS xxxxxxxx 230: User ftpuser logged in Cmd: TYPE A 200: Type set to A Logged in to drobo-fs.local as ftpuser. Cmd: PBSZ 0 Cmd: PROT P 200: PBSZ 0 successful Protection set to Private Cmd: SYST 215: UNIX Type: L8 Cmd: PWD 257: "/" is the current directory Cmd: PASV 227: Entering Passive Mode (192,168,1,113,145,9). Cmd: LIST -a 150: Opening ASCII mode data connection for file list 425: Unable to build data connection: Operation not permitted Cmd: NOOP 200: NOOP command successful Cmd: PASV 227: Entering Passive Mode (192,168,1,113,128,226). Cmd: LIST -a 150: Opening ASCII mode data connection for file list 425: Unable to build data connection: Operation not permitted

If you are using the default configuration, make sure that the permissions on the folder actually allow proftpd to list the content of the folder.

Hmm the docs for the package on DroboPorts.com say that ProFTPD will run as root.

Also, would that explain why it works via FTP but not via FTPS?

Actually, no. That is strange. Have you changed anything in etc/proftpd.conf in the section “” ?

That section contains the FTPS-specific configuration, therefore if there is nothing wrong with FTP, the problem is most likely in there.

Hmm I can confirm that, despite what the docs on DroboPorts.com say, the default configuration runs ProFTPD as nobody:nobody. I’ve also discovered that although I can log in over FTP, I can only browse folders with public permissions, while the majority of the files/folders I need to access have their permissions set to 700 (owned by root:root).

I modified proftpd.conf to run as root:root and restarted, and I’ve confirmed that the proftpd process is now running as root, but this hasn’t resolved either problem (logging in with FTPS or browsing folders with 700 permissions).

Any ideas?

Found it! A little bit of Google-fu got me this thread:

http://forums.proftpd.org/smf/index.php?topic=4440.0

From the thread:

[quote]It’s solved now with the option :

TLSOptions NoSessionReuseRequired
[/quote]

Edit: you can revert back to nobody:nobody.

Using a better FTP client, I’ve discovered that the error being given on FTPS login is “Couldn’t verify certificate chain.”

Here’s what I’m getting in my tls.log file:Jun 16 00:41:50 mod_tls/2.4.1[1624]: using default OpenSSL verification locations (see $SSL_CERT_DIR environment variable) Jun 16 00:41:50 mod_tls/2.4.1[1624]: TLS/TLS-C requested, starting TLS handshake Jun 16 00:41:50 mod_tls/2.4.1[1624]: unable to accept TLS connection: protocol error: (1) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Jun 16 00:41:50 mod_tls/2.4.1[1624]: TLS/TLS-C negotiation failed on control channel

This is the mod_tls section of my proftpd.conf file (I haven’t modified it):<IfModule mod_tls.c> TLSEngine on TLSLog /mnt/DroboFS/Shares/DroboApps/proftpd/var/log/tls.log TLSProtocol TLSv1 TLSRequired off TLSRSACertificateFile /mnt/DroboFS/Shares/DroboApps/proftpd/etc/server.crt TLSRSACertificateKeyFile /mnt/DroboFS/Shares/DroboApps/proftpd/etc/server.key TLSVerifyClient off </IfModule>[hr]
I’ve added to the mod_tls section of my conf file:TLSOptions NoSessionReuseRequired
I’ve also reverted to running as nobody:nobody.

Unfortunately that hasn’t helped. I still can’t connect via FTPS (same error as above) and I still can’t browse non-public folders via FTP.[hr]
Fixed the FTPS certificate chain error by replacingTLSProtocol TLSv1withTLSProtocol SSLv23in proftpd.conf, but now I’m onto another error (Illegal PORT command) while attempting to retrieve the initial directory listing. Trying to Google a solution to that now.

FTP permissions remain my biggest problem, and I’m stumped.

Ahhh, my bad. I thought the server was rejecting the connections.

If the problem is that the client can’t verify the certificate chain, then that’s a feature, not a bug. :slight_smile:

The reason for this is that to offer FTPS, proftpd requires a server certificate. As such, the first time proftpd is started, it generates a brand new server certificate. A self-signed server certificate.

Therefore, when your client gets the server certificate it goes: “what? who is this server? I’ve never seen this signature before, therefore I can’t trust it at all! Abort! Abort!”

There are three ways of solving this:

  1. Tell your FTP client to calm down, and accept self-signed server certificates, or
  2. Tell your FTP client that the server certificate proftpd generated is trustworthy, i.e., add it to its certificate database, or
  3. Buy a proper server certificate for proftpd

My guess is that option 2 is the way to go. That is what I did to my FTP client.

What you are seeing is pretty much the same people see when they access a webpage via HTTPS and the HTTP server provides them with a self-signed certificate. Firefox, for instance, tells you that there is something wrong with the certificate and asks you if you want to add an exception (i.e., add that certificate to its database).[hr]

To be honest, I’m not sure that going to a lower version of the protocol is an indicator of a better client… what client are you using that does not support TLSv1?

Actually I think my client (Transmit 4 for Mac) does support TLSv1, it just doesn’t like the self-signed certificate. Dropping to SSLv23 seems to have gotten around that. I’ll circle back to see if I can get TLS working later.

Meanwhile, I’ve solved the FTPS login problem by setting the PassivePorts directive in proftpd.conf and configuring my router to forward the specified port range to my Drobo FS.[hr]
Great, so now all that’s left to solve is the permissions issue. I’ll start a new thread, as it’s off-topic for this one.