it-swarm.dev

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 połączenie za pośrednictwem 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 przy użyciu PuTTY i mogę połączyć OK za pomocą MySQL Workbench przez ten tunel, który przekazuje połączenia do mojego lokalnego 3306 do zdalnego serwera, 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?

43
Dizzley

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_adres = 127.0.0.1. Więc tylko localhost może się połączyć.
  2. Używam serwera OpenSSH. Tak więc w pliku konfiguracyjnym/etc/ssh/sshd_config zmieniłem z nie na tak parametr odpowiedzialny za TCP, a więc - AllowTcpForwarding tak.
  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 jest 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ślnie)
    • 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.

31
Eye

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 tunelowałbyś używając -L za pomocą klienta wiersza polecenia OpenSSH).

Dlatego musisz określić połączenie z serwerem SSH na serwerze, przez który tworzysz tunel. Wygląda na to, że używasz mysql.myhost.com:3306, co sugeruje, ż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.com na porcie 3306, ale to bardzo mało prawdopodobne. Myślę, że twój serwer SSH nasłuchuje na porcie 22 (domyślnie).

Prawdopodobnie powinieneś 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.)

8
Bruno

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 [email protected]'%' IDENTIFIED BY 'whateverpassword';

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

GRANT ALL PRIVILEGES ON *.* TO [email protected]'%' IDENTIFIED BY PASSWORD '*7A670E02260CDEEFF062DD08F3A6F6DA079998CB ';

CAVEAT: root @ '%' zwykle nie jest zalecany. Może spróbuj [email protected]'10.% 'lub innego netblocka dla roota.

Spróbuj !!!

8
RolandoMySQLDBA

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

3
Gleasonator

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

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

2
Thomas

Mój problem wynikał z faktu, że próbowałem użyć ed25519 Klucz 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.

2
jbiz

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 mysql nazwa hosta i port.

1
Justin Buser

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 przy próbie połączenia z IPv4 do IPv6.

1
Markus Zeller

Czasami klucze utworzone przez PuTTY nie działają. Użyj ssh-keygen na Linux-ie, aby utworzyć parę kluczy. Skopiuj zawartość nowego 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 over SSH.

1
mcmacerson

Napotkałem ten sam problem. Sprawdziłem i próbowałem ustawić AllowTcpForwarding Yes, ale brakowało jej w moim sshd_config, więc nie ma pomocy. upewnij się, że nazwa hosta ssh to [~ # ~] nie [~ # ~] to samo co nazwa hosta mysql (użyj Lokalny Gospodarz).

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ć w Monit
  • Nazwa hosta MySQL: localhost lub 127.0.0.1
  • Port serwera MYSQL: 06
  • Możesz ustawić hasło lub dodać w Monit

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

1
Reagan Ochora

Wpadłem na ten sam błąd. Mój przypadek:

  • Ubuntu 18.04
  • mysql workbench 8.0.18
  • dostęp ssh bez hasła (tylko za pomocą publicznych/prywatnych kluczy ssh)

Rozwiązałem ten problem po:

  1. usuń mysql-workbench-community (poprzednio zainstalowany za pośrednictwem strony mysql):

    Sudo apt remove mysql-workbench-community -y

  2. zainstalować mysql-workbench

    Sudo apt install mysql-workbench -y

  3. dodaj nowe połączenie

  4. kliknij „Zapisz w pęku kluczy” dla mysql (nie dla użytkownika ssh) i ustaw hasło
  5. kliknij „Testuj połączenie”
  6. po zapytaniu o hasło pozostaw dane wejściowe puste i zaznacz „zapisz hasło”
  7. kliknij OK"
0
ktretyak

Biegać

SELECT user,Host FROM mysql.user;

I upewnij się, że użytkownik, którego próbujesz zalogować, jak w Workbench, mówi localhost w kolumnie Host, a nie %.

Jeśli mówi %, napraw to za pomocą:

UPDATE mysql.user SET Host="localhost" WHERE user="yourusername";

(Zakładając, że stworzyłeś tego użytkownika do pracy z Workbench przez SSH lub oczywiście, ponieważ powyższe powstrzyma tego użytkownika przed zalogowaniem się za pośrednictwem zdalnego TCP)

0
Nick

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.

0
Bonnie

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.

0
Kyle Coots