Não é possível conectar ao banco de dados MySQL por SSH com o Workbench

Estou tentando conectar-me ao meu banco de dados via tunelamento SSH de um de nossos servidores de aplicativos da web com o MySQL Workbench. Aqui está a configuração básica; observe que alterei alguns valores na captura de tela por motivos de segurança.

O problema é que sempre que tento conectar-me através de um túnel SSH de um de nossos servidores de aplicativos, recebo o seguinte erro:

Falha ao conectar-se a us-east-1.amazonaws.com através do túnel SSH em computer.amazonaws.com com o usuário social_shop_prod. Não é possível conectar ao servidor MySQL no 127.0.0.1.

No entanto, se eu usar as mesmas credenciais no SSH por meio da seguinte linha de comando:

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

Posso me conectar com sucesso e obter o prompt de comando interativo do MySQL.

Estive conversando com o restante da minha equipe de desenvolvimento aqui e nenhum de nós pode descobrir por que não posso fazer o túnel sobre o SSH de nossos servidores de aplicativos com o Workbench; mas quando eu SSH para um de nossos servidores de aplicativos e me conecto ao MySQL via linha de comando; Eu posso conectar com sucesso.

E por que ele está tentando se conectar através do 127.0.0.1? Eu não especifiquei isso na configuração; meu arquivo hosts também não está redirecionando os domínios mostrados abaixo para esse IP.

Qualquer contribuição construtiva é muito apreciada.

Como você está se conectando através de um túnel SSH, isso significa que a porta 3306 do MySQL de us-east-1.amazonaws.com está sendo aberta localmente no seu computador. O endereço IP do seu computador é 127.0.0.1 ou localhost. Quando você se conecta ao servidor mysql em us-east-1.amazonaws.com, na verdade você está acessando através do 127.0.0.1, ou seja, seu computador. Se você teve outro túnel aberto, ou o MySQL rodando localmente no seu computador, pode ser que outro servidor MySQL esteja rejeitando suas tentativas de autenticação

Existem alguns testes que você pode tentar:

1. Em quais portas o seu computador Windows está ouvindo

Em um prompt de comandos: netstat -a (lista todas as portas que estão abertas)

No linux seria: netstat -tlpn

2. Teste básico de conectividade

Em um prompt de comandos do DOS ou console linux: telnet 127.0.0.1 3306

Se você tiver um tempo limite ou algum outro programa responder, seu túnel não estará configurado corretamente.

3. Altere o número da porta que o MySQL Workbench está abrindo localmente

Estamos assumindo que o ambiente de trabalho MySQL está criando o túnel no seu computador. Nesse caso, no ambiente de trabalho MySQL, tente fazer o tunelamento através de outro número de porta como 9000.

Verifique se o 9000 não foi listado como uma porta aberta em: netstat -a

Se você tiver acesso ssh a us-east-1.amazonaws.com

4. Tente conectar-se ao MySQL em us-east-1.amazonaws.com

mysql -u myuser -h 127.0.0.1 -p

E, como Rolando disse, você deve verificar se está se conectando com as credenciais corretas. Por exemplo, se você estiver se conectando como myuser@127.0.0.1 e tiver um usuário myuser sem host, provavelmente não poderá se conectar usando user@127.0.0.1.

O motivo pelo qual 127.0.0.1 está sendo contatado é porque o túnel conecta uma porta em sua máquina local ao host remoto. A mensagem parece sugerir que uma conexão SSH não está sendo feita.

Tente isso na linha de comando:

ssh -L 33000:remotehost:3306 user@remotehost

Verifique se o SSH está permitindo portas encaminhadas; se você receber uma mensagem informando que o encaminhamento não foi permitido ou foi recusado, é por isso.

Para corrigir isso, você precisaria alterar a configuração do servidor; adicione esta configuração ao servidor SSH:

AllowTcpForwarding yes

Não se esqueça de reiniciar o servidor para ativar esta configuração.

Continuei lidando com esse problema por quase duas semanas, agora que consegui defini-lo. Vou postá-lo aqui para que mais pessoas possam experimentá-lo.

Ok, estou usando o OpenSSH (Win10 nativo) e o Workbench 8.

Passo a passo:
1. Adicione suas chaves de host SSH ao agente usando ssh-add.
2. Gere os pares de chaves usando ssh-keygen. No meu caso, esses arquivos passam automaticamente para Users/myUser/.sshas configurações de instalação.
3. Adicione a chave pública ao arquivo allowed_keys (que deve estar dentro do caminho de instalação do servidor, no meu caso Windows/System32/OpenSSH/.ssh) sem extensões.
4. Adicione as chaves geradas que você acabou de criar ao agente usando o ssh-add.

As etapas acima são basicamente a configuração de um servidor SSH da linha de comando, que eu descobri que o OP já fez para a conexão dele está funcionando através do terminal. Para configurar o MySQL Workbench 8, você faz exatamente a mesma coisa, exceto que deve converter o private_key.pem em um formato OpenSSH antes de movê-los para Users/myUser/.ssheOpenSSH_instalation_path/.ssh

1. Converta private_key.pem para o formato OpenSSH usando PUTTYgen.
   
2. Copie o campo "Chave pública para colar no OpenSSH allowed_keys" .
   
3. Salve a chave pública nas pastas User/myUser/.ssheOpenSSH_instalation_path/.ssh
   
4. Cole a chave copiou de massa para os authorized_keys arquivo na OpenSSH_instalation_path/.sshpasta.
5. Exporte a chave de formato OpenSSH para o User/myUser/.ssh.
6. Reinicie os serviços sshd e mysql
7. Configure o Workbench para conectar-se ao servidor SSH usando a chave privada convertida.

ATUALIZAÇÃO: você precisará definir o seguinte no seu arquivo sshd_config:

PermitRootLogin sem senha
PubkeyAuthentication yes
PasswordAuthentication não
PermitEmptyPasswords não
AllowTcpForwarding yes

POR FAVOR LEIA:

Sou um analista inexperiente, portanto, se um usuário mais avançado souber qual das duas pastas .ssh é a correta, informe-nos. Acho o OpenSSH meio ambíguo sobre isso.
Isso funcionou para mim ao definir um ambiente de desenvolvimento local usando apenas o host local. Apenas para fins de aprendizado.
Você pode adicionar myUser @ localhost aos usuários do MySQL Workbench antes de testar a conexão.
Se for realmente necessário, posso adicionar imagens.

No meu caso, o problema foi necessário voltar para um nome de domínio ou IP válido, em vez de um host personalizado localmente resolvido.

Falha na resolução do host personalizado ( /etc/hosts)

Eu trabalho com um mecanismo de resolução de hosts locais que definiu:

#.#.#.#    my-vm

Por alguma razão com MySQL 5.2.47a Linux Mint 14 (Nadia)qual é semelhante à Ubuntu 12.10 (Quantal)do mecanismo de resolução não trabalho .

Solução

Basta mudar para um nome de domínio público , como my-website.comresolver o problema.

Consulte aqui uma lista de recursos para conectar-se a vários destinos (Amazon RDS, Amazon EC2, Windows Azure e outros): http://forums.mysql.com/read.php?152,252640,252640#msg-252640 .

Eu tive um problema semelhante, e isso pode ser óbvio, mas verifique as regras de firewall na AWS. Eu tenho um intervalo de IP definido, para restringir as conexões do mundo exterior. E o IP no meu escritório mudou, ficando fora do intervalo de IP. Meu colega de outro escritório ainda pode se conectar, então pensei que o problema estava no meu PC, mas o problema estava nas regras de firewall da AWS. Espero que ajude alguém :)