Спроба використовувати MySQL Workbench з TCP / IP через SSH - підключення не вдалося


41

Я не можу підключитися за допомогою TCP / IP через SSH-з'єднання в MySQL Workbench з ПК. Що відбувається?

Я створив базу даних MySQL 5.1 на сервері Ubuntu mysql.myhost.com . Я можу отримати доступ до нього локально. MySQL Workbench (ПК) пропонує встановити з'єднання через TCP через ssh. Він працює на порту 3306 на віддаленому сервері, де командний рядок mysql працює нормально.

Я використовував такі деталі сеансу:

  • Спосіб підключення: TCP / IP через SSH.
  • Ім'я хосту SSH: mysql.myhost.com : 3306
  • Ім'я користувача SSH: мій вхід в Linux
  • Файл відкритого ключа SSH: мій файл місцевого відкритого ключа
  • Ім'я хоста MySQL: 127.0.0.1 MySQL
  • Порт сервера: 3306
  • Ім'я користувача: root

Коли я намагаюся підключитися, я отримую повідомлення про помилку: "Не вдалося підключитися до MySQL на 127.0.0.1:2306 через тунель SSH на mysql.myhost.com з користувачем root"

"Не вдається підключитися до сервера MySQL на" 127.0.0.1 "(10061)"

Як ще один тест - я створив тунель SSH з портом 3306 за допомогою Putty, і я можу підключити OK за допомогою MySQL Workbench через тунель, який пересилає з'єднання з моїм локальним 3306 до віддаленого сервера, як описано вище. Але я не можу заставити "TCP / IP через SSH" працювати в Workbench.

Вторинне запитання: коли Workbench запитує "Шлях до файлу відкритого ключа SSH", чи справді не потрібен мій файл приватного ключа?


4
Добре горе. bugs.mysql.com/bug.php?id=61368 показує, що це ПРИВАТНИЙ ключ ключа, необхідний у форматі OpenSSH. Я дивувався цьому, але не був впевнений.
— Дізлі

Відповіді:


29

Я натрапив на це питання, коли сам зіткнувся з цією помилкою. Нарешті я міг з'ясувати конфігурацію.

  1. Я нічого не торкався в /etc/mysql/my.cnf, у якому вже є bind_address = 127.0.0.1. Тож може підключитися лише localhost.
  2. Я використовую сервер OpenSSH. Таким чином , в конфігураційному файлі / і т.д. / SSH / sshd_config Я не змінився з НЕ до да Пар відповідальних за TCP експедирування, таким чином , AllowTcpForwarding та .
  3. Нарешті, у MySQL WorkBench увійшло наступне.

    • Ім'я хоста SSH: 192.168.0.8:22 (мій сервер SSH слухає порт 22)
    • Ім'я користувача SSH: sshuser
    • Файл ключа SSH: * C: \ Users \ windowsuser \ .ssh \ id_rsa * (має бути приватним ключем, навіть якщо він пише загальнодоступним)
    • MySQL Hostname: 127.0.0.1 (цього не слід змінювати, оскільки сервер MySQL за замовчуванням прив’язаний лише до localhost, який я не змінив)
    • Порт MySQL Server: 3306 (також за замовчуванням)
    • Ім'я користувача: root

Єдине, що вам залишається - це правильно налаштувати ваш SSH-сервер для роботи з ключами, а не паролями. Сподіваюся, що це комусь допоможе.


Одне, що мені потрібно було зробити на стороні сервера, - це переконатися, що / etc / ssh / sshd_config був цей рядок: AuthorizedKeysFile /home/root/.ssh/authorized_keysі що в санкціонованих_кеях був мій ПУБЛІЧНИЙ ключ як запис.
— RyanNerd

Будь ласка, уточніть, чи застосовується крок 2, який набір AllowTcpForwarding yesзастосовується до віддаленого сервера, тобто до хоста, який має екземпляр MySQL, до якого ми намагаємось підключитися; або локальна машина з встановленим MySQL Workbench
— Nam G VU

Крок 2 @NamGVU стосується віддаленого сервера, на якому встановлено MySQL. Особливо до сервера OpenSSH, який забезпечує тунелювання до MySQL через SSH.
— очі

Я намагався, але все-таки не вдався до тунелю. MySQL Workbench пропонує мені прочитати більше деталей помилок у файлі журналу. Чи можете ви знати, де читати?
— Нам Г ВУ

