Bug #75075 Could not acquire management access for administration
Submitted: 2 Dec 2014 17:54 Modified: 9 Sep 2015 16:41
Reporter: Dmitry Chorine Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench Severity:S1 (Critical)
Version:6.2.4.12437 OS:Linux (CentOS Linux release 7.0.1406 (Core))
Assigned to: CPU Architecture:Any

[2 Dec 2014 17:54] Dmitry Chorine
Description:
after upgrading to latest version of MySQL Workbench 6.2.4, I now not able to open _ANY_ of my connections that I was able to open prior to upgrade (6.2.3):

message I get every time I try to log in is:

Could not acquire management access for administration

UnboundLocalError: local variable 'chan' referenced before assignment

How to repeat:
upgrade to latest 6.2.4 and try to open a connection

Suggested fix:
n/a
[2 Dec 2014 20:14] Dmitry Chorine
error

Attachment: Screenshot from 2014-12-02 12:30:25.png (image/png, text), 12.99 KiB.

[2 Dec 2014 22:15] MySQL Verification Team
Thank you for the bug report. Which WorkBench package you installed on CentOS 7 or it`s self-compiled?. Thanks.
[2 Dec 2014 22:19] Dmitry Chorine
I updated my package "mysql-workbench-community" to latest version:

[alexus@wcmisdlin02 ~]$ rpm -q mysql-workbench-community
mysql-workbench-community-6.2.4-1.el7.x86_64
[alexus@wcmisdlin02 ~]$ sudo grep mysql-workbench-community /var/log/yum.log
Nov 26 11:08:03 Updated: mysql-workbench-community-6.2.4-1.el7.x86_64
[alexus@wcmisdlin02 ~]$
[2 Dec 2014 23:48] MySQL Verification Team
CentOS 7

Attachment: WB_ON_CENTOS7.png (image/png, text), 177.35 KiB.

[2 Dec 2014 23:52] MySQL Verification Team
I couldn't repeat see prior attached picture. Try to rename  the ~.mysql/workbench/connections.xml as backup file so it can be created again when started and create new connections. Thanks.
[3 Dec 2014 16:14] Dmitry Chorine
I am able to connect to localhost (socket or tcp/ip over ssh), yet not to a remote host, however I'm able to connect to remote host using mysql CLI client, 

I'm getting "Cannot Connect to Database Server"

Your connection attempt failed for user 'root' from your host to server at 127.0.0.1:3306:
  Tunnel error: Remote connection to 127.0.0.1:3306 failed: EOFError()

yet CLI:

[alexus@wcmisdlin02 ~]$ ssh XXX "mysql -h127.0.0.1 --execute='SELECT VERSION();'"
VERSION()
5.1.73-log
[alexus@wcmisdlin02 ~]$
[8 Dec 2014 20:01] Dmitry Chorine
I just created yet another connection using "Standard TCP/IP over SSH" and as mysql host specified "127.0.0.1", mysql wb completely ignores ssh part and connects to '127.0.0.1" instead.

any ETA on fix?
[9 Dec 2014 9:10] Robert Orakel Buchholz
Same issue on Fedora 20.
[9 Dec 2014 15:38] Diego Villamil
I have the same problem with 6.2.3.12312 build 2280 (64 bits) on Ubuntu 14.10. In StackOverflow, someone suggested it has to do with Python 2.x vs 3.  
http://stackoverflow.com/questions/27070957/database-ssh-connection-cannot-be-established-...
[12 Dec 2014 2:06] Leonardo Huerta
The issue is with the file wb_admin_ssh.py line 686
I'm currently using arch linux and that file is located under 
/usr/lib/mysql-workbench/modules/

The problem is that the assignment of the variable is inside a try but it is also used in the except.

I fixed it by adding 
char = None
at the top of the function.

After that I'm getting another issue.
[12 Dec 2014 3:21] Leonardo Huerta
I found the issue after fixing the 'chan' error, I had another issue with paramiko saying 
ERROR Could not determine remote OS details
I looked in the logs and the real issue was
TypeError: wba_open_channel() got an unexpected keyword argument 'window_size'

Because this is part of paramiko and I didn't wanted to mess with the library I changed the line 646 in wb_admin_ssh.py
from 
channel = transport.open_session()
to
channel = transport.open_channel('session')

This fixed the issue and I'm able to connect.
[12 Dec 2014 7:03] Leonardo Huerta
Looking further in the window_size error, I still have the issue when trying to add a new connection and then click configure server management, it runs a couple of test on the server and those were failing, I checked the logs and the same error about window_size.
I checked that they override the function open_channel on the file wb_admin_ssh.py line 140
paramiko.Transport.open_channel = wba_open_channel

I really don't know much about paramiko, just starting looking into it because of this, but checking the source code that function has the following signature
def open_channel(self, kind, dest_addr=None, src_addr=None, window_size=None, max_packet_size=None) 

I just modified the function wba_open_channel to accept those parameters and now it is working with no errors.

def wba_open_channel(self, kind, dest_addr=None, src_addr=None, timeout = None, window_size=None, max_packet_size=None)
[17 Dec 2014 13:20] Marcin Szalowicz
Hi Dmitry, Leonardo
can you please provide paramiko version you've got installed on your machine?
[17 Dec 2014 14:34] Diego Villamil
Following Leonardo's solution didn't have an effect on my software  =(  
I'm on Kubuntu 14.10.  MySQL Workbench 6.2.3.12312.
[19 Dec 2014 5:41] Leonardo Huerta
I'm using paramiko 1.15.1-1

I pasted the file wb_admin_ssh.py if you want to check my changes
http://pastebin.com/VMiyMXEZ
[19 Dec 2014 15:54] Dmitry Chorine
Marcin Szalowicz:

I believe "paramiko" is version 1.15.1 (python-2.7.5-16.el7.x86_64).
[22 Dec 2014 1:19] Remy FALCO
Hi all,

Please see below the part of the code that produce this issue when using paramiko newer then 1.14.99. The problem is located in wb_admin_ssh.py line 88.

if (server_version_str2tuple(paramiko.__version__) <= (1, 14, 99)):
    m.add_int(self.window_size)
    m.add_int(self.max_packet_size)

If paramiko is newer than 1.14.99 then the message to open a new channel will not contain the window size as well as the max packet size. In this situation the server will decode the message with a wrong value for the window size a so drop the connection.
[23 Dec 2014 16:13] Dmitry Chorine
Marcin Szalowicz

[alexus@wcmisdlin02 ~]$ rpm -q python-paramiko
python-paramiko-1.15.1-1.el7.noarch
[alexus@wcmisdlin02 ~]$ sudo grep python-paramiko /var/log/yum.log | tail -1
Nov 26 11:07:35 Updated: python-paramiko-1.15.1-1.el7.noarch
[alexus@wcmisdlin02 ~]$
[7 Jan 2015 15:59] Dmitry Chorine
temporary fix/workaround:

[alexus@wcmisdlin02 ~]$ sudo yum downgrade python-paramiko
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: centos.mirror.nac.net
 * epel: mirrors.ptd.net
 * extras: mirrors.seas.harvard.edu
 * updates: mirror.cc.columbia.edu
Resolving Dependencies
--> Running transaction check
---> Package python-paramiko.noarch 0:1.12.4-1.el7.centos will be a downgrade
---> Package python-paramiko.noarch 0:1.15.1-1.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package              Arch        Version                     Repository   Size
================================================================================
Downgrading:
 python-paramiko      noarch      1.12.4-1.el7.centos         extras      900 k

Transaction Summary
================================================================================
Downgrade  1 Package

Total download size: 900 k
Is this ok [y/d/N]: y
Downloading packages:
python-paramiko-1.12.4-1.el7.centos.noarch.rpm             | 900 kB   00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : python-paramiko-1.12.4-1.el7.centos.noarch                   1/2 
  Cleanup    : python-paramiko-1.15.1-1.el7.noarch                          2/2 
  Verifying  : python-paramiko-1.12.4-1.el7.centos.noarch                   1/2 
  Verifying  : python-paramiko-1.15.1-1.el7.noarch                          2/2 

Removed:
  python-paramiko.noarch 0:1.15.1-1.el7                                         

Installed:
  python-paramiko.noarch 0:1.12.4-1.el7.centos                                  

Complete!
[alexus@wcmisdlin02 ~]$
[14 Jan 2015 17:13] Joaquin Berlanga
In Fedora 20, a downgrade from 'python-paramiko-1.15.1-1.fc20.noarch' to 'python-paramiko-1.10.1-2.fc20.noarch' (yum downgrade python-paramiko) solves the problem and SSl connections works.

In Fedora 21, there isn't another package to downgrade

greetings,
Joaquin
[8 Sep 2015 23:34] MySQL Verification Team
Please try version 6.3.4. Thanks.
[9 Sep 2015 16:37] Dmitry Chorine
I believe it was resolved earlier already...

[alexus@wcmisdlin02 Desktop]$ rpm -q python-paramiko
python-paramiko-1.15.1-1.el7.noarch
[alexus@wcmisdlin02 Desktop]$ rpm -q mysql-workbench-community
mysql-workbench-community-6.3.4-1.el7.x86_64
[alexus@wcmisdlin02 Desktop]$
[9 Sep 2015 16:41] MySQL Verification Team
Thank you for the feedback.
[7 Sep 2017 12:54] Chiranjeevi Battula
http://bugs.mysql.com/bug.php?id=87689 marked as duplicate of this one.