Impossibile connettersi al database MySQL su SSH con Workbench

Sto cercando di connettermi al mio database tramite tunneling SSH da uno dei nostri server di app Web con MySQL Workbench. Ecco la configurazione di base; si noti che ho modificato alcuni valori nello screenshot per motivi di sicurezza.

Il problema è ogni volta che provo a connettermi su un tunnel SSH da uno dei nostri server di app, ottengo il seguente errore:

Impossibile connettersi a us-east-1.amazonaws.com tramite il tunnel SSH su computer.amazonaws.com con l'utente social_shop_prod. Impossibile connettersi al server MySQL su 127.0.0.1.

Tuttavia, se utilizzo le stesse credenziali su SSH tramite la seguente riga di comando:

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

Posso collegarmi con successo e ottenere il prompt dei comandi interattivo di MySQL.

Ho parlato con il resto del mio team di sviluppo qui e nessuno di noi può capire perché non riesco a scavalcare SSH dai nostri server di app con Workbench; ma quando eseguo SSH su uno dei nostri server di app e mi connetto a MySQL tramite la riga di comando; Posso collegarmi con successo.

E perché sta provando a connettersi oltre 127.0.0.1? Non l'ho specificato nella configurazione; né il mio file host reindirizza i domini mostrati sotto a quell'IP.

Ogni input costruttivo è molto apprezzato.

Dato che ti stai collegando attraverso un tunnel SSH, questo significa che la porta MySQL 3306 di us-east-1.amazonaws.com è stata aperta localmente sul tuo computer. L'indirizzo IP del tuo computer è 127.0.0.1 o localhost. Quando ti connetti al server mysql su us-east-1.amazonaws.com, accederai effettivamente tramite 127.0.0.1, cioè il tuo computer. Se hai aperto un altro tunnel o MySQL in esecuzione localmente sul tuo computer, potrebbe essere quell'altro server MySQL che rifiuta i tuoi tentativi di autenticazione

Ci sono alcuni test che puoi provare:

1. Su quali porte stai ascoltando il tuo computer Windows

Da un prompt dei comandi: netstat -a (elenca tutte le porte aperte)

In Linux sarebbe: netstat -tlpn

2. Test di connettività di base

Da un prompt dei comandi DOS o da una console linux: telnet 127.0.0.1 3306

Se hai una pausa, o se qualche altro programma risponde, il tuo tunnel non è configurato correttamente.

3. Modifica il numero di porta che MySQL Workbench sta aprendo localmente

Supponiamo che MySQL Workbench stia creando il tunnel sul tuo computer. In tal caso, nel workbench di MySQL, prova a eseguire il tunneling attraverso un altro numero di porta come 9000.

Assicurarsi che 9000 non sia elencato come porta aperta da: netstat -a

Se hai accesso ssh a us-east-1.amazonaws.com

4. Prova a connetterti a MySQL da us-east-1.amazonaws.com

mysql -u myuser -h 127.0.0.1 -p

E come ha detto Rolando, ti consigliamo di verificare che ti stai connettendo con le giuste credenziali. Ad esempio, se ci si connette come myuser@127.0.0.1 e si dispone di un utente myuser senza host, probabilmente non sarà possibile connettersi utilizzando user@127.0.0.1.

Il motivo per cui 127.0.0.1 viene contattato è perché il tunnel collega una porta sul computer locale all'host remoto. Il messaggio sembra suggerire che non è stata stabilita una connessione SSH.

Prova questo dalla riga di comando:

ssh -L 33000:remotehost:3306 user@remotehost

Assicurarsi che SSH consenta le porte inoltrate; se viene visualizzato un messaggio che informa che l'inoltro non è stato consentito o è stato rifiutato, ecco perché.

Per risolvere questo problema, dovresti cambiare la configurazione del server; aggiungi questa configurazione al server SSH:

AllowTcpForwarding yes

Non dimenticare di riavviare il server per attivare questa configurazione.