1
У мене це працює сьогодні - потрібна перезавантаження після налаштування AllowTcpForwardingзапису
— Nam G VU

8

Я думаю, що підхід TCP / IP через SSH працює, встановлюючи "нормальне" з'єднання SSH, яке лежить в основі з'єднання MySQL (так само, як ви б тунелювались -Lіз клієнтом командного рядка OpenSSH).

Тому вам потрібно буде вказати підключення до SSH-сервера на сервері, через який ви встановлюєте тунель. Тут ви, здається, використовуєте mysql.myhost.com:3306, що означає, що ви використовуєте цей SSH-сервер (а не MySQL) на порту 3306.

Можна зв’язати MySQL-сервер на 127.0.0.1:3306 та SSH-сервер на зовнішній IP-адресі для mysql.myhost.comпорту 3306, але це малоймовірно. Я думаю, ваш SSH-сервер прослуховує порт 22 (за замовчуванням).

Вам, мабуть, варто скористатися mysql.myhost.com:22. (Перевірте, чи можете ви підключитися до нього за допомогою звичайного клієнта SSH, наприклад, Putty.)


8

Можливо, вам доведеться перевірити користувачів у таблиці mysql.user.

Запустіть цей запит:

SELECT user,host FROM mysql.user;

Ви повинні побачити щось подібне:

mysql> SELECT user,host,password FROM mysql.user;
+------------------+-------------+-------------------------------------------+
| user             | host        | password                                  |
+------------------+-------------+-------------------------------------------+
| root             | localhost   | *7A670E02260CDEEFF062DD08F3A6F6DA079998CB |
| ping             | %           | *124E1DB56CC8D6E2FEE8315BB2544BF04B980DB6 |
| admin            | 10.67.135.% | 1a6858054a41fede                          |
| icorbin          | 10.67.135.% | 366ed93a7396650e                          |
+------------------+-------------+-------------------------------------------+
4 rows in set (0.00 sec)

Зауважте це

  • root @ localhost може увійти лише з localhost.
  • ping @ '%' може увійти через TCP / IP
  • admin@10.67.135.% може увійти через TCP / IP лише з цього нетблока
  • icorbin@10.67.135.% може увійти через TCP / IP лише з цього нетблока

Якщо ви хочете, щоб root з'єднався через TCP / IP, ви повинні вказати IP-адресу або netblock для кореневого користувача.

Щось на зразок цього:

GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY 'whateverpassword';

або якщо пароль root однаковий для root @ localhost, тоді

GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY PASSWORD '*7A670E02260CDEEFF062DD08F3A6F6DA079998CB ';

CAVEAT: root @ '%' не рекомендується. Можливо, спробуйте root@'10.% 'або будь-який інший netblock для root.

Спробувати !!!


3
Чи не слід ...@localhostпрацювати через тунель SSH, оскільки, що стосується сервера MySQL, з'єднання відбувається з кінця тунелю?
— Бруно

@Bruno: Один вірний спосіб знати - це успішно підключитись та запустити SELECT USER (), CURRENT_USER (); і подивіться, що це дає. Функція USER () повторює те, що ви намагалися пройти автентифікацію, тоді як CURRENT_USER () повторює те, що MySQL дозволило вам автентифікувати. Якщо CURRENT_USER () перегукується з root @ localhost, то відповідь на ваше запитання - так.
— RolandoMySQLDBA

3

Можливо, ви використовуєте старішу версію MySQL Workbench і вам потрібно оновити. Це помилка версії 6.0.8, яка наразі є версією у сховищах Ubuntu. Оновлення до версії 6.3.6 виправило це для мене.

Завантаження тут: http://dev.mysql.com/downloads/workbench/#downloads


2

