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 I've tried every combination of, 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\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?

  • SMSS use port 1434 (SRRP) to query Browser Service, but you may not forward this port, because it is UDP port and putty is not capable of forwarding UDP. My best guess is that you have a browser service installed on client host and SRRP lookup return invalid results, so SMSS would not connect. You can try forwarding port not on, but on real IP address your client have and try to connect to it.
    – kab00m
    Nov 2, 2020 at 8:56

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.