SQL Server przez tunel SSH

Połączenie przez tunel SSH przekierowuje ruch bazodanowy przez szyfrowany kanał między klientem a serwerem.

Jak tunel SSH przekazuje połączenie do SQL Server

Tunel SSH tworzy zaszyfrowane połączenie pomiędzy klientem SSH a hostem pośredniczącym lub bezpośrednio serwerem, na którym działa SQL Server. W typowym wariancie używa się lokalnego przekierowania portu. Klient otwiera lokalny port, na przykład 11433, a każdą sesję TCP przyjętą na tym porcie przekazuje przez połączenie SSH do wskazanego adresu i portu po stronie serwera. Przykładowa składnia wygląda następująco: ssh -L 11433:127.0.0.1:1433 uzytkownik@host-ssh. Oznacza to, że lokalny port 11433 jest przekazywany do portu 1433 widzianego z hosta SSH.

Aplikacja kliencka SQL Server, na przykład sqlcmd, SQL Server Management Studio albo program korzystający z Microsoft.Data.SqlClient, łączy się wtedy z adresem 127.0.0.1,11433. Dla klienta końcem połączenia jest lokalny komputer, natomiast rzeczywisty ruch trafia przez SSH do procesu nasłuchującego na porcie SQL Server. Tunel nie zmienia protokołu TDS używanego przez SQL Server. Przekazuje jego ruch w strumieniu TCP, dlatego po stronie klienta nadal należy podać poprawny serwer, port, metodę uwierzytelniania i nazwę bazy.

Port instancji, SQL Browser i zakres przekierowania

Domyślna instancja SQL Server często nasłuchuje na porcie TCP 1433, ale numer ten nie jest gwarantowany dla każdej instalacji. Instancja nazwana może korzystać z określonego portu statycznego albo z portu dynamicznego. Numer używanego portu można sprawdzić w SQL Server Configuration Manager, w konfiguracji protokołu TCP/IP dla danej instancji, a także w dzienniku błędów SQL Server. Tunel SSH musi wskazywać rzeczywisty port instancji, a nie automatycznie zakładać port 1433.

Przy połączeniach do nazwanej instancji format serwer\instancja może wymagać działania SQL Server Browser. Usługa ta używa UDP 1434 do udostępniania informacji o portach instancji, natomiast proste przekierowanie SSH z opcją -L przekazuje konkretny strumień TCP i nie zapewnia automatycznego przekazywania zapytań UDP. Z tego powodu w tunelu należy zwykle podać adres lokalny oraz konkretny port, na przykład localhost,11433, zamiast polegać na rozpoznawaniu nazwy instancji. Jeżeli aplikacja wymaga nazwy serwera do walidacji certyfikatu lub innych ustawień, trzeba rozdzielić tę nazwę od adresu używanego do transportu i skonfigurować klienta zgodnie z jego dokumentacją.

Szyfrowanie SSH a szyfrowanie sesji SQL Server

SSH szyfruje transport pomiędzy klientem SSH a hostem kończącym tunel. Chroni to dane przed odczytem na odcinku objętym sesją SSH, ale nie zastępuje konfiguracji zabezpieczeń samego SQL Server. Jeżeli tunel kończy się na serwerze SQL albo na zaufanym hoście w tej samej sieci, dalszy odcinek od hosta SSH do SQL Server może być osobnym połączeniem TCP. W przypadku przekierowania do 127.0.0.1 na hoście SSH oznacza ono lokalny interfejs tego hosta, nie lokalny komputer użytkownika.

SQL Server może dodatkowo używać TLS dla protokołu TDS. Ustawienia klienta takie jak Encrypt, TrustServerCertificate oraz walidacja nazwy certyfikatu wpływają na tę warstwę niezależnie od SSH. Tunel nie powoduje automatycznego uznania certyfikatu SQL Server za zaufany i nie naprawia błędnej konfiguracji TLS. W środowisku produkcyjnym należy sprawdzić, czy certyfikat jest wystawiony dla nazwy używanej przez klienta, czy łańcuch zaufania jest dostępny oraz czy wymuszanie szyfrowania po stronie SQL Server jest zgodne z ustawieniami aplikacji. Opcja wyłączająca weryfikację certyfikatu może umożliwić test, ale zmienia model zaufania i nie powinna być traktowana jako uniwersalne rozwiązanie.

Weryfikacja tunelu i typowe przyczyny nieudanego logowania

Najpierw trzeba potwierdzić, że lokalny port został otwarty przez klienta SSH i nie jest zajęty przez inny proces. Następnie można sprawdzić dostępność portu z komputera użytkownika, na przykład poleceniem PowerShell Test-NetConnection 127.0.0.1 -Port 11433. Sukces testu TCP oznacza tylko, że istnieje ścieżka do portu; nie potwierdza poprawności protokołu SQL Server, loginu ani uprawnień do bazy. Komunikat o odmowie połączenia zwykle wskazuje na błędny port, brak nasłuchu SQL Server, zaporę lub niepoprawny adres docelowy przekierowania.

Jeżeli tunel działa, ale klient SQL Server nie może się zalogować, należy osobno sprawdzić uwierzytelnianie Windows lub SQL Server, format nazwy użytkownika, dostępność wskazanej bazy oraz reguły logowania na instancji. Błąd TLS może wynikać z certyfikatu, nazwy serwera albo ustawienia szyfrowania, mimo że sam tunel SSH jest aktywny. Przy zrywaniu sesji warto uruchomić SSH z diagnostyką -v lub -vv, używać opcji -N dla tunelu bez powłoki oraz rozważyć -o ExitOnForwardFailure=yes, aby klient zakończył pracę, gdy nie uda się ustanowić przekierowania. Diagnostyka powinna rozdzielać trzy etapy: zestawienie SSH, połączenie TCP z portem instancji oraz negocjację i logowanie w SQL Server.