WSL2使用ODBC连接远程SQL Server报错问题排查

WSL2是独立的Linux虚拟化环境，和Windows宿主机的认证体系、证书信任链完全隔离，能ping通服务器只代表网络三层连通，不代表应用层连接能通。
Windows能正常连接是因为两个默认逻辑：

• 域环境下Windows自动缓存当前登录用户的Kerberos票据，SSPI认证不需要手动提供凭据
• Windows默认信任域内下发的自签名SQL Server证书，不会拦截TLS握手
  这两个逻辑WSL2都不会自动继承，直接照搬Windows的连接方式必然报错。

• Trusted_Connection=yes是Windows域集成认证开关，开启后ODBC驱动会强制读取本地Kerberos缓存做认证，直接忽略你配置的uid/pwd，这就是报「无Kerberos凭据」的直接原因。
• 你用sqlcmd时加的-G参数是Azure AD/域集成认证专用参数，开启后会强制走Kerberos认证流程、严格校验服务端证书，你在DSN里配的TrustServerCertificate=yes对加了-G的命令行连接完全不生效，这就是报自签名证书校验失败的直接原因。
• 连接地址写法错误：server@example.com格式里的@是Azure AD租户分隔符，不是普通地址写法；DSN里的tcp:server,port要注意参数首字母大写，unixODBC对参数、DSN名称大小写敏感，你之前敲isql -v mssqltest全小写，和你配置的[MSSQLTest]段名大小写不匹配，也会导致配置读取异常。
• 你配置里的uid/pwd/server参数首字母小写，部分版本的msodbcsql驱动不会识别小写的连接参数。

方案1：账号密码直连（不需要配Kerberos，最简便） #

1. 修改~/.odbc.ini的MSSQLTest配置段为如下内容：

[MSSQLTest]
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.9.so.1.1
Server=tcp:SQL服务器IP或FQDN,端口号(默认1433填1433)
Database=目标数据库名
Trusted_Connection=No
TrustServerCertificate=Yes
UID=域名\用户名（如果是SQL认证账号直接填账号名）
PWD=对应密码

2. isql测试时注意DSN名大小写，执行：

isql -v MSSQLTest

3. sqlcmd测试时不要加-G参数，执行：

sqlcmd -S tcp:SQL服务器IP或FQDN,端口号 -U "域名\用户名" -P "密码" -C

-C是sqlcmd命令行下跳过服务端证书校验的参数，和DSN里的TrustServerCertificate=Yes作用一致。

方案2：必须走域Kerberos集成认证 #

如果环境强制要求域认证不允许密码直连，额外做以下配置：

1. 安装Kerberos客户端：

sudo apt update && sudo apt install -y krb5-user

安装过程中按提示填写域的REALM（比如域是example.com就填EXAMPLE.COM）、域控KDC地址。
2. 手动申请域票据：

kinit 用户名@EXAMPLE.COM
# 执行后输入域账号密码，输完用klist命令确认票据正常生成

3. 保持DSN里Trusted_Connection=Yes配置，证书校验要么开TrustServerCertificate=Yes跳过，要么把SQL Server的自签名证书导入WSL2的系统证书信任库即可正常连接。

• 不要用服务器名@域名的格式写连接地址，@在SQL Server连接串里仅用于指定Azure AD租户，普通域环境连接直接写tcp:服务器FQDN,端口即可。
• 如果WSL2用默认NAT网络，确认Windows防火墙没有拦截WSL2子网到SQL Server端口的请求，你当前能ping通基本可以排除防火墙问题。

内容的提问来源于stack exchange，提问作者user1828605