Just wanted to revisit this article with some of my newest discoveries in the quest for a perfect mini server! The PureFTPd software I installed looks like a great option, especially for those that want to set up virtual users to allow clients to access only certain directories such as a web-hosting situation.

I still didn’t figure out the “fallback to [C]” errors in my console log on that front, and although it seemed to be working correctly, I decided to go in another direction for a 2nd option. This option involves using the built-in remote login over SSH capabilities built into MacOS X. But to make it more secure, there are a couple of things we need to do first.

First, I followed the tutorial on using the software “SSH Helper” at http://www.gideonsoftworks.com/SSHHOWTO/SSH-HOWTO.html

This tutorial walks you through configuring the SSH daemon, and shows you how to create your own public/private key files. You want to use “SSH Helper” on both the client computer you’d like to connect from, and the Mac Mini Server. Upload your created public key from your client machine to the mac mini server (don’t forget to set a passphrase in your key for more security) and add that public key to the list of allowed users. I unchecked the box in “Server Settings” for “Allow Password Authentication”, which only allows connections to be made from clients who possess the right key file AND have the passphrase for the key. I also checked the box to “Allow Secure FTP access” and clicked the button at the top of the window to “Install Server Settings”.

At this point, I went back to the client machine and ran the command “ssh -l username macmini.domainname.com” and if it is the first time you’ve connected, it will ask you if you want to accept the server’s public key file (answer “yes”) and then it will ask you for your passphrase that you set on your client public key file. At that point, you should have a shell and the commands you run will work just as if you were sitting in front of the Terminal in the mini! And (if I understand the technology correctly) noone but you should be able to log into your mini unless they get ahold of your private key file, and guess your username and passphrase. This is inherently more secure than allowing anyone on the internet to try and guess your username and password for a remote login.

Now that you have SSH logins enabled, you can fire up your favorite SFTP client for a “FTP” connection over SSH, which encrypts the communication between your client and mini when logging in (but does not encrypt the datastream possibly? I haven’t been able to verify that yet). In Cyberduck, it finds the private key file and you can choose it to connect with, instead of using a username/password.

Another very cool option is to follow the directions from the web address below to run a VNC server on the mini that only accepts connections from “localhost” and uses an SSH tunnel to encrypt the insecure VNC traffic from your remote client computer. I just followed these directions, and in about 5 minutes was looking at and interacting with the screen of my MiniServer over the internet on my PowerBook! For people who feel more comfortable using a GUI than the terminal to change settings over the internet, this is perfect, and it is MUCH cheaper than Apple Remote Desktop. When I tested my configuration, large changes to the screen only sent 50KB/s for a second and then the total bandwidth for viewing the screen was back down to 5-10KB/s, and it drops to nearly zero if no changes to the display are happening. On my PowerBook, I used my VNC client of choice, “VNCThing”, available on versiontracker.com.

http://www.macmod.com/content/view/89//

(WARNING: Enabling Remote Login on SSH is more of a security risk than not starting the service at all, but I believe the steps taken in the tutorials offer good security to take away most if not all of the risks…anyone can please set me straight if you have more knowledge in this area and can offer additional security suggestions)

Firstly, opening just port 21 on the firewall of the mini does not allow incoming connections to be made (at least, using the Cyberduck FTP client, which doesn’t allow one to specify the ports to be used for passive FTP connections if you’re coming through a NAT router). The initial connection would be made, but Cyberduck hangs and times out when trying to list the home directory. Unfortunately, it tries to use different ports each time you connect. In multiple tries, in my ipfw.log, Cyberduck was trying to access ports 14612, 53719, 45564, etc. Opening up ports 1024-65535 (the ports opened by the firewall in 10.3) on the mini running 10.4 finally allowed the connection to be made.

I followed the documentation on enabling SSL/TLS sessions by creating a certificate in the PureFTPd Manager software, and changing to “Mixed Mode”. When using cyberduck 2.5.5 to setup an sftp session using SSL/TLS, I got the certificate shown and thought I’d made a secure connection, but then I noticed the following line in the console log on the computer running Cyberduck.

182211 [] WARN ch.cyberduck.core.ftps.SSLProtocolSocketFactory – No data channel security: Fallback to [C]

Unchecking the “use unsecured connection if not supported” option in the FTP-TLS section of Cyberduck preferences resulted in the loss of ability to connect to the mini anymore (earlier connections had fallen back to regular FTP I suppose?).

To make things even more confusing, I just used PureFTPd Manager to change the preferences for TLS Sessions to “TLS Only”, restarted the ftp daemon, and am able to connect successfully (when the cyberduck “use unsecured connection if not supported” is checked) even though I would expect that the ftp server is now not accepting cleartext sessions? The error message about fallback to [C] still shows up in my client’s console.log with each new connection.

On second thought, does this just mean that the exchange of passwords is still encrypted but Cyberduck is just unable to secure all of the following communication of the data channel?

Perhaps someone else can comment with their findings!