[MySQL] Mysql Workbench verbindt alleen zonder wachtwoord

[CB32]

Mijn vraag
Ik heb een VPS server waarop MySQL draait. Vanaf mijn lokale PC wil ik via MySQL Workbench de database beheren. Daarvoor heb ik een mysql-user "remote" aangemaakt. Ik kan echter alleen succesvol verbinden met MySQL als ik deze user geen password mee geef.

Foutmelding:

code:

Your connection attempt failed for user 'remote' from your host to server at 127.0.0.1:3306:
  Can't connect to MySQL server on '127.0.0.1' (111)

Please:
1 Check that mysql is running on server 127.0.0.1
2 Check that mysql is running on port 3306 (note: 3306 is the default, but this can be changed)
3 Check the remote has rights to connect to 127.0.0.1 from your address (mysql rights define what clients can connect to the server and from which machines) 
4 Make sure you are both providing a password if needed and using the correct password for 127.0.0.1 connecting from the host address you're connecting from

De MySQL server is niet opgensteld voor buiten en verbinding loopt via een SSH tunnel.

Relevante software en hardware die ik gebruik
VPS

• Ubuntu Server 16.04
• MySQL Server 5.7.20-0ubuntu0.16.04.1

Lokale PC

• Ubuntu 17.04
• MySQL Workbench 6.3.8

MySQL User

• Username: remote
• Host name: (any host) %

Connectie in MySQL Workbench

• Connection method: Standard TCP/IP over SSH
• SSH gegevens VPS (worden geaccepteerd)
• MySQL Hostname: 127.0.0.1
• MySQL Server Port: 3306
• MySQL Username: remote

Wat ik al gevonden of geprobeerd heb
Ik heb al diverse vragen gevonden op stackoverflow maar het lijkt niet hetzelfde probleem aangezien ik wel een goede verbinding kan maken, mits er geen password ingesteld is. vb. https://stackoverflow.com...se-server-mysql-workbench
Veel problemen lijken te gaan over windows installaties.

Geprobeerd:

• MySQL workbench as root draaien, geen verschil
• Via SSH op de VPS volgende uitvoeren: mysql -u remote -p -h 127.0.0.1 -P 3306, verbinding gaat door
• Authentication Plugin: Native MySQL / SHA -> geen verschil
• Afdwingen / niet afdwingen SSL -> geen verschil

Ik hoor graag uw advies!

[Hero of Time]

Je hebt wel een wachtwoord ingesteld dus voor de gebruiker. Wat krijg je terug als je "select * from mysql.user where User = 'remote'" doet? Zie je dan wel je user 'remote' terug met een wachtwoord, en maar 1 result hiervoor? Het lijkt er namelijk op alsof het met een iets andere user connect string probeert te verbinden met de database.

[CB32]

Hero of Time schreef op dinsdag 23 januari 2018 @ 09:25:
Je hebt wel een wachtwoord ingesteld dus voor de gebruiker. Wat krijg je terug als je "select * from mysql.user where User = 'remote'" doet? Zie je dan wel je user 'remote' terug met een wachtwoord, en maar 1 result hiervoor? Het lijkt er namelijk op alsof het met een iets andere user connect string probeert te verbinden met de database.

Ja, als ik die query uitvoer krijg ik 1 rij terug met een wachtwoord, password_expired = N, password_lifetime = NULL.

[Brahiewahiewa]

Je error message spreekt van 127.0.0.1, da's localhost, niet remotehost

[CB32]

Brahiewahiewa schreef op dinsdag 23 januari 2018 @ 13:25:
Je error message spreekt van 127.0.0.1, da's localhost, niet remotehost

Dat klopt, maar de de host is relatief: ik verbind vanaf de VPS (via en tunnel) en dus 127.0.0.1. Port 3306 is niet van buiten bereikbaar. Exact zelfde instellingen, maar password verwijderen van account geeft een perfecte verbinding.

[Shivs]

Zie je ook in de logs terugkomen dat je probeert in te loggen in MySQL? En indien ja, vanaf welk IP adres dat gepoogd wordt? Het lijkt namelijk op een rechten dingetje met deze user.

Daarnaast zo je kunnen proberen wat er gebeurd als je hetzelfde doet met je root user, gewoon om te vergelijken of het met de account te maken heeft of met iets anders.

[GlowMouse]

Ik kan echter alleen succesvol verbinden met MySQL als ik deze user geen password mee geef.