Одне, що не згадується в жодній іншій відповіді, - це важливість формату OpenSSH для ключа, як зазначено в SO ( https://stackoverflow.com/questions/34504232/mysql-workbench-failing-to-connect-via- ssh-due-to-key / 38108623 # 38108623 ).

Незважаючи на відповідь, мені вдалося використати захищений паролем ключ з MySQL Workbench 6.3.7 (64 біт, Windows 10).


2

Моя проблема була пов’язана з тим, що я намагався використовувати ed25519ключ SSH. Я помітив цю помилку на сервері SSH у auth.log:

sshd[25251]: Connection closed by 192.168.x.x [preauth]

Коли я перейшов на використання ключа RSA, все працювало так, як очікувалося.


1

Ви намагаєтеся підключитися до сервера через ssh, але використовуючи порт mysql. Порт, який ви хочете, - це те, що слухає ваш ssh-сервер, як правило, 22, потім localhost та 3306 для імені хоста і mysql.


1

Я зіткнувся з тією ж проблемою. Я перевірив і спробував встановити AllowTcpForwarding Так, але він відсутній у моєму sshd_config, тому ніякої допомоги. переконайтесь, що ім'я хоста ssh НЕ збігається з ім'ям хоста mysql (використовуйте localhost).

На робочому столі виберіть +, щоб додати нове з'єднання, і встановіть наступне:

  • спосіб з'єднання: стандартний TCP / IP через SSH
  • Ім'я хоста SSH: 192.168.0.50:22 (розмістіть віддалений IP-сервер і порт віддаленого SSH (опція))
  • Ім'я користувача SSH: sshuser
  • Ви можете встановити пароль або додати в запиті
  • Ім'я хоста MYSQL: localhost або 127.0.0.1
  • Порт сервера MYSQL: 3306
  • Ви можете встановити пароль або додати в запиті

Тест з'єднання. Він повинен бути успішним, тоді натисніть OK.Viola!


1

Іноді ключі, створені PuTTY, не працюватимуть. Використовуйте ssh-keygen у вікні Linux для створення пари ключів. Скопіюйте вміст нового id_rsa в текстовий файл у Windows. Обов’язково додайте вміст id_rsa.pub до дозволених ключів у вікні Linux. Усі інші параметри за замовчуванням у Workbench добре, включаючи 127.0.0.1 для MySQL Hostname. Звичайно, це повинен бути стандартний TCP / IP через SSH.


1

Я придумав ту саму помилку. Проблема полягає в "дещо" таймауті. Я прокрутив навіть значення до 120 секунд, що не допомогло.

У моєму випадку я міг би вирішити це, роблячи nslookup myserver.com та використовуючи IP-адресу замість імені хоста. Моє припущення - це проблема, що намагається підключитися з IPv4 до IPv6.


0

Якраз ця проблема була на машині Ubuntu, підключеній до сервера, на якому працює MySQL версії 5.5.29 та MySQL Workbench 5.2.40. Сервер SSH вимагає використання ssh-ключа.

Мені не вдалося підключитися до сервера MySQL за допомогою користувача root, натомість мені довелося створити окремого некорінного користувача, який би використовувався для входу. Після цього я зміг підключитися просто чудово.

Сподіваюсь, це допомагає.


0

Гаразд, я знаю, що це давнє питання, але я витягував волосся над цим годинами. Я перевірив все, що згадували Бруно та Око, і все здавалося гарним. Тоді я зрозумів, що це дійсно приватний / публічний ключ. Тому я запустив Pageant і додав свій приватний ключ, щоб він створив відкритий ключ, який MySQL Workbench міг читати і вуаля, підключений! (Це було насправді антикліматичним, коли MySQL Workbench насправді почав працювати, але щасливо.)

TLDR: Використовуйте Pageant для створення відкритого ключа із приватного ключа.


Приватні ключі ніколи не повинні використовуватися як відкриті ключі, тому вони є приватними.
— Джеймс Андерсон

@JamesAnderson чи не в цьому полягає помилка ? Текст запитується приватним, його слід читати загальнодоступним ... принаймні за посиланням на помилку. Чи ні?
— Туфір

-1

Тільки те, що я знайшов ... часто я створюю користувачів на SSH-сервері без оболонки (наприклад, / sbin / nologin), щоб запобігти їм можливість увійти на сервер і створити там файли та інше ... (для виробничих систем ми робиш це на брандмауерах).

У звичайному середовищі Linux після цього ви все одно можете пересилати порти після цього, такі як:

ssh -Nf -L 3306:%mysql_ip%:%mysql_port% %ssh_host%

а потім підключіться до нього з локальної робочої станції як:

mysql -h localhost:3306 -u %mysql_user% -p

Але workbench видає помилку, що він не може підключитися до MySQL ... Якщо ви зміните оболонку для цього користувача, скажімо, / bin / bash - після цього все працює добре.

Не маю уявлення, чому Workbench вимагає локальної оболонки на віддаленому сервері SSH.


-1

Просто створіть новий ключ RSA з форматом, правильним для mysql workbench.

Наприклад:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.