Condividi tramite


Connessione da Linux o macOS

Scaricare il driver ODBC

Questo articolo descrive come creare una connessione a un database di SQL Server.

Proprietà connessione

Per tutte le parole chiave e gli attributi delle stringhe di connessione supportati in Linux e macOS, vedere Parole chiave e attributi per stringhe di connessione e DSN.

Importante

Se si stabilisce una connessione a un database che usa il mirroring, ovvero dispone di un partner di failover, non specificare il nome del database nella stringa di connessione. Inviare invece un comando use database_name per connettersi al database prima di eseguire le query.

Il valore passato alla parola chiave Driver può essere uno dei seguenti:

  • Il nome usato al momento dell'installazione del driver.

  • Il percorso della libreria di driver specificato nel file ini del modello usato per l'installazione del driver.

I DSN sono facoltativi. È possibile usare un DSN per definire parole chiave della stringa di connessione sotto un nome DSN al quale è poi possibile fare riferimento nella stringa di connessione. Per creare un DSN, creare, se necessario, e modificare il file ~/.odbc.ini (.odbc.ini nella home directory) per un DSN utente accessibile solo all'utente corrente o /etc/odbc.ini per un DSN di sistema (richiede privilegi amministrativi). Di seguito è riportato un file odbc.ini di esempio con le voci minime richieste per un 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
#  

Per connettersi usando il DSN precedente in una stringa di connessione è necessario specificare la parola chiave DSN come DSN=MSSQLTest;UID=my_username;PWD=my_password
La stringa di connessione precedente equivale a specificare una stringa di connessione senza la parola chiave DSN come Driver=ODBC Driver 18 for SQL Server;Server=tcp:localhost,1433;Encrypt=yes;UID=my_username;PWD=my_password

È anche possibile specificare il protocollo e la porta per la connessione al server. Ad esempio, Server=tcp:nomeserver, 12345. L'unico protocollo supportato dai driver Linux e macOS è tcp.

Per connettersi a un'istanza denominata tramite una porta statica, usare Server=nomeserver,numero_porta. La connessione a una porta dinamica non è supportata prima della versione 17.4.

In alternativa, è possibile aggiungere le informazioni del DSN in un file di modello ed eseguire il comando seguente per aggiungere tali informazioni a ~/.odbc.ini:

odbcinst -i -s -f <template_file>

Per la documentazione completa sui file INI e odbcinst, vedere la documentazione di unixODBC. Per le voci del file odbc.ini specifiche del driver ODBC per SQL Server, vedere Parole chiave e attributi per stringhe di connessione e DSN per le voci supportate in Linux e macOS.

È possibile verificare che il driver funzioni usando isql per testare la connessione oppure usare questo comando:

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

Uso di TLS/SSL

È possibile usare Transport Layer Security (TLS), noto in precedenza come Secure Sockets Layer (SSL), per crittografare le connessioni a SQL Server. TLS protegge i nomi utente e le password di SQL Server in rete. TLS verifica anche l'identità del server per la protezione dagli attacchi man-in-the-middle (MITM).

L'abilitazione della crittografia aumenta la sicurezza a scapito delle prestazioni.

Per altre informazioni, vedere Crittografia delle connessioni a SQL Server e Utilizzo della crittografia senza convalida.

Indipendentemente dalle impostazioni di Encrypt e TrustServerCertificate, le credenziali di accesso al server (nome utente e password) vengono sempre crittografate. Le tabelle seguenti mostrano l'effetto delle impostazioni di Encrypt e TrustServerCertificate.

ODBC Driver 18 e versioni successive

Impostazione di crittografia TrustServerCertificate Crittografia richiesta dal server Risultato
No No No Il certificato del server non viene controllato.
I dati inviati tra client e server non vengono crittografati.
No No Il certificato del server non viene controllato.
I dati inviati tra client e server non vengono crittografati.
No No Il certificato del server viene verificato.
I dati inviati dal client al server e viceversa vengono crittografati.
No Il certificato del server non viene controllato.
I dati inviati dal client al server e viceversa vengono crittografati.
No No Il certificato del server viene verificato.
I dati inviati dal client al server e viceversa vengono crittografati.
No Il certificato del server non viene controllato.
I dati inviati dal client al server e viceversa vengono crittografati.
No Il certificato del server viene verificato.
I dati inviati dal client al server e viceversa vengono crittografati.
Il certificato del server non viene controllato.
I dati inviati dal client al server e viceversa vengono crittografati.
Strict - - L'opzione TrustServerCertificate viene ignorata. Il certificato del server viene verificato.
I dati inviati dal client al server e viceversa vengono crittografati.

