Nie można połączyć się z bazą danych MySQL przez SSH z Workbench

Próbuję połączyć się z moją bazą danych poprzez tunelowanie SSH z jednego z naszych serwerów aplikacji WWW za pomocą MySQL Workbench. Oto podstawowa konfiguracja; zwróć uwagę, że ze względów bezpieczeństwa zmieniłem niektóre wartości na zrzucie ekranu.

Problem polega na tym, że za każdym razem, gdy próbuję połączyć się przez tunel SSH z jednego z naszych serwerów aplikacji, pojawia się następujący błąd:

Nie udało się połączyć z us-east-1.amazonaws.com przez tunel SSH na computer.amazonaws.com z użytkownikiem social_shop_prod. Nie można połączyć się z serwerem MySQL w wersji 127.0.0.1.

Jeśli jednak użyję tych samych danych logowania przez SSH za pomocą następującego wiersza polecenia:

mysql -u social_shop_prod -h us-east-1.amazonaws.com -p

Mogę pomyślnie nawiązać połączenie i uzyskać interaktywny wiersz polecenia MySQL.

Rozmawiałem tutaj z resztą mojego zespołu programistów i nikt z nas nie może zrozumieć, dlaczego nie mogę tunelować SSH z naszych serwerów aplikacji za pomocą Workbench; ale kiedy łączę SSH z jednym z naszych serwerów aplikacji i łączę się z MySQL za pomocą wiersza poleceń; Mogę się połączyć pomyślnie.

I dlaczego próbuje połączyć się przez 127.0.0.1? Nie określiłem tego w konfiguracji; plik mojego hosta nie przekierowuje domen pokazanych poniżej do tego adresu IP.

Wszelkie konstruktywne uwagi są mile widziane.

Ponieważ łączysz się przez tunel SSH, oznacza to, że port MySQL 3306 z us-east-1.amazonaws.com jest otwierany lokalnie na twoim komputerze. Adres IP twojego komputera to 127.0.0.1 lub localhost. Kiedy łączysz się z serwerem mysql na us-east-1.amazonaws.com, faktycznie uzyskujesz do niego dostęp za pośrednictwem 127.0.0.1, tj. Z komputera. Jeśli miałeś inny otwarty tunel lub MySQL działał lokalnie na twoim komputerze, być może inny serwer MySQL odrzuca twoje próby uwierzytelnienia

Istnieje kilka testów, które możesz wypróbować:

1. Na jakich portach słuchasz komputera z systemem Windows

Z wiersza polecenia: netstat -a (wyświetla listę wszystkich otwartych portów)

W Linuksie byłoby to: netstat -tlpn

2. Podstawowy test łączności

Z wiersza polecenia DOS lub konsoli Linux: telnet 127.0.0.1 3306

Jeśli dostaniesz czas lub jakiś inny program zareaguje, Twój tunel nie zostanie poprawnie skonfigurowany.

3. Zmień numer portu, który MySQL Workbench otwiera lokalnie

Zakładamy, że środowisko robocze MySQL tworzy tunel na twoim komputerze. Jeśli tak, w warsztacie MySQL spróbuj tunelować przez inny numer portu, np. 9000.

Upewnij się, że 9000 nie było wymienione jako otwarty port z: netstat -a

Jeśli masz dostęp ssh do us-east-1.amazonaws.com

4. Spróbuj połączyć się z MySQL z us-east-1.amazonaws.com

mysql -u mój użytkownik -h 127.0.0.1 -p

I jak powiedział Rolando, będziesz chciał sprawdzić, czy łączysz się z odpowiednimi poświadczeniami. Na przykład, jeśli łączysz się jako myuser@127.0.0.1 i masz myuser użytkownika bez hosta, prawdopodobnie nie będziesz mógł połączyć się za pomocą user@127.0.0.1.

Powodem kontaktu z 127.0.0.1 jest to, że tunel łączy port komputera lokalnego ze zdalnym hostem. Komunikat wydaje się sugerować, że nie nawiązano połączenia SSH.

Spróbuj tego z wiersza poleceń:

ssh -L 33000:remotehost:3306 user@remotehost

Upewnij się, że SSH zezwala na przekierowane porty; jeśli otrzymasz wiadomość z informacją, że przekazanie było niedozwolone lub zostało odrzucone, to właśnie dlatego.

Aby to naprawić, musisz zmienić konfigurację serwera; dodaj tę konfigurację do serwera SSH:

AllowTcpForwarding yes

