CentOS Stream 9 Gui

Option A: Azure portal

• Open the Azure Marketplace and search for "CentOS Stream 9 with GNOME Desktop SecureAnyCloud".
• Select the image and choose Create.
• On the Basics tab, select your Subscription, and create or select a Resource group.
• Enter a Virtual machine name, and select your preferred Region.
• For Size, select Standard_B2ms or larger. Choose a size that supports Generation 1.
• Under Administrator account, select SSH public key and enter your key.
• Under Inbound port rules, allow SSH (port 22) only. Do not open any VNC port, because the desktop is reached through an SSH tunnel.
• Choose Review + create, then Create.

Option B: Azure CLI

Run this on your own workstation. Substitute your resource group, VM name and preferred region. Accept the Marketplace terms once per subscription, then create the machine:

az vm image terms accept --urn sac1647283583153:centos-stream-9-gui:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-centos-desktop \
  --image sac1647283583153:centos-stream-9-gui:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Run these on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-centos-desktop --show-details --query publicIps -o tsv ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks for one, your client is not offering the key that you supplied at create time.

Check that the machine runs CentOS Stream 9 and boots to the graphical target. Also check that the GNOME login screen (GDM) is running with Wayland disabled, and see which desktop and VNC packages are installed:

cat /etc/centos-release uname -srm systemctl get-default systemctl is-active gdm.service grep '^WaylandEnable' /etc/gdm/custom.conf rpm -q --qf '%{NAME} %{VERSION}\n' gdm gnome-shell mutter xorg-x11-server-Xorg tigervnc-server

Expected output:

CentOS Stream release 9 Linux 5.14.0-745.el9.x86_64 x86_64 graphical.target active WaylandEnable=False gdm 40.1 gnome-shell 40.10 mutter 40.9 xorg-x11-server-Xorg 1.20.11 tigervnc-server 1.16.2

CentOS Stream is continuously delivered, so it has no minor version number. /etc/centos-release always reads CentOS Stream release 9, and the kernel and package versions move forward as you update.

The desktop and TigerVNC come from the distribution's own repositories, not from a third-party repository:

dnf group list --installed 2>/dev/null | grep -i 'Server with GUI' || true
dnf repolist echo "packages installed: $(rpm -qa | wc -l)" df -h /

dnf repolist shows exactly appstream, baseos and extras-common. No EPEL repository is configured.

The machine boots through the legacy BIOS path. The operating system disk keeps its first megabyte free for Azure, with the boot loader in a dedicated BIOS boot partition. The Azure Linux Agent names the operating system disk /dev/disk/azure/root, which is safer than a /dev/sdX letter. On a Generation 1 machine, the operating system disk and the temporary resource disk can swap letters between boots.

test -d /sys/firmware/efi && echo "firmware: UEFI (Gen2)" || echo "firmware: legacy BIOS (Generation 1)"
sudo parted -s /dev/disk/azure/root print | grep -E '^Partition Table|bios_grub'

firmware: legacy BIOS (Generation 1) Partition Table: gpt 1 1049kB 2097kB 1049kB BIOS boot partition bios_grub

A new virtual machine has VNC switched off. The helper shows the full state in one command:

sudo sac-vnc status

Expected output on a new VM:

VNC policy: localhost only, security types tlsvnc,vncauth (/etc/tigervnc/vncserver-config-mandatory) xvnc.socket (unauthenticated mode): disabled / inactive VNC desktops configured: none listening on VNC ports 5900-5999: none users with a VNC password set: none (each user runs: vncpasswd)

The helper lives at /usr/local/sbin/sac-vnc. On CentOS Stream, sudo replaces your PATH with its own secure_path, which does not include /usr/local/sbin. The image therefore also ships /usr/sbin/sac-vnc as a symlink, so sudo sac-vnc works as written. Its subcommands are status, enable [<user>], disable [<user>] and details. The <user> argument defaults to your administrator account.

Confirm the policy and the network side as well:

grep -vE '^#|^$' /etc/tigervnc/vncserver-config-mandatory
sudo ss -tln | awk '$1=="LISTEN"{print $4}' | sort

localhost securitytypes=tlsvnc,vncauth 0.0.0.0:22 [::]:22

SSH on port 22 is the only service listening.

