Не удается подключиться к базе данных MySQL через SSH с Workbench

Я пытаюсь подключиться к своей базе данных через SSH-туннелирование с одного из наших серверов веб-приложений с MySQL Workbench. Вот основной конфиг; обратите внимание, что я изменил некоторые значения на скриншоте из соображений безопасности.

Проблема заключается в том, что каждый раз, когда я пытаюсь подключиться через туннель SSH с одного из наших серверов приложений, я получаю следующую ошибку:

Не удалось подключиться к us-east-1.amazonaws.com через туннель SSH на computer.amazonaws.com с пользователем social_shop_prod. Не удается подключиться к серверу MySQL на 127.0.0.1.

Однако, если я использую те же учетные данные через SSH через следующую командную строку:

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

Я могу успешно подключиться и получить интерактивную командную строку MySQL.

Я говорил с остальной частью моей команды разработчиков здесь, и никто из нас не может понять, почему я не могу туннелировать через SSH с наших серверов приложений с Workbench; но когда я SSH к одному из наших серверов приложений и подключаюсь к MySQL через командную строку; Я могу успешно подключиться.

И почему он пытается подключиться через 127.0.0.1? Я не указал это в конфигурации; мой файл hosts не перенаправляет домены, показанные ниже, на этот IP.

Любой конструктивный вклад приветствуется.

Поскольку вы подключаетесь через SSH-туннель, это означает, что порт MySQL 3306 от us-east-1.amazonaws.com открывается локально на вашем компьютере. IP-адрес вашего компьютера 127.0.0.1 или localhost. Когда вы подключаетесь к серверу mysql на us-east-1.amazonaws.com, вы фактически получаете к нему доступ через 127.0.0.1, то есть через свой компьютер. Если у вас был открыт другой туннель или MySQL запущен локально на вашем компьютере, то это может быть тот другой сервер MySQL, который отклоняет ваши попытки аутентификации

Есть несколько тестов, которые вы можете попробовать:

1. На каких портах вы слушаете компьютер с Windows

Из командной строки: netstat -a (перечисляет все открытые порты)

В Linux это будет: netstat -tlpn

2. Базовый тест подключения

Из командной строки DOS или консоли Linux: telnet 127.0.0.1 3306

Если у вас истекло время ожидания, или какая-то другая программа отвечает, значит ваш туннель настроен неправильно.

3. Измените номер порта, который MySQL Workbench открывает локально

Мы предполагаем, что MySQL Workbench создает туннель на вашем компьютере. Если это так, в MySQL Workbench, попробуйте туннелирование через другой номер порта, например 9000.

Убедитесь, что 9000 не указан в качестве открытого порта от: netstat -a

Если у вас есть доступ по ssh к us-east-1.amazonaws.com

4. Попробуйте подключиться к MySQL с us-east-1.amazonaws.com

mysql -u myuser -h 127.0.0.1 -p

И, как сказал Роландо, вам нужно убедиться, что вы подключаетесь с правильными учетными данными. Например, если вы подключаетесь как myuser@127.0.0.1 и у вас есть пользователь myuser без хоста, вы, вероятно, не сможете подключиться, используя user@127.0.0.1.

Причина, по которой происходит соединение с 127.0.0.1, заключается в том, что туннель соединяет порт на вашей локальной машине с удаленным хостом. Похоже, что сообщение указывает на то, что соединение SSH не устанавливается.

Попробуйте это из командной строки:

ssh -L 33000:remotehost:3306 user@remotehost

Убедитесь, что SSH разрешает переадресацию портов; если вы получаете сообщение о том, что пересылка не была разрешена или была отклонена, то именно поэтому.

Чтобы это исправить, вам нужно изменить конфигурацию сервера; добавьте эту конфигурацию на сервер SSH:

AllowTcpForwarding yes

Не забудьте перезапустить сервер, чтобы активировать эту конфигурацию.

