SQL Server 2025 Developer on Ubuntu 24.04

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Select SQL Server 2025 Developer on Ubuntu 24.04 as the software version and select your Region, then choose Launch through EC2.

Choose m5.large or larger, your key pair and a security group as described in Prerequisites. SQL Server needs at least 2 GB of memory.

Alternatively, launch with the AWS CLI. Replace the values in angle brackets:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=sql-server-developer}]'

On a new instance, first boot takes about five minutes. Amazon EBS loads the AMI's blocks from its snapshot the first time they are read, and SQL Server's setup reads 1.4 GB of program files. Until first boot finishes, systemctl is-active mssql-firstboot reports activating and /root/mssql-credentials.txt does not yet contain your credentials. Later boots start SQL Server in seconds.

Version SSH user

SQL Server 2025 Developer on Ubuntu 24.04 ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

Confirm that the first-boot service and SQL Server both report active:

systemctl is-active mssql-firstboot mssql-server

active active

Check what is listening. SQL Server listens on the loopback address only. Port 1433 is the database port, 1431 is an additional local SQL Server port, and 1434 is the local dedicated administrator connection (DAC). A sysadmin can use the DAC from the instance itself as an emergency connection when SQL Server stops responding. Remote DAC is off, and only SSH listens on the network.

sudo ss -Htlnp | awk '{print $4, $6}' | sed 's/,pid=[0-9]*,fd=[0-9]*//g' | sort -u

0.0.0.0:22 users:(("sshd"),("systemd")) 127.0.0.1:1431 users:(("sqlservr")) 127.0.0.1:1433 users:(("sqlservr")) 127.0.0.1:1434 users:(("sqlservr")) 127.0.0.53%lo:53 users:(("systemd-resolve")) 127.0.0.54:53 users:(("systemd-resolve")) [::1]:1431 users:(("sqlservr")) [::1]:1434 users:(("sqlservr")) [::]:22 users:(("sshd"),("systemd"))

The credentials file is readable only by root. List the setting names that it holds:

sudo ls -l /root/mssql-credentials.txt
sudo grep -oE '^[A-Z_0-9]+=' /root/mssql-credentials.txt

-rw------- 1 root root 688 Oct 20 02:31 /root/mssql-credentials.txt SA_USER= SA_PASSWORD= <set-at-first-boot>= TLS_CERT= TLS_CERT_SHA256=

Read the whole file with sudo cat /root/mssql-credentials.txt and store the password in your password manager. The password is unique to this instance.

Never pass the password to sqlcmd with -P, because it would land in your shell history and the process list. sqlcmd reads the password from the SQLCMDPASSWORD environment variable instead. Load it once per shell:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)"

The command blocks below repeat that line so that each one works on its own. sqlcmd is on the PATH of every login shell (/opt/mssql-tools18/bin), but the blocks use the full path.

Connect to the loopback address. The -C option tells sqlcmd to trust the instance's self-signed certificate. Step 6 shows how to verify the certificate instead.

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -Q "SET NOCOUNT ON; SELECT CAST(SERVERPROPERTY('Edition') AS nvarchar(40)) AS edition, CAST(SERVERPROPERTY('ProductVersion') AS nvarchar(20)) AS version, CAST(SERVERPROPERTY('ProductUpdateLevel') AS nvarchar(10)) AS cu, CAST(SERVERPROPERTY('EngineEdition') AS int) AS engine_edition"

edition version cu engine_edition ---------------------------------------- -------------------- ---------- -------------- Enterprise Developer Edition (64-bit) 17.0.5015.4 CU9 3

An engine_edition of 3 is the Enterprise engine, which Developer edition runs.

SQL Server forces encryption, so even a client that asks only for optional encryption (-No) gets an encrypted session. Run:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -No -Q "SET NOCOUNT ON; SELECT encrypt_option, protocol_type, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID"

encrypt_option protocol_type auth_scheme ---------------------------------------- ---------------------------------------- ---------------------------------------- TRUE TSQL SQL

The certificate is this instance's own and is named after its hostname:

openssl x509 -in /etc/ssl/mssql/mssql.pem -noout -subject -enddate -ext subjectAltName -fingerprint -sha256

subject=CN = ip-172-31-90-118 notAfter=Oct 17 02:31:09 2036 GMT X509v3 Subject Alternative Name: DNS:ip-172-31-90-118, DNS:localhost, IP Address:127.0.0.1 sha256 Fingerprint=5F:95:10:E2:C3:BD:BC:04:59:42:15:CA:2A:03:23:52:32:D2:6F:43:D4:D7:79:43:FD:E1:7A:27:F4:65:45:5D

The same fingerprint is in /root/mssql-credentials.txt as TLS_CERT_SHA256.

To verify the server instead of trusting it blindly, copy /etc/ssl/mssql/mssql.pem (the public certificate, never mssql.key) to your client and add it to the client's trusted certificates. In tools that support it, you can pin the fingerprint instead. Because the certificate names localhost and 127.0.0.1, verification also works through the SSH tunnel in Step 8.

Create a database, write a row, read it back, and drop the database:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -W -Q "SET NOCOUNT ON; CREATE DATABASE demo; EXEC('USE demo; CREATE TABLE dbo.notes (id INT IDENTITY PRIMARY KEY, body NVARCHAR(200) NOT NULL); INSERT INTO dbo.notes (body) VALUES (N''hello from SQL Server 2025 Developer'');'); SELECT id, body FROM demo.dbo.notes; DROP DATABASE demo;"

id body -- ---- 1 hello from SQL Server 2025 Developer

For an application, create a dedicated login and database instead of using sa. Run the following in an interactive sqlcmd session (/opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C), and choose your own strong password:

CREATE DATABASE appdb; GO CREATE LOGIN appuser WITH PASSWORD = N'<a-strong-password>', CHECK_POLICY = ON; GO USE appdb; CREATE USER appuser FOR LOGIN appuser; ALTER ROLE db_owner ADD MEMBER appuser; GO

The safest way to use SQL Server Management Studio, Azure Data Studio, VS Code or an application on your workstation is an SSH tunnel. The tunnel keeps port 1433 closed to the network:

ssh -i <your-key.pem> -N -L 1433:127.0.0.1:1433 ubuntu@<public-ip>

Connect your client to 127.0.0.1,1433 with SQL Server authentication as sa and encryption set to Mandatory (or Strict). Either trust the server certificate or install mssql.pem as a trusted certificate (Step 6).

If applications on other hosts in your VPC must connect directly, open the listen address and restart SQL Server. Then allow TCP 1433 in the security group from those hosts' CIDRs only, never from 0.0.0.0/0:

sudo /opt/mssql/bin/mssql-conf unset network.ipaddress
sudo systemctl restart mssql-server

Encryption stays forced. The certificate names the instance's hostname, localhost and 127.0.0.1. Clients that connect by another name must trust the certificate or use a certificate that you issue for that name (mssql-conf set network.tlscert and network.tlskey, then restart).