First, set your account password. Run the following command yourself on the VM, and enter the new password twice when prompted:

sudo passwd azureuser

Then set your VNC password. Run vncpasswd as yourself, without sudo. Enter the password twice, and answer n to the view-only question:

vncpasswd

Password: Verify: Would you like to enter a view-only password (y/n)? n A view-only password is not used

Only the first 8 characters of a VNC password are used, and vncpasswd stores it in ~/.config/tigervnc/passwd with mode 0600. Your SSH access is unaffected, because SSH remains key-only.

sudo sac-vnc enable

Expected output:

VNC desktop for azureuser enabled on display :1: listening on localhost port 5901 only from your own machine: ssh -N -L 5901:localhost:5901 azureuser@<vm-ip> then point a VNC viewer at localhost:5901 and enter azureuser's VNC password

The helper adds :1=azureuser to /etc/tigervnc/vncserver.users and runs systemctl enable --now vncserver@:1.service. It then waits until port 5901 is listening, and it refuses and stops the desktop again if the port is bound anywhere other than localhost. The desktop starts again after a reboot.

If a password is missing, the helper refuses and tells you which one:

refusing to start a VNC desktop for azureuser: the account has no password yet. The GNOME lock screen and administrator prompts inside the desktop ask for it. Set it first:
sudo passwd azureuser

refusing to start a VNC desktop for azureuser: no VNC password is set. As azureuser (without sudo) run: vncpasswd

On your own workstation, open the tunnel and leave it running:

ssh -N -L 5901:localhost:5901 azureuser@<vm-ip>

Azure drops a TCP connection that has carried no traffic for about four minutes, and an idle SSH tunnel looks exactly like that. The ssh process keeps running, but the forward silently stops working. On this image, a tunnel opened without keepalives stopped forwarding after 270 seconds idle. The same tunnel with -o ServerAliveInterval=60 still authenticated after 280 seconds idle. If you leave the tunnel open between sessions, add the keepalive:

ssh -N -o ServerAliveInterval=60 -L 5901:localhost:5901 azureuser@<vm-ip>

Then point your VNC viewer at localhost:5901. TigerVNC and RealVNC accept localhost:5901, and some viewers want the display form localhost:1. On macOS, open Screen Sharing and connect to vnc://localhost:5901. Enter your VNC password, and your GNOME desktop opens.

TigerVNC Viewer marks the password dialog "This connection is not secure". It does so because the server has no certificate for the viewer to verify, since TigerVNC's TLSVnc security type uses anonymous TLS. Through the SSH tunnel, the connection is encrypted and SSH authenticates the server. That is why the image allows VNC only over the tunnel.

GNOME opens in the Activities overview. Press Escape to reach the desktop, or press the Super key to return to the overview. The top-right system menu offers Restart, Power Off and Log Out. Suspend is absent by design, because a suspended Azure virtual machine stops answering while Azure still reports it as running:

The application grid holds the applications that come with the Server with GUI group:

A terminal inside the session behaves exactly as your SSH session does, and your administrator account keeps its sudo rights. The session type is X11, and the VNC server listens on the loopback addresses only:

To add software, use dnf as on any CentOS Stream machine, for example sudo dnf install -y libreoffice. Then open the application from the grid.

Closing your VNC viewer leaves the session running on the VM. Connect again to return to it.

Each user gets their own display and port. Create the user with a password, have them run vncpasswd, and then enable their desktop. The helper assigns the next free display (:2 is port 5902):

sudo useradd -m alice
sudo passwd alice
sudo -u alice -H vncpasswd
sudo sac-vnc enable alice

After her SSH key is in place, Alice tunnels her own port, for example with ssh -N -L 5902:localhost:5902 alice@<vm-ip>.

sudo sac-vnc disable

VNC desktop for azureuser disabled: display :1 removed, nothing listening on port 5901

This command stops the session, disables vncserver@:1.service and removes the mapping, so nothing listens after a reboot. sudo sac-vnc status shows the state at any time.

Confirm that SELinux is enforcing, that SSH is key-only, that no account has a password until you set one, and that guest sleep is disabled:

getenforce
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication) '
sudo passwd -S root | awk '{print $1, $2}'
sudo awk -F: '$2 !~ /^[!*]/ && $2 != "" {n++} END {print "accounts with a password: " n+0}' /etc/shadow busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager CanSuspend