Nie zapomnij zrestartować serwera, aby aktywować tę konfigurację.

Nadal zajmowałem się tym problemem przez prawie 2 tygodnie, teraz udało mi się go ustawić. Zamieszczę go tutaj, aby więcej osób mogło go wypróbować.

Ok, używam OpenSSH (natywny Win10) i Workbench 8.

Krok po kroku:
1. Dodaj klucze hosta SSH do agenta za pomocą ssh-add.
2. Wygeneruj pary kluczy za pomocą ssh-keygen. W moim przypadku pliki te są automatycznie Users/myUser/.sshprzenoszone zgodnie z konfiguracjami instalacji.
3. Dodaj klucz publiczny do pliku autoryzowanego_klucza (który w moim przypadku musi znajdować się w ścieżce instalacyjnej serwera Windows/System32/OpenSSH/.ssh) bez rozszerzeń.
4. Dodaj wygenerowane klucze, które właśnie utworzyłeś do agenta za pomocą ssh-add.

Powyższe kroki to w zasadzie konfiguracja wiersza poleceń SSH Server, który, jak sądzę, OP już zrobił dla jego połączenia działa przez terminal. Aby skonfigurować MySQL Workbench 8, wykonaj dokładnie to samo, tyle że musisz przekonwertować plik private_key.pem do formatu OpenSSH przed przeniesieniem ich do Users/myUser/.sshiOpenSSH_instalation_path/.ssh

1. Konwertuj private_key.pem do formatu OpenSSH za pomocą PUTTYgen.
   
2. Skopiuj pole „Klucz publiczny do wklejenia do kluczy autoryzowanych OpenSSH” .
   
3. Zapisz klucz publiczny w folderach User/myUser/.sshiOpenSSH_instalation_path/.ssh
   
4. Wklej klucz skopiowany z PUTTY do pliku autoryzowanych_kluczy w OpenSSH_instalation_path/.sshfolderze.
5. Wyeksportuj klucz formatu OpenSSH do User/myUser/.ssh.
6. Uruchom ponownie usługi sshd i mysql
7. Skonfiguruj Workbench, aby łączył się z serwerem SSH przy użyciu przekonwertowanego klucza prywatnego.

AKTUALIZACJA: Musisz ustawić następujące ustawienia w swoim pliku sshd_config:

PermitRootLogin bez-password
PubkeyAuthentication tak
PasswordAuthentication nie
PermitEmptyPasswords nie
AllowTcpForwarding tak

PROSZĘ PRZECZYTAJ:

Jestem niedoświadczonym analitykiem, więc jeśli bardziej zaawansowany użytkownik wie, który z dwóch folderów .ssh jest właściwy, powiedz nam. Uważam, że OpenSSH jest niejasny w tej kwestii.
Działa to dla mnie podczas ustawiania lokalnego środowiska programistycznego przy użyciu tylko localhost. Tylko do celów edukacyjnych.
Możesz dodać myUser @ localhost do użytkowników MySQL Workbench przed przetestowaniem połączenia.
Jeśli jest to naprawdę potrzebne, mogę dodawać obrazy.

W moim przypadku problem musiałem zmienić z powrotem na prawidłową nazwę domeny lub adres IP zamiast niestandardowego hosta host lokalny rozwiązany.

Niepowodzenie rozdzielczości hosta niestandardowego ( /etc/hosts)

Pracuję z mechanizmem rozpoznawania lokalnych hostów, który zdefiniował:

#.#.#.#    my-vm

Z jakiegoś powodu MySQL 5.2.47na Linux Mint 14 (Nadia)którym jest podobna do Ubuntu 12.10 (Quantal)tej mechanizmu rozstrzygania nie działa .

Rozwiązanie

Wystarczy zmienić nazwę domeny publicznej, na przykład my-website.comrozwiązać problem.

Zobacz tutaj listę zasobów do łączenia się z różnymi celami (Amazon RDS, Amazon EC2, Windows Azure i inne): http://forums.mysql.com/read.php?152,252640,252640#msg-252640 .

Miałem podobny problem, który może być niewidoczny, ale sprawdź reguły zapory w AWS. Mam ustawiony zakres adresów IP, aby ograniczyć połączenia ze świata zewnętrznego. I zmieniło się IP w moim biurze, więc znalazło się poza zakresem IP. Mój kolega z innego biura nadal może się połączyć, więc pomyślałem, że problem dotyczy mojego komputera, ale problem dotyczył reguł zapory w AWS. Mam nadzieję, że ktoś komuś pomoże :)