Como conectar do Linux ou macOS

Artigo
07/31/2023

Este artigo discute como criar uma conexão com um banco de dados SQL Server.

Propriedades da conexão

Confira DNS e palavras-chave e atributos da cadeia de conexão para ver todas as palavras-chave e atributos da cadeia de conexão compatíveis com Linux e macOS.

Importante

Ao se conectar a um banco de dados que use o espelhamento de banco de dados (tem um parceiro de failover), não especifique o nome do banco de dados na cadeia de conexão. Em vez disso, envie um comando usedatabase_name para se conectar ao banco de dados antes de executar suas consultas.

O valor passado para a palavra-chave Driver pode ser um dos seguintes:

O nome usado quando você instalou o driver.
O caminho para a biblioteca de drivers, que foi especificada no arquivo .ini de modelo usado para instalar o driver.

DSNs são opcionais. É possível usar um DSN para definir palavras-chave de cadeia de conexão com um nome DSN ao qual você pode fazer referência na cadeia de conexão. Para criar um DSN, crie (se necessário) e edite o arquivo ~/.odbc.ini (.odbc.ini em seu diretório base) para um DSN de Usuário acessível somente para o usuário atual ou /etc/odbc.ini para um DSN de Sistema (são necessários privilégios administrativos). O seguinte odbc.ini é um exemplo que mostra as entradas mínimas necessárias para um DSN:

# [DSN name]
[MSSQLTest]  
Driver = ODBC Driver 18 for SQL Server  
# Server = [protocol:]server[,port]  
Server = tcp:localhost,1433
Encrypt = yes
#
# Note:  
# Port isn't a valid keyword in the odbc.ini file  
# for the Microsoft ODBC driver on Linux or macOS
#

Para se conectar usando o DSN acima em uma cadeia de conexão, é necessário especificar a palavra-chave DSN, como: DSN=MSSQLTest;UID=my_username;PWD=my_password
A cadeia de conexão acima seria equivalente a especificar uma cadeia de conexão sem a palavra-chave DSN, como: Driver=ODBC Driver 18 for SQL Server;Server=tcp:localhost,1433;Encrypt=yes;UID=my_username;PWD=my_password

Opcionalmente, você pode especificar o protocolo e a porta para se conectar ao servidor. Por exemplo, Server = TCP:ServerName, 12345. O único protocolo compatível com os drivers do Linux e do macOS é o tcp.

Para se conectar a uma instância nomeada em uma porta estática, use Server=servername,port_number. Não há suporte para se conectar a uma porta dinâmica antes da versão 17.4.

Como alternativa, você pode adicionar as informações de DSN a um arquivo de modelo e executar o comando a seguir para adicioná-lo a ~/.odbc.ini:

odbcinst -i -s -f <template_file>

Confira a documentação completa sobre arquivos ini e odbcinst na documentação do unixODBC. Confira as entradas do arquivo odbc.ini específico do ODBC Driver para SQL Server em Atributos e palavras-chave da cadeia de conexão e DSN para ver aquelas com suporte no Linux e no macOS.

Você pode verificar se o driver está funcionando usando isql para testar a conexão ou pode usar o seguinte comando:

bcp master.INFORMATION_SCHEMA.TABLES out OutFile.dat -S <server> -U <name> -P <password>

Como usar o TLS/SSL

Use o protocolo TLS, anteriormente conhecido como SSL, para criptografar conexões com o SQL Server. O TLS protege nomes de usuário e senhas do SQL Server na rede. O TLS também confirma a identidade do servidor para proteção contra ataques MITM (man-in-the-middle).

Habilitar a criptografia aumenta a segurança, mas reduz o desempenho.

Para obter mais informações, confira Criptografar conexões para o SQL Server e Usar criptografia sem validação.

Independentemente das configurações para Encrypt e TrustServerCertificate, as credenciais de logon do servidor (nome de usuário e senha) sempre são criptografadas. As tabelas a seguir mostram o efeito das configurações Encrypt e TrustServerCertificate.

Driver ODBC 18 e mais recentes

Configuração de criptografia	Confiar em Certificado do Servidor	Criptografia forçada do servidor	Resultado
Não	No	Não	O certificado do servidor não é verificado. Os dados enviados entre o cliente e o servidor não são criptografados.
Não	Sim	Não	O certificado do servidor não é verificado. Os dados enviados entre o cliente e o servidor não são criptografados.
Sim	No	Não	O certificado do servidor é verificado. Os dados enviados entre cliente e servidor são criptografados.
Sim	Sim	Não	O certificado do servidor não é verificado. Os dados enviados entre cliente e servidor são criptografados.
Não	No	Sim	O certificado do servidor é verificado. Os dados enviados entre cliente e servidor são criptografados.
Não	Sim	Sim	O certificado do servidor não é verificado. Os dados enviados entre cliente e servidor são criptografados.
Sim	Não	Sim	O certificado do servidor é verificado. Os dados enviados entre cliente e servidor são criptografados.
Sim	Sim	Sim	O certificado do servidor não é verificado. Os dados enviados entre cliente e servidor são criptografados.
Rigoroso	-	-	TrustServerCertificate é ignorado. O certificado do servidor é verificado. Os dados enviados entre cliente e servidor são criptografados.

Observação

Estrito só está disponível em servidores que dão suporte a conexões TDS 8.0.

Driver ODBC 17 e mais antigos