De foutmelding die je hebt gepost heeft niets te maken met wel/geen wachtwoord, dus deze quote geloof ik eigenlijk niet.

[ Voor 191% gewijzigd door GlowMouse op 23-01-2018 14:45 ]

[The Eagle]

Je gaat via een SSH tunnel. Heb je poort 3306 ook geforward in je ssh client? Wordt nog wel eens vergeten.

[Hero of Time]

Waarom zit je via een SSH tunnel te werken? Is het niet de bedoeling van die MySQLBench dat je 't lokaal draait, dus op de server zelf? Waarom hebben ze 't er anders over om de boel via 127.0.0.1 te connecten?

[CB32]

Hero of Time schreef op dinsdag 23 januari 2018 @ 15:13:
Waarom zit je via een SSH tunnel te werken? Is het niet de bedoeling van die MySQLBench dat je 't lokaal draait, dus op de server zelf? Waarom hebben ze 't er anders over om de boel via 127.0.0.1 te connecten?

De VPS is headless, ik gebruik workbench GUI lokaal om een db schema te maken en dan te synchroniseren met de VPS. En dat werkt dus perfect, zolang de MySQL user maar geen password heeft.

Verbinden naar publiek adres heeft geen nut want de poort staat dicht, en dat blijft lekker zo.

Kan nu even niet bij de logs maar zal ze onderzoeken.

[Hero of Time]

Dan nog. Als het een GUI heeft, gebruik je X11-forwarding (zit standaard in MobaXterm voor Windows, en op Linux gebruik je ssh -X ) en draai je 't alsnog lokaal. Even zorgen dat je een paar fonts geïnstalleerd hebt staan icm xauth en gaan.

[Merethil]

Hero of Time schreef op dinsdag 23 januari 2018 @ 17:23:
Dan nog. Als het een GUI heeft, gebruik je X11-forwarding (zit standaard in MobaXterm voor Windows, en op Linux gebruik je ssh -X ) en draai je 't alsnog lokaal. Even zorgen dat je een paar fonts geïnstalleerd hebt staan icm xauth en gaan.

Waarom zou je dat doen? Er zit niet voor niets een mogelijkheid tot SSH-tunnel in die software, die hoort gewoon prima te werken want hij hoeft alleen wat commando's door te sturen naar de MySQL instance op je server.
Beetje nutteloos om resources op je server te gebruiken om daar de workbench te draaien terwijl je een pc of laptop hebt die dat prima kan, laat staan de extra rotzooi die je moet installeren om zo'n workbench te draaien (o.a. moet je een JVM hebben, lekker zonde op een server die bijvoorbeeld alleen PHP draait ofzo)

[Hero of Time]

