Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Bug: Connecting through SSH Tunnel Using Plink within Windows 10 64bit isn't established #521
Opening issue as in https://www.heidisql.com/forum.php?t=26506#p26509 requestd.
I have this bug (like www.heidisql.com/forum.php?t=15224 one years ago) since latest 9.5 up to actual 10.1.0.5471 version since I was switched from Windows 7 64bit to Windows 10 64bit version in November.
In first tries it seems to be related to 64bit version of HeidiSQL because last year I got running the 9.5 portable 32bit version but thats now also not working anymore.
The connection to SSH server is established and request for my SSH pubkey by agent is made and accepted but then HeidiSQL is hanging endless without connecting successful through the tunnel to the MariaDB servers.
Both 32/64 bit versions are connecting fine to MariaDB servers (running different versions 10.1 / 10.2).
There seems yet no "actual" bug notification by someone other on this cause so I opened a new one.
Steps to reproduce this issue
HeidiSQL freezes / waits endless for MariaDB/MySQL connection
Should connect to MariaDB/MySQL server as in direct links.
Hello @ansgarbecker ,
If this question was on me: I had successful tested manual call of plink like
because I didn't see/debug how HeidiSQL is calling this program.
Or do you asked this to @petertiny ?
Hello @ansgarbecker ,
I found the cause in latest 10.1 version by activating SQL logging to file which also writes the plink call/output as SQL comments into it.
You are calling plink.exe with the wrong
which creates an unneeded interactive shell and causes an interactive prompt which must be accepted before having ports forwarded:
You need to switch the parameter to
I think we have to wait for a nightly release with this fix because the plink call is not configurable but compiled in. But I guess this won't take long to get it active since there was already a response by developer ;)
After cloning/checking for the line with wrong create online the fix/pull request; Github fixed nearby mixed newline to Windows ones:
Thanks for that pull request. As I am a bit picky about unrelated changes in commits, I did not merge the pull request with the unintentionally line feed changes. Also I don't know how to merge only a part of a pull request.
Are you sure that -batch parameter works with older plink versions?
Hi, no problem - the line switch was automatically done by Github when doing online edit.
The batch parameter exists since beginning as e.g. here shown:
EDIT: If not yet patched; you can also add instead switching the parameter -ssh which is default connection type so it's not needed but if you want to be sure (as before) you can use both parameters:
Hi @ansgarbecker, sadly this seems not fix the problem yet.
Is it possible to get enhanced logging active for nightly builds to better see what the problem is? Perhaps this could also be later default if it make sense or a checkbox option.
but it seems correct from logging:
Compared to direct cmd call:
I am only a little wondering where the 4 additional empty ErrorText lines come from.
thanks for updating the call for testing.
The behavior is weird, now I got a popup exception window for the first three lines:
and in log I have these lines:
For this host it seems to be also a problem that IPv6 access is tried too long before switching to IPv4 connection.
=> Could there be a problem with these lines which breaks somehow the waiting loop?
So I tried another host with IPv4 only and get here 2 popups.
The lost connection comes from hard kill of pagent.exe after some minutes blocking HeidiSQL foreground process.
So the plink.exe process is running fine with
Since I didn't know howto debug such MySQL handshakes I sadly cannot help here much but it seems that the handshake is somehow not started correctly / too early to get the connection up and running.
thanks and best is that other people like @petertiny could also test the new behavior.
I have no special server and tested it before with 2 and today with 3 different servers.
The only party why on external DC the IPv6 connection is delaying / not connecting comes because I use at home a HE IPv6 network tunnel with is geolocated in US and I allow SSH connects only from DE using converted MaxMind GeopIP2 database because last time the sshd scanner were very aggressive scanning even they have no chance to get in.
With todays nightly build I got now on all 3 connections
One idea came up - should the
because it's again remembering me onto this not clear break of the given timeout by configuration: