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

41

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?

Dizzley
źródło
4
O jeny. bugs.mysql.com/bug.php?id=61368 pokazuje, że JEST PRYWATNYM plikiem klucza, który jest potrzebny w formacie OpenSSH. Zastanawiałem się nad tym, ale nie byłem pewien.
Dizzley,

Odpowiedzi:

29

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.

Oko
źródło
Jedną rzeczą, którą musiałem zrobić po stronie serwera, było upewnienie się, że plik / etc / ssh / sshd_config ma tę linię: AuthorizedKeysFile /home/root/.ssh/authorized_keysi że klucze autoryzowane miały mój klucz PUBLICZNY jako wpis.
RyanNerd
Wyjaśnij, czy krok 2, który zestaw AllowTcpForwarding yesjest zastosowany do zdalnego serwera, tj. Hosta z instancją MySQL, z którą próbujemy się połączyć; lub lokalna maszyna z zainstalowanym MySQL Workbench
Nam G VU
@NamGVU krok 2 dotyczy zdalnego serwera, na którym jest zainstalowany MySQL. Szczególnie w przypadku serwera OpenSSH, który zapewnia tunelowanie do MySQL przez SSH.
Oko
Próbowałem, ale nadal nie udało mi się tunelować. MySQL Workbench każe mi przeczytać więcej szczegółów błędów w pliku dziennika. Czy wiesz, gdzie czytać?
Nam G VU
1
Dostałem to dzisiaj - potrzebuję restartu po skonfigurowaniu AllowTcpForwardingwpisu
Nam G VU
8

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).

Bruno
źródło
8

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
  • [email protected].% może zalogować się przez TCP / IP tylko z tego bloku sieciowego
  • [email protected].% 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 !!!

RolandoMySQLDBA
źródło
3
Nie powinno ...@localhostdziałać przez tunel SSH, ponieważ jeśli chodzi o serwer MySQL, połączenie pochodzi z końca tunelu?
Bruno
@Bruno: Jednym pewnym sposobem na sprawdzenie jest pomyślne połączenie, a następnie uruchomienie SELECT USER (), CURRENT_USER (); i zobacz, co wyprowadza. Funkcja USER () powtarza to, co próbowałeś uwierzytelnić, podczas gdy CURRENT_USER () powtarza to, co MySQL pozwoliło ci się uwierzytelnić. Jeśli CURRENT_USER () echa root @ localhost, odpowiedź na twoje pytanie brzmi: tak.
RolandoMySQLDBA
3

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

Gleasonator
źródło
2

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.

jbiz
źródło
1

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.

Justin Buser
źródło
1

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!

Reegan Ochora
źródło
1

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.

mcmacerson
źródło
1

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.

Markus Zeller
źródło
0

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.

Kyle Coots
źródło
0

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.

Bonnie
źródło
Klucze prywatne nigdy nie powinny być używane jako klucze publiczne, dlatego są prywatne.
James Anderson
@JamesAnderson nie o to chodzi w błędzie ? Tekst prosi o prywatność, powinien czytać publicznie ... przynajmniej zgodnie z linkiem do błędu. Albo nie?
Thufir
-1

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.

użytkownik251897
źródło
-1

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

Na przykład:

ssh-keygen -t rsa -b 4096 -C "[email protected]"
będzie
źródło