I'm trying to use SSMS to connect via a SSH tunnel (using Putty) to a SQL Server default instance running on an AWS server. I can establish the tunnel and access data in the DB using SQLCMD from a PowerShell window on my workstation. However, I can't get SSMS to work at all.
I only have user privs on the local workstation, but I do have full root/admin in the AWS environment.
I'm using Putty to set up the SSH tunnel, Local port 1433 forwarded through the bastion server to the SQL server port 1433. When I log onto the bastion server and run tcpdump, I can easily see activity from the SQLCMD session. However, when I try connecting via SSMS, I'm seeing nothing relevant.
I've tried connecting to localhost as well as 127.0.0.1. I've tried every combination of 127.0.0.1, port #, and MSSQLSERVER, using a comma before the port # every time, putting the port # after the IP address and before the MSSQLSERVER as well as doing it after the MSSQLSERVER. Using forward slash and using backslash.
I believe the proper way should be 127.0.0.1\MSSQLSERVER,1433. The error I get when I do that is the standard MS SQL Server Error 1225.
When I RDP into the SQL server, I can connect using SSMS to the DB locally.
I've turned on the SQL Server Browser and added a tunnel for port 1434 to my putty configuration.
I've searched here, and other sites, but all fixes seem to be tied to issues on the server itself. I've tried implementing those fixes, even though I really don't see those as being the problem considering I can't see any related activity on the bastion.
And without admin access to the local workstation, I can't view the firewall settings or security logs to see what they might show me.
Any thoughts on what I might be missing?
Best Answer
We discovered the root cause yesterday. The SSMS application is running in a XenApp sandboxed environment and can't see the local machine. We tried a test image that had it installed directly on the image and it worked.