| Bug #65672 | Crash when using key-based SSH authentication and username is incorrect | ||
|---|---|---|---|
| Submitted: | 19 Jun 2012 14:03 | Modified: | 10 Jun 2013 1:25 |
| Reporter: | Craig Fowler | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Workbench: SQL Editor | Severity: | S2 (Serious) |
| Version: | 5.2.40 | OS: | Linux (Debian testing) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Connection, crash, ssh | ||
[19 Jun 2012 14:06]
Craig Fowler
Full backtrace from the crash
Attachment: crash.txt (text/plain), 25.64 KiB.
[20 Jun 2012 19:59]
Rafael Antonio Bedoy Torres
Hello Craig, Thanks for your report. Can you please add more details about the problem you have?, like the OS of your local and remote machines and what MySQL version you are using. Thanks in advance!
[22 Jun 2012 15:45]
Craig Fowler
The local machine is Debian Testing (Squeeze + Wheezy) x64. I have been able to reproduce this on Workbench 5.2.38 and 5.2.40 (I am using the 64-bit .deb installer for Workbench). I can also reproduce the problem when the remote machine is either [Windows Server 2008 + Cygwin + sshd] or [Debian Squeeze + sshd]. I strongly suspect the MySQLd version on the remote machine will be irrelevant because this bug relates to a crash caused by a failure to establish an ssh tunnel. Until the ssh tunnel is established successfully, Workbench has no communication (cannot have any communication) with the remote MySQL server. For the sake of completeness though, on the Debian Squeeze remote server the MySQL version is 5.1.49.
[2 Oct 2012 20:36]
Armando Lopez Valencia
Verified in:
Ubuntu 12.04x64 (Client)
Ubuntu 10.04x86 (Server)
WB 5.2.44
armando@Ubuntu12:~$ mysql-workbench
Initializing AdvancedSidebar factory method
Initializing mforms factory
Creating WBOptions
Ready.
** Message: overview.home built-in command is being overwritten
Thread started
/usr/lib/python2.7/dist-packages/paramiko/client.py:95: UserWarning: Unknown ssh-rsa host key for 192.168.1.129: 674aea99ea37ae599757d5d957f760a8
(key.get_name(), hostname, hexlify(key.get_fingerprint())))
Exception in thread Thread-2:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
self.run()
File "/usr/share/mysql-workbench/sshtunnel.py", line 108, in run
if not self._connect_ssh():
File "/usr/share/mysql-workbench/sshtunnel.py", line 206, in _connect_ssh
except BadHostKeyException, exc:
NameError: global name 'BadHostKeyException' is not defined
Thread started
Exception in thread Thread-5:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
self.run()
File "/usr/share/mysql-workbench/sshtunnel.py", line 108, in run
if not self._connect_ssh():
File "/usr/share/mysql-workbench/sshtunnel.py", line 206, in _connect_ssh
except BadHostKeyException, exc:
NameError: global name 'BadHostKeyException' is not defined
Thread started
Exception in thread Thread-8:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
self.run()
File "/usr/share/mysql-workbench/sshtunnel.py", line 108, in run
if not self._connect_ssh():
File "/usr/share/mysql-workbench/sshtunnel.py", line 206, in _connect_ssh
except BadHostKeyException, exc:
NameError: global name 'BadHostKeyException' is not defined
(mysql-workbench-bin:2024): glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: call to empty boost::function
Trace/breakpoint trap (core dumped)
[28 May 2013 9:03]
Craig Fowler
Just had a conversation on IRC about whether I can still reproduce this. I have tried and can reproduce it on 5.2.47 as described.
[28 May 2013 16:48]
Alfredo Kojima
Posted by developer: SSH tunnel handling was fixed for initial connection and reconnections.
[10 Jun 2013 1:25]
Philip Olson
Posted by developer: Fixed as of the upcoming Workbench 6.0.2, and here's the changelog entry: MySQL Workbench could crash after modifying a functioning SSH key-based authenticated stored connection with incorrect credentials. Thank you for the bug report.
Description: MySQL Workbench crashes when failing to connect using SSH key-based authentication & a pre-stored connection. The story as to how I managed to discover this was that I changed my username on a remote ssh server and had forgotten to update the stored username for the connection in MySQL Workbench's SQL editor. When connecting with these (now invalid) credentials, instead of offering a friendly "could not establish SSH tunnel" message, Workbench crashes. How to repeat: Create a saved connection in the SQL Editor that uses SSH & key-based authentication, use correct credentials to set it up. Now, shut Workbench down and re-open it. Choose "Manage Connections" and alter the "SSH username" field of the saved connection so that it is now incorrect. Save the connection and again shut Workbench down and re-open. Double-click that connection to start it. Workbench crashes. --- Here's what I think is the "interesting" bit of the command-line info that WB spits out. I'll paste the whole thing into an attachment though. --- ERROR: Traceback (most recent call last): File "/usr/share/mysql-workbench/sshtunnel.py", line 205, in _connect_ssh self._client.connect(self._server[0], self._server[1], username=self._username, key_filename=self._keyfile, password=self._password) File "/usr/lib/python2.7/dist-packages/paramiko/client.py", line 332, in connect self._auth(username, password, pkey, key_filenames, allow_agent, look_for_keys) File "/usr/lib/python2.7/dist-packages/paramiko/client.py", line 493, in _auth raise saved_exception AuthenticationException: Authentication failed. Suggested fix: From a glance at the stack trace, it looks like Workbench's python interface to Paramiko fails to catch and deal with an exception that Paramiko raises.