This is the expected output on a new VM. After Step 5, the password count reads 1, which is your own account:

Enforcing passwordauthentication no kbdinteractiveauthentication no root LK accounts with a password: 0 s "na"

LK means that the root account is locked, and na means that logind will not suspend the machine. Drop-in files pin both the sleep policy and the SSH policy, so a later package update to the main configuration cannot quietly loosen them:

grep -vE '^#|^$' /etc/systemd/sleep.conf.d/20-sac-no-guest-sleep.conf
grep -vE '^#' /etc/ssh/sshd_config.d/60-sac-hardening.conf

[Sleep] AllowSuspend=no AllowHibernation=no AllowSuspendThenHibernate=no AllowHybridSleep=no PermitRootLogin prohibit-password PasswordAuthentication no KbdInteractiveAuthentication no ChallengeResponseAuthentication no

Every available update was applied when this image was built. dnf-automatic is armed, so the machine downloads and applies updates on its own schedule:

systemctl is-enabled dnf-automatic.timer grep -E '^(upgrade_type|download_updates|apply_updates) ' /etc/dnf/automatic.conf

Expected output:

enabled upgrade_type = default download_updates = yes apply_updates = yes

Why the image applies all updates and not only security updates. CentOS Stream publishes no security advisory metadata. Its repositories carry no updateinfo data, so a security-only selection has nothing to select.

SecureAnyCloud verified this during the image build. With one package update pending, dnf upgrade --security and dnf-automatic set to upgrade_type = security both reported "No security updates needed, but 1 update available" and installed nothing. With upgrade_type = default, the update was installed. On CentOS Stream, the only way to keep a machine patched unattended is to apply every update, and this image does so.

If you prefer to review updates yourself, set apply_updates = no in /etc/dnf/automatic.conf. To opt out entirely, run sudo systemctl disable --now dnf-automatic.timer.

Check whether anything is pending at any time. The advisory count is always zero on CentOS Stream, so the check-update exit code is the result that matters:

dnf -q check-update >/dev/null 2>&1; echo "check-update exit=$? (0 = nothing pending, 100 = updates available)" echo "advisories published for this release: $(dnf -q updateinfo list --all 2>/dev/null | wc -l)"

check-update exit=0 (0 = nothing pending, 100 = updates available) advisories published for this release: 0

Automatic updates never restart the machine for you. After a kernel update, check whether a restart is owed, and pick your own maintenance window:

dnf needs-restarting -r || true

You can always update on your own schedule with sudo dnf -y upgrade, and reboot if a new kernel was installed.

GNOME Software may show "Software Updates Ready to Install" on your first login even when dnf reports nothing pending. That notification comes from the firmware updater (fwupd), not from a package. It can offer firmware variable updates published through the Linux Vendor Firmware Service. It is not an operating system package and is not part of this image, and you decide whether to apply a firmware update to your virtual machine. fwupdmgr get-updates shows exactly what it offers.

The Azure Network Security Group is the enforced firewall for this image. You do not need to open any port for the desktop, because it travels inside SSH.

The Server with GUI group brings several daemons that a cloud server does not need, and the base image had rpcbind listening. These services are left installed but disabled, never masked, so the image exposes only port 22 and you can turn any of them back on with a single command:

for u in cockpit.socket avahi-daemon.service cups.service bluetooth.service firewalld.service rpcbind.socket xvnc.socket; do echo "$u: $(systemctl is-enabled "$u" 2>/dev/null || true)" done

cockpit.socket: disabled avahi-daemon.service: disabled cups.service: disabled bluetooth.service: disabled firewalld.service: disabled rpcbind.socket: disabled xvnc.socket: disabled

To enable any of them, for example the Cockpit web console, run sudo systemctl enable --now cockpit.socket and open the port in your Network Security Group. Do not enable xvnc.socket, because it serves a login screen over VNC on port 5900 with no VNC password (-SecurityTypes=None).

firewalld is installed but switched off, so your NSG rules take effect exactly as written. If your policy requires a host firewall, enable it yourself and allow SSH through it:

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload

The VNC desktop needs no firewalld rule, because the tunnel arrives over SSH. The network stack is NetworkManager, configured by cloud-init exactly as on CentOS Stream 9 Server.