Próba użycia MySQL Workbench z TCP / IP przez SSH - nie udało się połączyć

Nie mogę się połączyć za pomocą połączenia TCP / IP przez połączenie SSH w MySQL Workbench z komputera. Co się dzieje?

Stworzyłem bazę danych MySQL 5.1 na serwerze Ubuntu mysql.myhost.com . Mogę uzyskać do niego dostęp lokalnie. MySQL Workbench (PC) oferuje nawiązywanie połączenia przez TCP przez ssh. Działa na porcie 3306 na zdalnym serwerze, na którym mysql z wiersza poleceń działa dobrze.

Użyłem następujących szczegółów sesji:

• Metoda połączenia: TCP / IP przez SSH.
• Nazwa hosta SSH: mysql.myhost.com : 3306
• Nazwa użytkownika SSH: mój login Linux
• Plik klucza publicznego SSH: mój lokalny plik klucza publicznego
• Nazwa hosta MySQL: 127.0.0.1 MySQL
• Port serwera: 3306
• Nazwa użytkownika: root

Podczas próby połączenia pojawia się komunikat o błędzie: „Nie udało się połączyć z MySQL w wersji 127.0.0.1:3306 przez tunel SSH w mysql.myhost.com z użytkownikiem root”

„Nie można połączyć się z serwerem MySQL na„ 127.0.0.1 ”(10061)”

Jako kolejny test - skonfigurowałem tunel SSH z portem 3306 za pomocą Putty i mogę połączyć OK za pomocą MySQL Workbench przez ten tunel, który przekazuje połączenia do mojego lokalnego 3306 ze zdalnym serwerem, jak opisano powyżej. Ale nie mogę uruchomić „TCP / IP przez SSH” w Workbench.

Drugie pytanie: kiedy Workbench pyta o „Ścieżkę do pliku klucza publicznego SSH”, czy tak naprawdę nie potrzebuje mojego pliku klucza prywatnego?

Natknąłem się na to pytanie, kiedy sam napotkałem ten błąd. W końcu mogłem wymyślić konfigurację.

1. Nie dotknąłem niczego w /etc/mysql/my.cnf, który już ma adres bind_dress = 127.0.0.1. Więc tylko localhost może się połączyć.
2. Używam serwera OpenSSH. Więc w pliku konfiguracyjnym / etc / ssh / sshd_config zmieniłem z no na yes parametr odpowiedzialny za przekazywanie TCP, dlatego AllowTcpForwarding yes .

3. Wreszcie mam następujące wpisane w MySQL WorkBench.

   • Nazwa hosta SSH: 192.168.0.8:22 (mój serwer SSH nasłuchuje na porcie 22)
   • Nazwa użytkownika SSH: sshuser
   • Plik klucza SSH: * C: \ Users \ windowsuser \ .ssh \ id_rsa * (powinien być kluczem prywatnym, nawet jeśli mówi publiczny)
   • Nazwa hosta MySQL: 127.0.0.1 (nie należy tego zmieniać, ponieważ domyślnie serwer MySQL jest powiązany z hostem lokalnym, którego nie zmieniłem)
   • Port serwera MySQL: 3306 (również domyślny)
   • Nazwa użytkownika: root

Pozostaje Ci tylko poprawnie skonfigurować serwer SSH do pracy z kluczami, a nie hasłami. Mam nadzieję, że to komuś pomoże.

Myślę, że podejście TCP / IP przez SSH działa poprzez ustanowienie „normalnego” połączenia SSH leżącego u podstaw połączenia MySQL (w taki sam sposób, jak w przypadku tunelowania za -Lpomocą klienta wiersza poleceń OpenSSH).

Dlatego musisz określić połączenie z serwerem SSH na serwerze, przez który tworzysz tunel. Tutaj wydaje się, że używasz mysql.myhost.com:3306, co sugerowałoby, że używasz tego serwera SSH (nie MySQL) na porcie 3306.

Możliwe jest powiązanie serwera MySQL na 127.0.0.1:3306 i serwera SSH na twoim zewnętrznym adresie IP dla mysql.myhost.comportu 3306, ale to bardzo mało prawdopodobne. Myślę, że twój serwer SSH nasłuchuje na porcie 22 (domyślnie).

Powinieneś prawdopodobnie użyć mysql.myhost.com:22. (Sprawdź, czy możesz się z nim połączyć za pośrednictwem zwykłego klienta SSH, takiego jak Putty).

Może być konieczne sprawdzenie użytkowników w tabeli mysql.user.

Uruchom to zapytanie:

SELECT user,host FROM mysql.user;

Powinieneś zobaczyć coś takiego:

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)

Proszę to zauważyć

• root @ localhost może zalogować się tylko z localhost.
• ping @ '%' może się zalogować przez TCP / IP
• admin@10.67.135.% może zalogować się przez TCP / IP tylko z tego bloku sieciowego
• icorbin@10.67.135.% może zalogować się przez TCP / IP tylko z tego bloku sieciowego

Jeśli chcesz, aby root łączył się przez TCP / IP, musisz podać adres IP lub blokadę sieciową dla użytkownika root.

Coś takiego:

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

lub jeśli hasło roota jest takie samo dla root @ localhost, to

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

CAVEAT: root @ '%' zwykle nie jest zalecany. Może spróbuj root@'10.% 'lub dowolnego innego bloku sieciowego dla roota.

Spróbuj !!!