Configuração de criptografia	Confiar em Certificado do Servidor	Criptografia forçada do servidor	Resultado
Não	No	Não	O certificado do servidor não é verificado. Os dados enviados entre o cliente e o servidor não são criptografados.
Não	Sim	Não	O certificado do servidor não é verificado. Os dados enviados entre o cliente e o servidor não são criptografados.
Sim	No	Não	O certificado do servidor é verificado. Os dados enviados entre cliente e servidor são criptografados.
Sim	Sim	Não	O certificado do servidor não é verificado. Os dados enviados entre cliente e servidor são criptografados.
Não	No	Sim	O certificado do servidor não é verificado. Os dados enviados entre cliente e servidor são criptografados.
Não	Sim	Sim	O certificado do servidor não é verificado. Os dados enviados entre cliente e servidor são criptografados.
Sim	Não	Sim	O certificado do servidor é verificado. Os dados enviados entre cliente e servidor são criptografados.
Sim	Sim	Sim	O certificado do servidor não é verificado. Os dados enviados entre cliente e servidor são criptografados.

Ao usar uma criptografia de conexão, o nome (ou o endereço IP) em um CN (Nome Comum) da Entidade ou o SAN (Nome Alternativo da Entidade) em um certificado do SQL Server TLS/SSL deve corresponder exatamente ao nome do servidor (ou ao endereço IP) especificado na cadeia de conexão. A palavra-chave HostnameInCertificate (v18.0 e mais recente) pode ser usada para especificar um nome alternativo que é usado para a correspondência com os nomes no certificado TLS/SSL. Quando a palavra-chave é especificada, o certificado TLS/SSL do SQL Server deve fazer a correspondência com o nome do servidor ou com HostnameInCertificate.

Por padrão, conexões criptografadas sempre verificam o certificado do servidor. No entanto, se você se conectar a um servidor que tem um certificado autoassinado e não estiver usando o modo de criptografia estrito, poderá adicionar a opção TrustServerCertificate para ignorar a verificação do certificado em relação à lista de autoridades de certificação confiáveis:

Driver={ODBC Driver 18 for SQL Server};Server=ServerNameHere;Encrypt=YES;TrustServerCertificate=YES

No modo de criptografia estrito, o certificado sempre é verificado. Como uma opção à validação de certificado padrão, a palavra-chave ServerCertificate (v18.1 e mais recente) pode ser usada para especificar o caminho para um arquivo de certificado que deve corresponder ao certificado SQL Server. Essa opção só está disponível ao usar a criptografia estrita. Os formatos de certificado aceitos são PEM, DER e CER. Se especificado, o certificado SQL Server será verificado para analisar se o ServerCertificate fornecido é uma correspondência exata.

O TLS no Linux e no macOS usa a biblioteca OpenSSL. A tabela a seguir mostra as versões mínimas com suporte do OpenSSL e os locais dos repositórios de confiança de certificado para cada plataforma:

Plataforma	Versão mínima do OpenSSL	Local do repositório de confiança de certificado padrão
Debian 10, 11, 12	1.1.1	/etc/ssl/certs
Debian 9	1.1.0	/etc/ssl/certs
Debian 8.71	1.0.1	/etc/ssl/certs
Sistema Operacional X 10.11, macOS	1.0.2	/usr/local/etc/openssl/certs
Red Hat Enterprise Linux 9	3.0.1	/etc/pki/tls/cert.pem
Red Hat Enterprise Linux 8	1.1.1	/etc/pki/tls/cert.pem
Red Hat Enterprise Linux 7	1.0.1	/etc/pki/tls/cert.pem
Red Hat Enterprise Linux 6	1.0.0-10	/etc/pki/tls/cert.pem
SUSE Linux Enterprise 15	1.1.0	/etc/ssl/certs
SUSE Linux Enterprise 11, 12	1.0.1	/etc/ssl/certs
Ubuntu 22.04, 23.04	3.0.2	/etc/ssl/certs
Ubuntu 20.04	1.1.1	/etc/ssl/certs
Ubuntu 18.04	1.1.0	/etc/ssl/certs
Ubuntu 16.04	1.0.2	/etc/ssl/certs
Ubuntu 14.04	1.0.1	/etc/ssl/certs
Alpine 3.17, 3.18	3.0.1	/etc/ssl/certs

Você também poderá especificar a criptografia na cadeia de conexão usando a opção Encrypt ao empregar o SQLDriverConnect para se conectar.

Ajustando as configurações keep alive do TCP

Do Driver ODBC 17.4 em diante, é possível configurar a frequência com que o driver envia pacotes keep alive e os retransmite quando uma resposta não é recebida. Para configurar, adicione as configurações a seguir à seção do driver em odbcinst.ini ou à seção do DSN em odbc.ini. Ao se conectar com um DSN, o driver usará as configurações da seção do DSN, se existente; caso contrário ou se estiver se conectando somente com uma cadeia de conexão, usará as configurações da seção do driver em odbcinst.ini. Se a configuração não estiver presente em nenhum dos locais, o driver usará o valor padrão. A partir do Driver ODBC 17.8, as palavras-chave KeepAlive e KeepAliveInterval podem ser especificadas na cadeia de conexão.

KeepAlive=<integer> controla a frequência com que o TCP tenta verificar se uma conexão ociosa ainda está intacta enviando um pacote keep alive. O padrão é 30 segundos.
KeepAliveInterval=<integer> determina o intervalo que separa cada retransmissão keep alive até que uma resposta seja recebida. O padrão é 1 segundo.