A Linux service reaches SQL Server through more than an open port. Connecting to SQL Server from Linux depends on the driver, identity, and certificate chain working together. Test those layers on the actual application host before blaming a query.
Choose a Supported Path for Connecting to SQL Server From Linux
Microsoft publishes ODBC Driver packages for supported Linux distributions. Start with the installation guide for the exact distribution and version. Add the Microsoft package source through your organization’s approved process, then install the driver package, such as msodbcsql18. Install mssql-tools18 separately if you need sqlcmd and bcp. The unixODBC driver manager is a dependency for ODBC applications and is handled by the supported package process.
I ask which machine runs the application, not which machine an administrator used for a quick test. A container image, service host, and jump box can carry different packages. Which environment is actually connecting to SQL Server from Linux? Record the distribution, architecture, driver package version, and tools package version. The answer prevents a successful test on one host from masking a missing driver on another.
Verify Driver Registration
After installation, confirm that unixODBC lists the Microsoft driver under the expected name. A connection string using ODBC Driver 18 for SQL Server must match the registered driver name. If the application reports a driver-not-found error, fix registration and architecture before changing credentials. A 32-bit process and a 64-bit driver are not interchangeable.
I also check which sqlcmd executable is on the path. Tool packages and application driver packages are separate. A working sqlcmd on an administrator’s shell does not prove the application loads the same ODBC library. Keep the executable path and driver registration in the deployment record. That small record saves a long walk through package history later.
Establish a Simple Test for Connecting to SQL Server From Linux
Use sqlcmd from the Linux host with the planned server and database. Start with an approved authentication path and a query that returns the connected instance. The T-SQL query below can be sent by sqlcmd or the application after connecting. It confirms the destination and current login. It cannot prove certificate validation by itself, so pair it with the client configuration and connection log.
I test by server name, not only by an IP address. TLS validation checks the name against the certificate. A direct IP test that needs a trust bypass is a different configuration from the production name. Keep DNS, firewall, and SQL Server port checks separate from authentication tests.
SELECT
@@SERVERNAME AS ConnectedInstance,
ORIGINAL_LOGIN() AS LoginName,
DB_NAME() AS CurrentDatabase;Plan Kerberos Before Replacing Passwords
When connecting to SQL Server from Linux, the Microsoft ODBC Driver can use Kerberos integrated authentication. That requires a valid ticket, correct realm configuration, and a service principal name for the SQL Server endpoint. Configure the service identity and keytab through your organization’s security process. Use Trusted_Connection in the client connection settings only after the ticket flow works. A missing ticket is not fixed by changing the SQL query.
I check the ticket cache under the same operating-system account that runs the service. An administrator’s ticket does not travel into another account’s process. Verify clock synchronization and name resolution too. Kerberos is precise about identity. It is not impressed by a server nickname that exists only in one configuration file.
Validate the Certificate When Connecting to SQL Server From Linux
ODBC Driver 18 requests encrypted connections by default and validates the server certificate under normal settings. The Linux host must trust the issuing certificate authority, and the SQL Server name used by the client must match the certificate. Install the approved trust chain in the client environment. A certificate mismatch should lead to a name or certificate correction.
TrustServerCertificate can bypass validation in some modes, but it is a diagnostic shortcut rather than the desired production state. I compare the configured server name with the certificate identity before reaching for that setting. The encrypted flag can still say yes when identity validation was skipped. Encryption and trust answer different questions.
Inspect the Server-Side Session
Once the connection succeeds, query the current session for transport, encryption, and authentication scheme. The values describe this SQL Server session, not the full Linux driver configuration. They help confirm whether the negotiated connection fits the plan. Run the query through the same service path when possible.
If the result differs from the intended setup, check the driver connection string, authentication mode, and server endpoint. A local admin connection can use a different protocol or login from the application. I keep one diagnostic query in the runbook so the next deployment can check the same fields without guessing which client option was used.
SELECT
c.net_transport,
c.encrypt_option,
c.auth_scheme,
c.client_net_address
FROM sys.dm_exec_connections AS c
WHERE c.session_id = @@SPID;Separate Driver Errors From SQL Errors
A driver load failure happens before a socket opens. A TLS trust failure happens before login completes. A login rejection happens before application SQL runs. Log those stages separately, without writing passwords or tickets to the log. Give the support team the driver name, package version, server name, and relevant error text.
I ask for the first failure, not the last retry message. Retries can cover the original cause with timeouts. Test a known-good path on the same host, then change one setting at a time. If the certificate fails, do not switch the application to an unencrypted connection to make a dashboard green. Fix the trust path.
Keep Packages and Configuration Together
Pin the driver and tools versions in the deployment record. Test upgrades against the current SQL Server and authentication setup. Check that package updates do not leave an old driver name in the connection string or an unexpected sqlcmd earlier in the path. Use a controlled rollout across application hosts and compare behavior before retiring the old package.
The operating guide should state how the driver is installed on that Linux distribution, where Kerberos credentials come from, which certificate authority is trusted, and how to run the connection check. This is enough to make the next rebuild reproducible without turning the database into a password-sharing exercise.
Related reading on this blog: SQL Server on Linux: SQL in Sixty Seconds #162 and Fix: Error: The certificate chain was issued by an authority that is not trusted.
A Linux SQL Server connection is not an open port, it is a tested path through driver, identity, and trust.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