Ho continuato a gestire questo problema per quasi 2 settimane, ora sono riuscito a risolverlo. Pubblicherò qui in modo che più persone possano provarlo.

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

Step-by-step:
1. Aggiungi le tue chiavi host SSH all'agente usando ssh-add.
2. Generare le coppie di chiavi usando ssh-keygen. Nel mio caso, questi file vanno automaticamente Users/myUser/.sshsecondo le configurazioni di installazione.
3. Aggiungi la chiave pubblica al file authorized_keys (che nel mio caso deve trovarsi nel percorso di installazione del tuo server Windows/System32/OpenSSH/.ssh) senza estensioni.
4. Aggiungi le chiavi generate che hai appena fatto all'agente usando ssh-add.

I passaggi sopra sono praticamente la configurazione di un server SSH a riga di comando che ho capito che l'OP già fatto per la sua connessione sta funzionando attraverso il terminale. Per configurare MySQL Workbench 8 fai praticamente la stessa cosa, tranne che devi convertire private_key.pem in un formato OpenSSH prima di spostarli in Users/myUser/.ssheOpenSSH_instalation_path/.ssh

1. Converti private_key.pem in formato OpenSSH usando PUTTYgen.
   
2. Copia il campo "Chiave pubblica per incollare in OpenSSH authorized_keys" .
   
3. Salvare la chiave pubblica nelle cartelle User/myUser/.ssheOpenSSH_instalation_path/.ssh
   
4. Incolla la chiave che hai copiato da PUTTY al file authorized_keys nella OpenSSH_instalation_path/.sshcartella.
5. Esporta la chiave del formato OpenSSH in User/myUser/.ssh.
6. Riavvia i servizi sshd e mysql
7. Configurare Workbench per la connessione al server SSH utilizzando la chiave privata convertita.

AGGIORNAMENTO: Sarà necessario impostare quanto segue nel file sshd_config:

PermitRootLogin senza password
PubkeyAuthentication sì
PasswordAuthentication no
PermitEmptyPasswords no
AllowTcpForwarding sì

SI PREGA DI LEGGERE:

Sono un analista inesperto, quindi se un utente più esperto sa quale delle due cartelle .ssh è quella giusta, ti preghiamo di comunicarcelo. Trovo che OpenSSH sia un po 'ambiguo al riguardo.
Questo ha funzionato per me durante l'impostazione di un ambiente di sviluppo locale utilizzando solo localhost. Solo a scopo di apprendimento.
È possibile aggiungere myUser @ localhost agli utenti di MySQL Workbench prima di testare la connessione.
Se è davvero necessario, posso aggiungere immagini.

Nel mio caso il problema ho dovuto tornare a un nome di dominio o IP valido anziché a un host personalizzato localmente risolto.

Risoluzione dell'host personalizzata non riuscita ( /etc/hosts)

Lavoro con un meccanismo di risoluzione degli host locali che ha definito:

#.#.#.#    my-vm

Per qualche motivo con MySQL 5.2.47il Linux Mint 14 (Nadia)quale è simile al Ubuntu 12.10 (Quantal)il meccanismo di risoluzione non lavoro .

Soluzione

Basta passare a un nome di dominio pubblico come my-website.comrisolvere il problema.

Vedi qui per un elenco di risorse per la connessione a vari target (Amazon RDS, Amazon EC2, Windows Azure e altri): http://forums.mysql.com/read.php?152,252640,252640#msg-252640 .

Ho avuto un problema simile, e questo potrebbe essere un problema, ma controlla le regole del firewall in AWS. Ho impostato un intervallo IP per limitare le connessioni dal mondo esterno. E l'IP nel mio ufficio è cambiato, quindi è uscito dall'intervallo IP. Il mio collega in un altro ufficio potrebbe ancora connettersi, quindi ho pensato che il problema fosse sul mio PC, ma il problema era con le regole del firewall in AWS. Spero che aiuti qualcuno :)