Nota

L'impostazione Strict è disponibile solo per i server che supportano le connessioni TDS 8.0.

ODBC Driver 17 e versioni precedenti

Impostazione di crittografia TrustServerCertificate Crittografia richiesta dal server Risultato
No No No Il certificato del server non viene controllato.
I dati inviati tra client e server non vengono crittografati.
No No Il certificato del server non viene controllato.
I dati inviati tra client e server non vengono crittografati.
No No Il certificato del server viene verificato.
I dati inviati dal client al server e viceversa vengono crittografati.
No Il certificato del server non viene controllato.
I dati inviati dal client al server e viceversa vengono crittografati.
No No Il certificato del server non viene controllato.
I dati inviati dal client al server e viceversa vengono crittografati.
No Il certificato del server non viene controllato.
I dati inviati dal client al server e viceversa vengono crittografati.
No Il certificato del server viene verificato.
I dati inviati dal client al server e viceversa vengono crittografati.
Il certificato del server non viene controllato.
I dati inviati dal client al server e viceversa vengono crittografati.

Quando si usa la crittografia della connessione, il nome (o l'indirizzo IP) in un nome comune del soggetto (CN, Common Name) o in un nome alternativo del soggetto (SAN, Subject Alternative Name) di un certificato TLS/SSL di SQL Server deve corrispondere esattamente al nome del server (o all'indirizzo IP) specificato nella stringa di connessione. La parola chiave HostnameInCertificate (v18.0+) può essere usata per specificare un nome alternativo da confrontare con i nomi del certificato TLS/SSL. Quando viene specificata la parola chiave, il certificato TLS/SSL SQL Server deve corrispondere a uno dei nomi del server o all'oggetto HostnameInCertificate.

Per impostazione predefinita, le connessioni crittografate verificano sempre il certificato del server. Tuttavia, se ci si connette a un server che ha un certificato autofirmato e non si usa la modalità di crittografia strict, aggiungere anche l'opzione TrustServerCertificate per ignorare il controllo del certificato rispetto all'elenco di autorità di certificazione attendibili:

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

In modalità di crittografia strict, il certificato viene sempre verificato. Come opzione per la convalida standard del certificato, la parola chiave ServerCertificate (v18.1+) può essere usata per specificare il percorso di un file di certificato da confrontare con il certificato SQL Server. Questa opzione è disponibile solo quando si usa la crittografia strict. I formati di certificato accettati sono PEM, DER e CER. Se il valore viene specificato, il certificato di SQL Server viene controllato esaminando se il valore di ServerCertificate fornito è una corrispondenza esatta.

TLS in Linux e macOS usa la libreria OpenSSL. La tabella seguente mostra le versioni minime supportate di OpenSSL e i percorsi dei file di archivio di scopi consentiti ai certificati predefiniti per ogni piattaforma:

Piattaforma Versione minima OpenSSL Percorso del file di archivio di scopi consentiti ai certificati
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
OS 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

È anche possibile specificare la crittografia nella stringa di connessione usando l'opzione Encrypt quando si usa SQLDriverConnect per connettersi.

Regolazione delle impostazioni keep-alive TCP

A partire dalla versione 17.4 del driver ODBC, la frequenza con cui il driver invia pacchetti keep-alive e li ritrasmette quando non viene ricevuta una risposta è configurabile. Per configurare, aggiungere le impostazioni seguenti alla sezione del driver in odbcinst.ini o alla sezione del DSN in odbc.ini. Quando ci si connette a un DSN, il driver usa le impostazioni presenti nella sezione del DSN, in caso contrario, o se ci si connette solo con una stringa di connessione, userà le impostazioni presenti nella sezione del driver in odbcinst.ini. Se l'impostazione non è presente in nessuna delle due posizioni, il driver usa il valore predefinito. A partire dalla versione 17.8 del driver ODBC, le parole chiave KeepAlive e KeepAliveInterval possono essere specificate nella stringa di connessione.

  • KeepAlive=<integer> determina la frequenza dei tentativi effettuati da TCP per verificare l'integrità di una connessione inattiva inviando un pacchetto keep-alive. Il valore predefinito è 30 secondi.

  • KeepAliveInterval=<integer> determina l'intervallo tra le ritrasmissioni keep-alive finché non viene ricevuta una risposta. Il valore predefinito è 1 secondo.

Vedi anche