AlmaLinux 9 Gui
Overview
AlmaLinux is a community-owned enterprise Linux distribution, produced by the AlmaLinux OS Foundation to be binary compatible with Red Hat Enterprise Linux. This image is genuine stable AlmaLinux 9 with the distribution's own desktop added: the AppStream environment group @graphical-server-environment, which AlmaLinux calls Server with GUI. This guide covers deploying and configuring it on Microsoft Azure from SecureAnyCloud's preconfigured virtual machine image in the Azure Marketplace.
You reach the desktop with any VNC viewer through TigerVNC, the VNC server AlmaLinux ships in its own AppStream repository. Each user gets their own full GNOME session running on the virtual machine.
A freshly deployed machine exposes nothing but SSH. VNC ships switched off, no account has a password, and no VNC password exists anywhere in the image. When you turn VNC on, the server listens on localhost only, so you reach it through an SSH tunnel rather than over the internet.
What you get:
- AlmaLinux 9.8 ("Olive Jaguar") on the 5.14 kernel, binary compatible with RHEL 9, with every available update applied at build time
- The GNOME desktop from the AlmaLinux AppStream repository: GNOME Shell 40.10, the GDM 40 login screen and mutter 40.9
- Desktop applications from the same group, including Files (Nautilus), Terminal, Firefox, Text Editor, Calculator, System Monitor, Disks, Logs and Software
- TigerVNC 1.15 (
tigervnc-server), configured for per-user desktops on localhost only, with every offered security type requiring the VNC password sac-vnc, a small helper that shows the VNC state and starts or stops a user's desktop in one command- Guest sleep disabled, so the desktop never offers a Suspend that would leave an Azure virtual machine unreachable
dnf-automaticarmed for security updates, so the machine keeps patching itself- SELinux in enforcing mode and the Azure provisioning path unchanged (cloud-init, the Azure Linux Agent, NetworkManager)
- Gen2 Hyper-V virtual machine support
- 24/7 SecureAnyCloud support
- Platform: Microsoft Azure (Gen2 Hyper-V, x64)
- Default user:
azureuser
The image carries around 1,170 packages and uses about 5 GiB of the 30 GiB operating system disk, leaving the rest for your own software and data.
Why VNC, and how it is locked down
The remote desktop options in AlmaLinux 9 itself are limited. GNOME Remote Desktop on this release only shares a session that someone is already logged into at the machine, so it cannot give you a remote login on a cloud server. xrdp is available only from EPEL, a third-party repository this image does not use. TigerVNC is the first-party way to run headless GNOME desktops on AlmaLinux 9, and it is what Red Hat documents for RHEL 9.
VNC's own password protocol is old: it uses only the first 8 characters of the password. That is why this image never exposes VNC to the network.
The policy file /etc/tigervnc/vncserver-config-mandatory forces two settings for every user. TigerVNC loads the file after each user's own configuration, so a user's settings cannot undo it:
localhostmakes the VNC server listen on127.0.0.1and::1only. You connect through an SSH tunnel, which is encrypted and authenticated with your SSH key.securitytypes=tlsvnc,vncauthoffers only security types that require the VNC password.None(no password) is never offered.
GDM runs with Wayland disabled (WaylandEnable=False in /etc/gdm/custom.conf), which RHEL 9 requires for TigerVNC desktops. Sessions are therefore X11.
The two passwords, and which one goes where
Neither password exists until you create it, and both belong to you:
- Your VNC password. You set it by running
vncpasswdas your own user, withoutsudo. It is stored at~/.config/tigervnc/passwd, readable only by you. Your VNC viewer asks for it when it connects. Only the first 8 characters count. - Your account password. You set it with
sudo passwd <your-user>. The VNC session logs you straight into GNOME, but the desktop still asks for this password when the screen locks and when an application needs administrator rights. The image ships with no account password at all.
SSH stays key-only throughout. Setting either password does not enable password logins over SSH.
Security posture
This image ships with no known credential:
- No account has a password. The root account is locked, and your administrator account is created at first boot with only the SSH key you supply.
- SSH is key-only (
PasswordAuthentication no). - No VNC password exists for any account. No VNC desktop is configured, the unauthenticated inetd mode
xvnc.socketis disabled, and a new virtual machine listens on SSH port 22 only. Port 22 is the only port the listing advertises. - When VNC is on, it listens on localhost only, and every offered security type requires the VNC password.
- The helper refuses to start a desktop for a user who has no account password or no VNC password.
- Guest sleep is disabled, so the desktop menu offers Restart, Power Off and Log Out but never Suspend.
- SSH host keys are removed before capture and regenerated on each machine at first boot.
/etc/machine-idis also regenerated per machine, so no two machines share a host identity. Firmware update tooling generates its own client key per machine as well. - SELinux is left in enforcing mode, the AlmaLinux default, and GDM automatic login is not enabled.
Known issue: TigerVNC and CVE-2025-49177
CVE-2025-49177 is not fixed in the TigerVNC package on AlmaLinux 9, and Red Hat has said it will not fix it on RHEL 9. Checked on 16 September 2026:
- Red Hat (Security Data API for CVE-2025-49177) lists
tigervncon Red Hat Enterprise Linux 9 as "Will not fix", severity Important, CVSS 3.1 score 6.1 with vectorAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L, which is a local attack vector. Red Hat describes it as: "A flaw was found in the XFIXES extension. The XFixesSetClientDisconnectMode handler does not validate the request length, allowing a client to read unintended memory from previous requests." On mitigation Red Hat says: "Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria". - AlmaLinux has published no AlmaLinux 9 advisory that fixes it. The AlmaLinux 9 TigerVNC advisory for that group of X server flaws, ALSA-2025:9306 "Important: tigervnc security update", lists CVE-2025-49175, CVE-2025-49176, CVE-2025-49178, CVE-2025-49179 and CVE-2025-49180, and not CVE-2025-49177. The newest TigerVNC advisory, ALSA-2026:29844, which ships the
tigervnc-server-1.15.0-7.el9_8.2in this image, does not list it either.
SecureAnyCloud measured the following on this image. These are recorded as facts, not as a claim that you are unaffected:
- The Xvnc server reports the X.Org 1.20.11 code base and negotiates XFIXES protocol version 5.0, and the XFixesSetClientDisconnectMode request belongs to XFIXES version 6.
- Xvnc runs as the desktop's own user and accepts X clients only through its local socket and that user's X authority cookie, with no X11 TCP port.
- VNC is off until you enable it.
If your security policy does not accept an unfixed vendor CVE, do not enable VNC on this image. If AlmaLinux publishes a fixed package, dnf-automatic applies it automatically.
Prerequisites
Before you deploy this image, make sure you have:
- An active Microsoft Azure subscription
- Access to the Azure Portal or the Azure CLI
- An SSH key pair for Linux VM access
- A VNC viewer, such as TigerVNC Viewer (Windows, macOS, Linux), RealVNC Viewer, Remmina on Linux, or the built-in Screen Sharing app on macOS
Recommended VM size: Standard_B2ms (2 vCPU, 8 GB RAM) or larger.
The login screen plus one idle GNOME VNC session uses about 1.5 GiB of memory on this image. That fits in the 4 GB of Standard_B2s for light use, but a browser and a few applications quickly need the extra room. There is no GPU requirement, because the desktop renders in software.
Deploy the virtual machine
Option A: Azure Portal
- Open the Azure Marketplace and search for "AlmaLinux 9 with GNOME Desktop SecureAnyCloud".
- Select the image and click Create.
- On the Basics tab, configure the following fields.
- Subscription: select your Azure subscription.
- Resource Group: create a new group or select an existing one.
- Virtual Machine Name: enter a name for your VM.
- Region: select your preferred Azure region.
- Size:
Standard_B2msor larger. - 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 you reach the desktop through an SSH tunnel.
- Click Review + Create, then click Create.
Option B: Azure CLI
Run the commands below 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:almalinux-9-gui:default:latest
az vm create \
--resource-group myResourceGroup \
--name my-almalinux-desktop \
--image sac1647283583153:almalinux-9-gui:default:latest \
--size Standard_B2ms \
--admin-username azureuser \
--generate-ssh-keys \
--public-ip-sku StandardConnect via SSH
Run these commands on your own workstation, not on the VM. Find the public IP address, then connect:
az vm show --resource-group myResourceGroup --name my-almalinux-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 you supplied at create time.
Confirm the release and the desktop
Check that the machine is AlmaLinux 9 and boots to the graphical target. Check that the GNOME login screen (GDM) is running with Wayland disabled, and see which desktop and VNC packages are installed:
cat /etc/almalinux-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-serverExpected output:
AlmaLinux release 9.8 (Olive Jaguar) Linux 5.14.0-687.46.1.el9_8.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.15.0The 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. No EPEL repository is configured.
Check that VNC is off
A new virtual machine has VNC switched off. The helper shows the whole picture in one command:
sudo sac-vnc statusExpected 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 AlmaLinux, 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.
The helper's 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}' | sortlocalhost securitytypes=tlsvnc,vncauth 0.0.0.0:22 [::]:22SSH on port 22 is the only service listening.
Set your two passwords
First, set your account password. Run the command below yourself on the VM and enter the new password twice when prompted:
sudo passwd azureuserThen set your VNC password. Run vncpasswd as yourself, without sudo. Enter the password twice, then answer n to the view-only question:
vncpasswdPassword: Verify: Would you like to enter a view-only password (y/n)? n A view-only password is not usedOnly 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, and SSH remains key-only.
Start your VNC desktop
sudo sac-vnc enableExpected 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 passwordThe helper adds :1=azureuser to /etc/tigervnc/vncserver.users and runs systemctl enable --now vncserver@:1.service. It waits until port 5901 is listening. 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 azureuserrefusing to start a VNC desktop for azureuser: no VNC password is set. As azureuser (without sudo) run: vncpasswdConnect through an SSH tunnel
On your own workstation, open the tunnel and leave it running:
ssh -N -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: TigerVNC's TLSVnc security type uses anonymous TLS. Through the SSH tunnel, the connection is encrypted and SSH authenticates the server. This is why the image allows VNC only over the tunnel.
Use the desktop
GNOME opens in the Activities overview. Press Escape for the desktop, or the Super key to return to the overview.
The system menu at the top right offers Restart, Power Off and Log Out. Suspend is deliberately absent, 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 is listening on the loopback addresses only:
To add software, use dnf as on any AlmaLinux 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.
Desktops for more users
Each user gets their own display and port. Create the user with a password, have them run vncpasswd, then enable their desktop. The helper assigns the next free display, where :2 is port 5902:
sudo useradd -m alice
sudo passwd alice
sudo -u alice -H vncpasswd
sudo sac-vnc enable aliceOnce her SSH key is in place, Alice tunnels her own port, for example ssh -N -L 5902:localhost:5902 alice@<vm-ip>.
Turn VNC off again
sudo sac-vnc disableVNC desktop for azureuser disabled: display :1 removed, nothing listening on port 5901This stops the session, disables vncserver@:1.service and removes the mapping, so nothing listens after a reboot. Run sudo sac-vnc status at any time to see the state.
Verify the security posture
Confirm that SELinux is enforcing, SSH is key-only, no account has a password until you set one, and 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 CanSuspendExpected output on a new VM (after Step 5 the password count reads 1, your own account):
Enforcing passwordauthentication no kbdinteractiveauthentication no root LK accounts with a password: 0 s "na"LK means the root account is locked, and na means 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 noPatching and updates
Every available update was applied when this image was built. dnf-automatic is armed, so the machine applies security updates on its own schedule:
systemctl is-enabled dnf-automatic.timer grep -E '^(upgrade_type|download_updates|apply_updates) ' /etc/dnf/automatic.confExpected output:
enabled upgrade_type = security download_updates = yes apply_updates = yesYou can check two views of what is pending at any time: whether any package update is available, and whether any security advisory applies to an installed package:
dnf -q check-update >/dev/null 2>&1; echo "check-update exit=$? (0 = nothing pending, 100 = updates available)" echo "pending security advisories: $(dnf -q updateinfo list --security --available 2>/dev/null | wc -l)"Automatic updates never restart the machine. After a kernel update, check whether a restart is owed and pick your own window:
dnf needs-restarting -r || trueYou can always update on your own schedule with sudo dnf -y upgrade, and reboot if a new kernel was installed. To opt out of automatic updates entirely, run sudo systemctl disable --now dnf-automatic.timer.
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. On Azure, it offers Microsoft's UEFI Secure Boot revocation list (the "dbx") update, published through the Linux Vendor Firmware Service.
It is not an operating system package, and it is not part of this image. Whether to apply a firmware variable update to your virtual machine is your decision. Run fwupdmgr get-updates to see exactly what it offers.
Networking, the firewall, and services that ship switched off
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. The image therefore exposes only port 22, and you can turn any of the services 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)" donecockpit.socket: disabled avahi-daemon.service: disabled cups.service: disabled bluetooth.service: disabled firewalld.service: disabled rpcbind.socket: disabled xvnc.socket: disabledTo enable one 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. It serves a login screen over VNC on port 5900 with no VNC password (-SecurityTypes=None).
firewalld is installed but switched off, consistent with the rest of the SecureAnyCloud AlmaLinux family, 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 --reloadThe VNC desktop needs no firewalld rule, because the tunnel arrives over SSH. The network stack is NetworkManager, configured by cloud-init exactly as on AlmaLinux Server.
Verify what you are running
Three commands answer the three questions that matter: which release this is, whether it is a desktop image, and whether VNC is currently on.
cat /etc/almalinux-release systemctl get-default
sudo sac-vnc statusCommon use cases
- A cloud workstation for enterprise Linux development with a full GNOME desktop, reached through an SSH tunnel
- Running graphical administration and data tools close to your Azure resources
- A RHEL 9 compatible desktop for testing applications certified against RHEL, without a subscription
- Training labs and demonstrations that need a desktop rather than a shell, one desktop per user
- A secure jump desktop that exposes nothing but SSH
Troubleshooting
"Connection refused" on localhost:5901
VNC is off on a fresh VM by design. Run sudo sac-vnc enable first, check the SSH tunnel is still running in its own terminal window, and check the port matches your display (:1 is 5901, :2 is 5902). sudo sac-vnc status shows what is listening.
The viewer says "Authentication failure"
The viewer wants your VNC password, the one you set with vncpasswd, not your account password. Only its first 8 characters count. Set it again with vncpasswd and reconnect; the running desktop does not need restarting.
Connecting directly to the VM's public IP on port 5901 does not work
That is the security design: the VNC server listens on localhost only. Use the SSH tunnel from Step 7. The localhost setting in /etc/tigervnc/vncserver-config-mandatory also overrides any interface or localhost setting in a user's own ~/.config/tigervnc/config.
The screen is locked and asks for a password
The lock screen wants your account password from sudo passwd <your-user>. If you never set one, the helper would not have started the desktop; if you removed it afterwards, set it again over SSH.
A desktop you start again can also open straight at the lock screen. GNOME remembers, per display, that the previous desktop on that display was locked when it stopped (for example after it locked while idle), and it keeps that promise for the next desktop on the same display while you are still logged in over SSH. Click or press a key and enter your account password.
The desktop does not start for a user
journalctl -u vncserver@:1 shows the service, and the session log is in the user's ~/.local/state/tigervnc/. TigerVNC cannot start a VNC desktop for a user who is already logged into another graphical session on the same machine, so log that session out first.
"This connection is not secure" in TigerVNC Viewer
Expected, and explained in Step 7: the server has no certificate, and the SSH tunnel provides the encryption and server authentication.
Cannot connect via SSH
- Verify the VM is in Running state in the Azure Portal
- Check that port 22 is allowed in the Network Security Group
- Ensure you are using the administrator username you named at create time
- Verify your SSH key matches the one you supplied at create time. Password login over SSH is disabled by design.
A service is blocked and the logs mention SELinux
SELinux is enforcing, which is the secure default and should stay that way. Denials are recorded in the audit log, so look there rather than in the journal:
sudo ausearch -m AVC -ts recent </dev/null 2>/dev/null || echo "no recent AVC denials"Most denials on a fresh machine come from software installed into a non standard path. Relabel with sudo restorecon -Rv /path before considering any policy change. vncpasswd already creates ~/.config/tigervnc with the correct vnc_home_t label.
Important Notes
AlmaLinux is free and open source, but it is not covered by a single licence: the distribution is a collection of thousands of independently packaged components, each carrying its own terms, predominantly GPL and LGPL, with MIT, BSD, Apache 2.0, MPL and others. The GNOME desktop, GDM and TigerVNC are free software packaged in the AlmaLinux AppStream repository. Every package's terms are readable on the machine with rpm -qi <package> and under /usr/share/licenses/. No subscription, entitlement or licence key is required to run this image, and no Red Hat subscription is involved.
AlmaLinux 9 is not an end of life product. It reached general availability on 26 May 2022, active support runs until 31 May 2027 and security support until 31 May 2032. Check the AlmaLinux release notes for the dates that apply to your deployment.
AlmaLinux is a mark of the AlmaLinux OS Foundation and GNOME is a trademark of the GNOME Foundation. Both names are used here nominatively, only to identify the distribution and the desktop environment this image contains. SecureAnyCloud is not affiliated with, endorsed by or sponsored by the AlmaLinux OS Foundation or the GNOME Foundation.
Support
For assistance with this image, contact SecureAnyCloud support:
- Website: secureanycloud.com
- Product Catalogue: secureanycloud.com/products
- User Guides: secureanycloud.com/guides
- SLA: 24 hour response guaranteed
Deploy on Azure
Launch AlmaLinux 9 with GNOME Desktop on Azure with 24/7 support from SecureAnyCloud.
View this image
Need Help?
Our support team is available 24/7.
sales@secureanycloud.com