@Merethil, ken de tool niet maar dacht dat hij apart een tunnel opzette en de tool via de tunnel liet lopen, ipv dat de tool alles zelf regelt (wijs naar server en laat 'm zweten).

[Merethil]

Hero of Time schreef op dinsdag 23 januari 2018 @ 17:40:
@Merethil, ken de tool niet maar dacht dat hij apart een tunnel opzette en de tool via de tunnel liet lopen, ipv dat de tool alles zelf regelt (wijs naar server en laat 'm zweten).

Ah dat verklaart
De tool zet een tunnel op en daarna doe je relatief aan het pad aan de andere kant van de tunnel je MySQL-connectie opzetten, dus naar localhost.
Op zich een hele normale gang van zaken en zou dus niet mogen verschillen tussen gewoon via SSH MySQL aanroepen in de terminal of op deze manier, vreemd dus ook dat het een wel werkt en het ander niet met passwoord.

@CB32 kan het zijn dat je login van de SSH-tunnel andere credentials gebruikt dan wanneer je via SSH inlogt en in de terminal MySQL aanroept?

[Hero of Time]

Merethil schreef op dinsdag 23 januari 2018 @ 19:01:
@CB32 kan het zijn dat je login van de SSH-tunnel andere credentials gebruikt dan wanneer je via SSH inlogt en in de terminal MySQL aanroept?

Dat is puur wat je hebt ingesteld. Als je met SSH inlogt met gebruiker piet en wachtwoord klaas, terwijl je databasegebruiker jan is met wachtwoord mies, ga je natuurlijk geen werkende SQL connectie krijgen als je met piet probeert in te loggen. Daarom is het zo belangrijk om je logs na te kijken.

[Blokker_1999]

Maakt niet uit, je hebt voor alle twee aparte credentials in de workbench.

De error 111 in zijn foutmelding is een connection refused. Het zou me niet verbazen dat er iets mis is met de tunnel waardoor 127.0.0.1 niet meer tot bij de workbench geraakt maar dat de verbinding een ander IP gebruikt voor de connectie. Best zoals aangegevende logs nakijken en zien vanwaar de verbinding volgens de MySQL server vandaan komt.

[The Eagle]

Die connection refused kan bij ssh verkeer natuurlijk ook komen door missende certificaten. Dan heb je geen passwordless login met je user vanuit de workbench.
Als je normaal inlogt met ssh, moet je dan een ww intypen of niet?

[MSteverink]

Heb je, al dan niet per ongeluk, ook op de lokale PC MySQL -server geïnstalleerd staan?

[CB32]

MSteverink schreef op woensdag 24 januari 2018 @ 17:39:
Heb je, al dan niet per ongeluk, ook op de lokale PC MySQL -server geïnstalleerd staan?

Ja dat heb ik. Zou MySQL Workbench op de een of andere manier die proberen te bereiken?


Over instellingen SSH, die moeten wel goed zijn omdat ik *zonder* instellingen in Workbench aan te passen, een volledige verbinding krijgt, die alleen (lijkt) af te hangen of de MySQL user wel of geen password heeft ingesteld.

Nog wel even mijn mysql error log kunnen bekijken maar die lijkt heel erg leeg. Morgen nog een keer proberen.

Helaas kan ik nu geen andere dingen testen. Ik werk vanuit Ugandan en onze "Unlimited" verbinding heeft zojuist voor vandaag zijn limiet weer bereikt en ben ik beperkt tot 128kbps, maar dat gaat helemaal nergens over.

[Hero of Time]

Ik heb zelf even de tool geïnstalleerd. Dit is het scherm voor een nieuwe connectie, heb je die wel op deze manier ingevuld?

Let op de connection method, die moet je dus zetten op Standard TCP/IP over SSH en dan heb je aparte credentials voor SSH en MySQL.

[MSteverink]

CB32 schreef op donderdag 25 januari 2018 @ 07:57:
[...]
Ja dat heb ik. Zou MySQL Workbench op de een of andere manier die proberen te bereiken?

Misschien. Je moet ernstig overwegen om die lokale server, in elk geval tijdelijk, uit te schakelen tijdens het testen/debuggen.

Heb je ook nog een SSH-server lokaal?

[ Voor 5% gewijzigd door MSteverink op 25-01-2018 09:26 ]

[CB32]

Allen,

ik vermoed dat het om een bug in MySQL Workbench gaat:

Ik heb een verse user, "workbench" aangemaakt op de MySQL server. Deze user heeft een password.


Verbinding in Workbench is alsolgt:


Als ik vervolgens verbind, en het juiste wachtwoord ingeef voor "workbench" dan krijg ik de volgende error in de mysql error log:

code:

2018-01-26T11:11:14.079614Z 109 [Note] Access denied for user 'workbench'@'localhost' (using password: NO)

Als ik vervolgens voor de user "workbench" (in MySQL) geen wachtwoord meegeef:


Dan wordt mijn verbinding netjes gemaakt, er is immers geen wachtwoord om te controleren door de MySQL server.

Nu geef ik de user "workbench" opnieuw een wachtwoord, maar ditmaal met Password Hashing "SHA256 Password Autentication" ipv "Native MySQL Authentication"


Ik krijg dezelfde error in de log en in workbench.

Ook als ik SSL forceer (instellen MySQL + in workbench) krijg ik exact dezelfde error meldingen. Workbench lijkt het password niet (goed) mee te sturen.

Wat zie ik over het hoofd?

[ Voor 3% gewijzigd door CB32 op 26-01-2018 12:31 . Reden: Plaatjes gingen niet goed in list ]

[CH4OS]

Ik kreeg Workbench via SSH ook nooit aan de praat op mijn dev machine op het werk, naar de VPS van onze testomgeving. Uiteindelijk kreeg ik dat wel aan de praat met DBeaver.

[GlowMouse]

Druk eens op 'clear' bijna onderaan. Het kan zijn dat hij ooit zonder wachtwoord verbinding kon maken, en dat heeft onthouden.
Als workaround kun je altijd nog een ssh-tunnel opzetten met je favoriete ssh-client.