Como conectar do Linux ou macOS
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 use database_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 | Não | 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 | Não | 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.