Być może korzystasz ze starszej wersji MySQL Workbench i potrzebujesz aktualizacji. Jest to błąd w wersji 6.0.8, która jest obecnie wersją w repozytoriach Ubuntu. Aktualizacja do wersji 6.3.6 naprawiła to dla mnie.

Pliki do pobrania tutaj: http://dev.mysql.com/downloads/workbench/#downloads

Jedną rzeczą, która nie jest wymieniona w żadnej innej odpowiedzi, jest znaczenie formatu OpenSSH dla klucza, jak podano w SO ( https://stackoverflow.com/questions/34504232/mysql-workbench-failing-to-connect-via- ssh-due-to-key / 38108623 # 38108623 ).

Pomimo odpowiedzi na to pytanie byłem w stanie użyć klucza chronionego hasłem w MySQL Workbench 6.3.7 (64-bitowy, Windows 10).

Mój problem wynikał z faktu, że próbowałem użyć ed25519klucza SSH. Zauważyłem ten błąd na serwerze SSH w auth.log:

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

Po przejściu na używanie klucza RSA wszystko działało zgodnie z oczekiwaniami.

Próbujesz połączyć się z serwerem przez ssh, ale używając portu mysql. Port, który chcesz, jest tym, czego nasłuchuje serwer ssh, zwykle 22, następnie localhost i 3306 dla nazwy hosta i portu mysql.

Napotkałem ten sam problem. Sprawdziłem i próbowałem ustawić AllowTcpForwarding Tak, ale brakowało go w moim sshd_config, więc nie ma pomocy. upewnij się, że nazwa hosta ssh NIE jest taka sama jak nazwa hosta mysql (użyj localhost).

W środowisku roboczym wybierz +, aby dodać nowe połączenie i ustaw następujące opcje:

• metoda połączenia: standardowy TCP / IP przez SSH
• Nazwa hosta SSH: 192.168.0.50:22 (podaj adres IP i port zdalnego serwera SSH (opcjonalnie))
• Nazwa użytkownika SSH: sshuser
• Możesz ustawić hasło lub dodać po znaku zachęty
• Nazwa hosta MYSQL: localhost lub 127.0.0.1
• Port serwera MySQL: 3306
• Możesz ustawić hasło lub dodać po znaku zachęty

Testuj połączenie. Powinien się udać, a następnie nacisnąć OK. Viola!

Czasami klucze utworzone przez PuTTY nie działają. Użyj ssh-keygen na Linux-ie, aby utworzyć parę kluczy. Skopiuj zawartość nowej id_rsa do pliku tekstowego w systemie Windows. Pamiętaj, aby dodać zawartość id_rsa.pub do uprawnionych kluczy w Linux-ie. Wszystkie inne ustawienia domyślne w Workbench są w porządku, w tym 127.0.0.1 dla MySQL Hostname. Oczywiście musi to być Standard TCP / IP przez SSH.

Wpadłem na ten sam błąd. Problemem jest „nieco” przekroczenie limitu czasu. Podkręciłem nawet wartość do 120 sekund, co nie pomogło.

W moim przypadku mógłbym to rozwiązać, robiąc nslookup myserver.com i używając adresu IP zamiast nazwy hosta. Moje założenie jest problemem podczas próby połączenia z IPv4 do IPv6.

Właśnie miałem ten sam problem na komputerze Ubuntu łączącym się z serwerem z systemem MySQL w wersji 5.5.29 i MySQL Workbench 5.2.40. Serwer SSH wymaga użycia klucza ssh.

Nie byłem w stanie połączyć się z serwerem MySQL przy użyciu użytkownika root, zamiast tego musiałem utworzyć osobnego użytkownika innego niż root do logowania. Po tym mogłem się dobrze połączyć.

Mam nadzieję że to pomoże.

OK, wiem, że to stare pytanie, ale godzinami wyciągałam z tego włosy. Sprawdziłem wszystko, o czym wspomnieli Bruno i Eye, i wszystko wydawało się dobre. Potem zdałem sobie sprawę, że to naprawdę sprawa klucza prywatnego / publicznego. Uruchomiłem więc program Pageant i dodałem swój klucz prywatny, aby utworzyć klucz publiczny, który MySQL Workbench mógłby odczytać i połączyć się! (Właściwie to było trochę antyklimatyczne, kiedy MySQL Workbench faktycznie zaczął działać, ale w szczęśliwy sposób).

TLDR: Użyj programu Pageant, aby wygenerować klucz publiczny z klucza prywatnego.

Tylko to, co znalazłem ... często tworzę użytkowników na serwerze SSH bez powłoki (np. / Sbin / nologin), aby uniemożliwić im logowanie się na serwerze i tworzenie plików itp. Tam ... (w systemach produkcyjnych mamy robią to na zaporach ogniowych).

Następnie w zwykłym środowisku Linux nadal możesz przekierowywać porty, takie jak:

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

a następnie połącz się z nim z lokalnej stacji roboczej jako:

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

Ale stół roboczy z błędem, że nie może połączyć się z MySQL ... Jeśli zmienisz powłokę dla tego użytkownika na, powiedzmy, / bin / bash - po tym wszystko działa poprawnie.

Nie mam pojęcia, dlaczego Workbench wymaga lokalnej powłoki na zdalnym serwerze SSH.

Po prostu utwórz nowy klucz RSA o poprawnym formacie do mysql workbench.

Na przykład:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"