Я продолжал заниматься этой проблемой почти 2 недели, теперь мне удалось ее решить. Я опубликую это здесь, чтобы больше людей могли попробовать это.

Хорошо, я использую OpenSSH (родной Win10) и Workbench 8.

Шаг за шагом:
1. Добавьте свои ключи хоста SSH к агенту с помощью ssh-add.
2. Сгенерируйте пары ключей, используя ssh-keygen. В моем случае эти файлы автоматически переходят Users/myUser/.sshв соответствии с настройками установки.
3. Добавьте открытый ключ в authorized_keys файл (который должен быть в пути установки сервера, в моем случае Windows/System32/OpenSSH/.ssh) без расширений.
4. Добавьте сгенерированные ключи, которые вы только что создали, к агенту с помощью ssh-add.

Шаги, приведенные выше, в значительной степени конфигурируют SSH-сервер командной строки, который, как я выяснил, OP уже сделал для своего соединения, работает через терминал. Чтобы настроить MySQL Workbench 8, вы в значительной степени делаете то же самое, за исключением того, что вы должны преобразовать private_key.pem в формат OpenSSH, прежде чем перемещать их в Users/myUser/.sshиOpenSSH_instalation_path/.ssh

1. Преобразование private_key.pem в формат OpenSSH с использованием PuTTYgen.
   
2. Скопируйте поле «Открытый ключ для вставки в OpenSSH авторизованные ключи» .
   
3. Сохраните открытый ключ в папках User/myUser/.sshиOpenSSH_instalation_path/.ssh
   
4. Вставить ключ, скопированный из замазки в authorized_keys файл в OpenSSH_instalation_path/.sshпапке.
5. Экспортируйте ключ формата OpenSSH в User/myUser/.ssh.
6. Перезапустите службы sshd и mysql
7. Сконфигурируйте Workbench для подключения к серверу SSH с помощью преобразованного закрытого ключа.

ОБНОВЛЕНИЕ: Вам необходимо установить следующее в вашем файле sshd_config:

PermitRootLogin без пароля
PubkeyAuthentication да
PasswordAuthentication нет
PermitEmptyPasswords нет
AllowTcpForwarding да

ПОЖАЛУЙСТА, ПРОЧИТАЙТЕ:

Я неопытный аналитик, поэтому, если более опытный пользователь знает, какая из двух папок .ssh является правильной, сообщите нам. Я нахожу OpenSSH немного двусмысленным по этому поводу.
Это сработало для меня при настройке локальной среды разработки с использованием только localhost. Просто для учебных целей.
Возможно, вы захотите добавить myUser @ localhost пользователям MySQL Workbench перед тестированием соединения.
Если действительно нужно, я могу добавить изображения.

В моем случае проблема была вынуждена вернуться к действительному имени домена или IP-адресу вместо локального хоста, решенного локально.

Нестандартное разрешение хоста не удалось ( /etc/hosts)

Я работаю с механизмом разрешения локальных хостов, который определил:

#.#.#.#    my-vm

По какой - то причине с MySQL 5.2.47на Linux Mint 14 (Nadia)который похож Ubuntu 12.10 (Quantal)на механизм разрешения не работает .

Решение

Просто переключитесь на публичное доменное имя, например, my-website.comрешите проблему.

См. Здесь список ресурсов для подключения к различным целям (Amazon RDS, Amazon EC2, Windows Azure и др.): Http://forums.mysql.com/read.php?152,252640,252640#msg-252640 .

У меня была похожая проблема, и это может быть обидно, но проверьте правила брандмауэра в AWS. У меня установлен диапазон IP-адресов, чтобы ограничить соединения с внешним миром. И IP в моем офисе изменился, так что он вышел за пределы диапазона IP. Мой коллега в другом офисе все еще мог подключиться, поэтому я подумал, что проблема на моем ПК, но проблема была с правилами брандмауэра в AWS. Надеюсь, что это помогает кому-то :)