This is not a Perl solution, but if the remote end has an ssh daemon running, you can use SSH tunneling to connect to the remote database:

ssh -fNg -L 6603:127.0.0.1:3306 remote_user@mysql.example.com
[download]

Then you connecto to localhost:6603, and the communication should get forwarded to the remote machine.

To do this transparently from Perl, I would launch ssh in the background like this:

my $ssh_pid= open("ssh -fNg -L 6603:127.0.0.1:3306 remote_user@mysql.e
+xample.com |")
    or die;

my $dbh= DBI->connect("dbd:mysql...");

...

# tear down the connection
kill -9 => $ssh_pid;
[download]

Right, I am very familiar with that technique. However, if you'll note from my post, my design goals dictate that I establish the tunneled connection without the use of exec() or open() calls to system binaries like the SSH client binary (/usr/bin/ssh) or socat.

I am not looking for how to do this from the shell; I am looking to do this completely from within the confines of my Perl application, mostly for portability issues, but also because this "application" I'm working on will be implemented as a custom module in an API I am designing.

Dependence on external programs in this situation seems sloppy and hard to maintain. I am looking for my fellow developers to simply "use" my module and not have to worry about installing anything else besides other Perl modules.

Then, there is only a realistic way to do that: write your own ssh implementation using Net::SSH2 able to redirect connections on a TCP port to the remote MySQL port trough SSH.

Then in your module run this proxy in a new thread or process.

May I cordially suggest that this is a perfect application for VPN ... whether you do it in local software or even in the built-in VPN capability of a modern router device.

Simply establish a secure tunnel to the target system, preferably using digital certificates, and the entire problem goes away.   The two systems simply talk to one another, over what appear to each of them to be a “local” connection, and .. mirabile dictu! .. the connection is secure!   Courtesy of a third-party agent that is quite unknown to (and therefore, no longer a concern to) either of them.   Priceless!™

May I cordially suggest that this is a perfect application for VPN ... whether you do it in local software or even in the built-in VPN capability of a modern router device.

Simply establish a secure tunnel to the target system, preferably using digital certificates, and the entire problem goes away.   The two systems simply talk to one another, over what appear to each of them to be a “local” connection, and .. mirabile dictu! .. the connection is secure!   Courtesy of a third-party agent that is quite unknown to (and therefore, no longer a concern to) either of them.   They no longer have to take any special steps at all to secure the connection ... they may simply take for granted that it is. “Priceless!”™

I agree that a VPN would help certainly fix the problem, but again - I have a design requirement that states that there can be no external dependencies. The solution must live completely within the Perl code.

Another restriction is that I am trying to avoid any bootstrapping of the remote system, and using a VPN would defeat this requirement as well.

OpenSSH has native support for creating VPNs (no external programs required). Though it must be enabled on the configuration and requires root access.

Net::OpenSSH looks like a prime candidate. In my original post, I wrote:

I've also looked for similar questions about tunneling in general, and have looked at say, the Tunnels section of the Net::OpenSSH perldoc, but can't wrap my head around how I would create a driver handle that connects over the pipes created by Net::OpenSSH's open_ex method...

So really, I suppose my entire post could have been distilled down to "How do you make DBI connect with DBD::mysql over Net::OpenSSH tunnels?" but I did not want to necessarily dis-avail myself of other possible solutions. I shouldn't have been so quick to dismiss the VPN solution out-of-hand, especially seeing that is, as Salva alluded to above, what Net::OpenSSH's perldoc "Tunnels" section is referring to.

However, these are just wrappers over the sytem-installed ssh and not pure Perl solutions, so if they 'hide the underlying system' enough or not for you remains your decision.

In the absence of any other viable solution, I suppose I may have to settle for something in this approach. The reason I'm hesitant to use wrappers for system binaries is because I'd like to wrap this up in an easily-distributed module to my local team of co-devs, and did I mention the target OS will eventually be Windows?

Looks like Net::OpenSSH isn't supported on Windows, so that's out. Probably should have checked that requirement beforehand. Tunneling and VPNs likely would not have worked here either because, Windows.

I suppose I'll have to find another path.

I've updated my original post with my conclusions.

Thank you everyone for sharing your insights. Even though I was not able to find exactly what I was looking for I did come away much more informed about the capabilities and limitations of the SSH modules on CPAN.