MySQL Bugs: #71341: Provide option to use existing SSH infrastructure instead of built-in

Bug #71341	Provide option to use existing SSH infrastructure instead of built-in
Submitted:	10 Jan 2014 10:45	Modified:	22 Aug 2014 15:45
Reporter:	Johan De Meersman	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Workbench	Severity:	S4 (Feature request)
Version:		OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	ssh local configuration agent

Description:
Workbench currently uses it's internal code for making SSH jumps. This works fine in and of itself, but it also ignores any existing configuration the user has for his local SSH client.

In my particular situation, I have a number of ssh-jump routes set up, that sometimes even consist of several consecutive jumps. There is currently no way to set this up in Workbench; but if the software were to use the native SSH libraries, all such configuration would transparantly work as expected.

How to repeat:
Attempt to connect to a MySQL server that is more than one SSH jump away.

What SSH libraries are you referring to?

Libraries may have been the wrong word, but the local SSH client and everything related - the point is to use the existing configuration, instead of using custom code that might add security vulnerabilities or become incompatible at some point.

So you want something like an option where you'd specify the command to start the tunnel, where you'd enter your usual ssh command for tunneling and another to shut it down?

No, the ideal would be to just use the platform's *native* ssh command - on linux /usr/bin/ssh. That way, all the setup that I've already got in my ~/.ssh/config will automatically be used; whereas if I had to manually specify the whole commandline to perform three or more jumps it'd still be an ungodly mess :-)

Having a configuration option to define what the local ssh command *is*, is a welcome feature, too, of course.

This is issue is the source of almost all ssh issues on this bug tracker. Please use the system supplied facilities for ssh, including the ssh agent! There is no way you can accommodate even the most common use cases by rewriting everything.

For example: My particular issue is that my private ssh key is not on my computer (this is normal with both agent-forwarding and physical rsa tokens). This works fine with any other software because everyone else just connects to the ssh agent. You should really get rid of you own ssh code on linux and osx, otherwise worbench will never work for a large fraction of people.