Debian 13 with KDE Plasma Desktop on AWS User Guide

Overview

This image is Debian 13 "trixie" with the KDE Plasma desktop, one software version of the cloudimg Hardened Debian & Linux Desktops AMIs listing on AWS Marketplace. Every desktop in the listing is described at /guides/linux-desktop-aws/.

It is the official Debian 13 AMI with Debian's own KDE Plasma 6.3 desktop added (the task-kde-desktop selection Debian's installer uses), the SDDM display manager, and xrdp 0.10 set up as the remote desktop server: you connect with any RDP client, sign in at the xrdp login box with your own account name and password, and get a full Plasma session running on the instance. Debian 13 was released on 9 August 2025 and has security support from the Debian Security Team followed by Debian LTS, to 30 June 2030.

Remote desktop ships switched off, and no account has a password. xrdp signs you in with your ordinary Linux account password, so there is exactly one password and it is yours: you set it over SSH, then turn remote desktop on with one command. The recommended route is an SSH tunnel, so port 3389 never has to be open to the internet.

How Plasma runs over RDP. Plasma 6 starts a Wayland session by default at a local screen, but an RDP server needs an X11 session to draw into. Debian 13 still ships Plasma's X11 session, Plasma (X11), with its X11 window manager kwin_x11, and that is the session every remote desktop connection to this image starts. Every build signs in over RDP with a real client and checks that a Plasma X11 session starts and stays up.

What cloudimg does to the image:

• The KDE Plasma 6.3 desktop from Debian's main archive: Dolphin file manager, Konsole terminal, Kate text editor, System Settings, System Monitor and KWalletManager, with the SDDM display manager. Every package the image adds comes from Debian 13's own main archive (trixie, trixie-security and trixie-updates), the same archive and the same security update stream as the rest of the operating system. Nothing is rebuilt and there are no third-party repositories.
• Installed without the extras that open network listeners or carry identity: no NetworkManager, Avahi, print server, Bluetooth, Discover software centre, KDE Connect, power management, web browser or office suite, and no remote access server other than xrdp (no KRdp, KRFB or VNC server).
• xrdp, off until you enable it, hardened. At first boot each instance generates its own self-signed TLS certificate and its own xrdp RSA key, readable by root (and the xrdp service) only. Nothing is shared between two instances and nothing is baked into the image. xrdp accepts TLS only (TLS 1.2 and 1.3), offers only the local Xorg session (the VNC and RDP-forwarding modules that would let the login box open connections to other hosts are removed), refuses root logins and has RDP audio switched off. The session manager talks to xrdp over a local UNIX socket, so it adds no network port. cloudimg-remote-desktop enable refuses to start until an administrator account has a password, so an RDP login box is never exposed with nothing behind it.
• xrdp at 0.10.1-3.1+deb13u2 or later, the Debian security release that fixes CVE-2025-68670.
• A login screen on EC2. Debian's cloud kernel has no graphics driver, so an EC2 instance booted with it has no display device and SDDM cannot start. This image boots Debian's standard kernel (linux-image-amd64, the same security stream) and binds EC2's virtual VGA adapter to the in-kernel bochs display driver, so SDDM's login screen runs as on any Debian desktop.
• Remediated with the OpenSCAP CIS Level 1 Server profile. The build applies the SCAP Security Guide 0.1.82 profile cis_level1_server with oscap --remediate after the desktop is installed, then reboots and runs a scored evaluation; the build fails if fewer than 95% of the scored rules pass. The report ships in the image at /usr/share/doc/cloudimg/cis-l1-report.html. This is a measurement made by open-source tooling, not a certification or accreditation by the benchmark's publisher or any other body, and these images are not CIS Hardened Images.
• Fully patched at build time, with automatic security updates left on (unattended-upgrades).
• Key-only SSH as admin. Password login over SSH is off and stays off when you set a desktop password; root login is refused and the root account is locked.
• IMDSv2 only, the ufw host firewall (inbound SSH only), LLMNR and in-guest sleep switched off, chrony on the Amazon Time Sync Service and the AWS Systems Manager agent.

Printing is not included. The CUPS print server is not installed and is pinned out of apt. Plasma's own packages depend on the CUPS and Qt print client libraries, so those libraries are present, but nothing runs or listens for printing.

Connecting to your instance

Connect over SSH as the default login user for the operating system variant you launched:

Operating system variant	SSH login user
Debian 13 with KDE Plasma Desktop	admin

Launch from AWS Marketplace

1. Open the listing on AWS Marketplace and choose View purchase options, then Subscribe. One subscription covers every version in the listing.
2. Once the subscription is active, choose Launch your software.
3. Choose Launch from EC2 Console (or One-click launch), then in Version choose Debian 13 with KDE Plasma Desktop - YYYY-MM-DD HH:MM and your Region.
4. Instance type: m5.large (2 vCPU, 8 GiB) is recommended. Plasma is a full desktop and renders in software (there is no GPU requirement); pick m5.xlarge or larger for heavier desktop work.
5. Key pair: choose your EC2 key pair. It is the only way in.
6. Security group: allow inbound TCP 22 from your own IP address only. The listing's default security group also offers TCP 3389 for a direct RDP connection; restrict it to your own address too, or remove it and use the SSH tunnel (Step 5).
7. Storage: the root volume is 16 GiB gp3 by default. Choose a larger size if you will install applications; cloud-init grows the root filesystem to fill it on first boot.
8. Leave the metadata settings at their defaults (the image requires IMDSv2), then choose Launch.

Step 1: Connect over SSH and check the desktop

ssh -i ~/.ssh/my-key.pem admin@<public-ip>

admin has passwordless sudo. There is no password on any account. Confirm the release, that the instance booted to the graphical target with the SDDM display manager running, and the installed desktop and remote desktop packages:

grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
cat /etc/debian_version
systemctl get-default
systemctl is-active sddm
dpkg-query -W -f='${Package} ${Version}\n' task-kde-desktop plasma-workspace kwin-x11 sddm xrdp xorgxrdp

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
VERSION_ID="13"
13.7
graphical.target
active
kwin-x11 4:6.3.6-1
plasma-workspace 4:6.3.6-2
sddm 0.21.0+git20250502.4fe234b-2
task-kde-desktop 3.81
xorgxrdp 1:0.10.2-1
xrdp 0.10.1-3.1+deb13u2

Step 2: Check that remote desktop is off

A new instance has remote desktop switched off. The helper shows the whole picture:

sudo cloudimg-remote-desktop status
sudo ss -tlnH | awk '{print $4}' | sort

Expected output (the certificate fingerprint is unique to your instance):

remote desktop service: disabled / inactive
session manager: disabled / inactive
listening on 3389: no
per-instance TLS certificate: generated (/etc/xrdp/cert.pem)
TLS certificate SHA-256: D7:F6:3D:60:4D:0A:33:08:08:D1:81:0E:98:F1:39:68:B3:56:B5:36:2C:A3:74:FD:0F:18:54:81:A0:33:E1:17
accounts able to log in at the KDE Plasma remote desktop: none (set one with: sudo passwd <user>)
0.0.0.0:22
127.0.0.1:25
127.0.0.53%lo:53
127.0.0.54:53
[::1]:25
[::]:22

The only listener reachable from outside the instance is SSH on port 22. The other entries are the local DNS resolver and the local mail transfer agent (port 25, for system mail), bound to loopback addresses only.

Step 3: Set your password

The xrdp login box asks for your account password, and a new instance has none. Choose your own. Run this yourself on the instance and enter the new password twice when prompted:

sudo passwd admin

The image's password policy (part of the CIS Level 1 remediation) requires at least 14 characters with upper case, lower case, a digit and a symbol. SSH stays key only: the password works at the xrdp login box, to unlock the Plasma screen locker and for the EC2 serial console, and for nothing else over the network.

Step 4: Turn remote desktop on

sudo cloudimg-remote-desktop enable

Expected output:

remote desktop enabled: listening on port 3389
TLS certificate SHA-256: 89:4F:FC:0F:56:F7:49:27:E5:AF:C4:A7:51:6F:EB:23:E2:78:97:FD:27:50:73:7C:D3:3D:FF:02:19:79:A8:D4
sign in with your own account name and the password you set with sudo passwd
recommended route: ssh -N -L 3389:localhost:3389 <user>@<instance-ip>, then point your RDP client at localhost:3389

If no administrator account has a password yet, the helper refuses and tells you which command to run first. The setting survives reboots. Under the hood it enables and starts xrdp.service, which starts the session manager with it. Print your instance's connection details:

sudo cloudimg-remote-desktop credentials

The output lists RDP_USERNAME (admin), RDP_PORT and the certificate fingerprints. There is no separate remote desktop password: RDP_PASSWORD_SOURCE records that the password is your own account password.

Step 5: Connect with your RDP client

The recommended route keeps port 3389 closed and carries RDP inside your SSH connection (the host firewall already admits it, because the tunnel arrives on the loopback interface). On your workstation, open a tunnel and leave it running:

ssh -i ~/.ssh/my-key.pem -N -L 3389:localhost:3389 -o ServerAliveInterval=60 admin@<public-ip>

Then point your RDP client at localhost:3389:

• Windows: Remote Desktop Connection (mstsc) or Windows App, computer localhost:3389
• macOS: Windows App, add a PC with the name localhost:3389
• Linux: Remmina (RDP), server localhost:3389, or FreeRDP 3: xfreerdp3 /v:localhost:3389 /u:admin /gfx /bpp:32

On first connection the client shows the server's certificate: it is self signed and unique to your instance, so compare its fingerprint with RDP_TLS_SHA256 (or RDP_TLS_SHA1, which Windows shows as the thumbprint) before you accept it. If your client asks for credentials before connecting, you can enter admin and your password there and skip the login box.

The xrdp login box appears. The Session list has one entry, Xorg, which is the one you want. Enter admin and the password you set in Step 3:

The Plasma desktop appears. The first sign in to an account takes longer than later ones (up to a minute) while Plasma creates its settings:

Disconnecting your RDP client leaves the session running on the instance; connect again with the same account and you return to it. xrdp asks for your password again every time you connect, so a disconnected session is not left unprotected.

Direct connection instead of the tunnel. Allow TCP 3389 in the instance's security group from your own public address only, never from the whole internet, and admit the same address in the host firewall on the instance:

sudo ufw allow from <your-public-ip> to any port 3389 proto tcp

Step 6: Use the desktop

Click the application launcher at the bottom left of the panel to see what is installed:

Press Ctrl+Alt+T to open Konsole, the terminal (it is also in the launcher under System). admin keeps its passwordless sudo, so sudo works in the desktop exactly as it does over SSH:

To add software, use apt in Konsole as on any Debian machine, for example sudo apt install firefox-esr or sudo apt install libreoffice.

A few things to know about Plasma's defaults on this image:

• The panel's pinned icons are Plasma's stock set: System Settings, the Discover software centre, the file manager and the web browser. Discover is not installed (use apt), so its pin shows a blank icon and does nothing; right click it and choose Unpin from Task Manager. No web browser is installed either, so until you install one the web browser pin (and the first favourite in the launcher) opens Kate, the text editor, and shows its icon. Install a browser (for example sudo apt install firefox-esr) and the pin opens it instead.
• The screen locks after 5 minutes of inactivity, which is Plasma's default. Unlock it with your account password. To change the delay or turn it off, open System Settings and search for Screen Locking.
• There is no Sleep button. An EC2 instance must never put itself to sleep, so in-guest sleep is switched off. To stop paying for compute, stop the instance from EC2 instead.
• Resolution follows your RDP client. Resize the client window or set the display size in the client before connecting. Sound is not redirected (xrdp's audio channel is off).

Security posture

Confirm that SSH is key only (and forwards no X11: use the RDP desktop), root is locked, no account has a password until you set one, and the host firewall admits SSH only:

sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin|pubkeyauthentication|x11forwarding) '
sudo passwd -S root
sudo awk -F: '$2 !~ /^[!*]/ && $2 != "" {n++} END {print "accounts with a password: " n+0}' /etc/shadow
sudo ufw status | grep -E '^(Status|22/tcp |3389)' || true

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
x11forwarding no
root L 2026-11-03 0 99999 7 -1
accounts with a password: 0
Status: active
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)

After Step 3 the accounts with a password line reads 1 (your own account). L after root means the root password is locked. And confirm the xrdp hardening:

grep -E '^(security_layer|ssl_protocols|rdpsnd)=' /etc/xrdp/xrdp.ini
grep -E '^\[(Xorg|Xvnc|vnc-any|neutrinordp-any)\]' /etc/xrdp/xrdp.ini
grep -E '^AllowRootLogin=' /etc/xrdp/sesman.ini

security_layer=tls
ssl_protocols=TLSv1.2, TLSv1.3
rdpsnd=false
[Xorg]
AllowRootLogin=false

View the compliance report

The evaluation the build ran after its reboot is in /usr/share/doc/cloudimg/cis-l1-report.html (HTML), cis-l1-arf.xml (machine-readable ARF) and cis-l1-summary.json (counts, pass rate, threshold, SSG version and checksums) in the same directory. The build host's name and addresses are replaced in the shipped copy.

python3 -c "import json; d=json.load(open('/usr/share/doc/cloudimg/cis-l1-summary.json')); print(d['profileLabel'], d['ssgVersion'], '-', d['pass'], 'of', d['scored'], 'scored rules pass', '(' + str(d['ratePct']) + '%)', '- waived', d['waived'])"
python3 -c "import json; [print(r) for r in json.load(open('/usr/share/doc/cloudimg/cis-l1-summary.json'))['failingRules']]"

CIS Level 1 Server 0.1.82 - 359 of 364 scored rules pass (98.6%) - waived 6
file_groupownerships_var_log
file_ownerships_var_log
journald_forward_to_syslog
service_systemd-journal-upload_enabled
systemd_journal_upload_url

The 5 scored rules that do not pass are listed in the summary's failingRules; four fail and one (file_ownerships_var_log) reports error. Each is the result of a deliberate choice, and each stays in the score rather than being hidden:

• Log file ownership (file_ownerships_var_log, file_groupownerships_var_log). These checks accept only log files owned by root and a short list of groups. Three services on this image keep their own log files on purpose: Debian's daily AIDE check runs as _aide and rotates /var/log/aide/aide.log itself, xrdp writes /var/log/xrdp.log as its own xrdp account, and Debian's SDDM package creates /var/log/sddm.log for the sddm account and group (mode 0640 on this image). Handing those files to root would make the services fail to write their logs.
• journald forwarding (journald_forward_to_syslog). The profile selects both "forward the journal to syslog" and "do not forward the journal to syslog", so one of the pair always fails.
• Remote journal upload (service_systemd-journal-upload_enabled, systemd_journal_upload_url). The benchmark wants the journal sent to a remote log server. The image cannot know yours, and with no address the upload service would fail at every boot, so it is installed but disabled. To use it, set URL= to your collector in /etc/systemd/journal-upload.conf, then run sudo systemctl enable --now systemd-journal-upload.

The profile's GNOME login-screen rules do not apply to this image (it uses SDDM, not GNOME's display manager). The local display's X server writes its log to /run/sddm/Xorg.0.log rather than /var/log, because Xorg always creates that file world-readable.

Copy the HTML report to your workstation and open it in a browser:

scp -i ~/.ssh/my-key.pem admin@<public-ip>:/usr/share/doc/cloudimg/cis-l1-report.html .

Re-run the same evaluation on your instance at any time (nothing is changed). oscap exits with status 2 when any rule fails; the report is still written:

sudo oscap xccdf eval --tailoring-file /usr/share/doc/cloudimg/cis-l1-tailoring.xml \
  --profile xccdf_co.cloudimg_profile_cis-l1_ec2_single \
  --report ~/cis-l1-rescan.html /usr/share/xml/scap/ssg/content/ssg-debian13-ds.xml

Waived rules

These rules of the profile are deselected through the tailoring file /usr/share/doc/cloudimg/cis-l1-tailoring.xml and are not scored; the reasons are in /usr/share/doc/cloudimg/cis-l1-waivers.txt. Everything else the profile selects is remediated and scored.

Rule	Category	Why it is waived on EC2
partition_for_tmp	single-volume-partitions	The image boots from one EBS root volume, so /tmp, /var, /var/log, /var/log/audit, /var/tmp and /home live on the root filesystem.
grub2_password	serial-console-and-boot	A boot-loader or root password would have to be baked into the image, giving every instance the same credential. Root stays locked and no password exists.
grub2_uefi_password	serial-console-and-boot	As above, for the UEFI boot loader.
accounts_maximum_age_login_defs	key-only-account-aging	Password-age defaults apply to every account cloud-init creates at launch. Those accounts are key-only and have no password, so an age limit would expire them and lock the SSH key out. Accounts that do have a password (yours, after Step 3) are still aged.
account_disable_post_pw_expiration	key-only-account-aging	As above, for the inactivity default.
sshd_limit_user_access	ssh-access-list	An AllowUsers/AllowGroups list fixed at build time would refuse SSH to accounts you create with cloud-init user-data. SSH is key-only, root login is refused, and your security group restricts the source addresses.

Networking, LLMNR and sleep

The EC2 network interface is configured by cloud-init and systemd-networkd, exactly as on Debian's own AMI. The KDE package set on this image does not install NetworkManager, so no second network stack competes for your interface:

networkctl list --no-legend

  1 lo   loopback carrier  unmanaged
  2 ens5 ether    routable configured

Because NetworkManager is not installed, Plasma shows no network applet in the system tray; that is expected. If you want one, install NetworkManager and plasma-nm yourself and test the change from the EC2 serial console before you reboot.

LLMNR and multicast DNS are switched off in systemd-resolved, so the instance does not listen on ports 5355 or 5353. In-guest sleep is switched off as well: an instance that suspends itself stops answering SSH and RDP while EC2 still shows it as running, so every sleep mode is disabled and Plasma offers no Sleep button. Shut down and restart work normally. Check both:

resolvectl llmnr
busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager CanSuspend

Global: no
Link 2 (ens5): no
s "no"

Turn remote desktop off, or change your password

To switch remote desktop off again (the setting survives reboots):

sudo cloudimg-remote-desktop disable

To change the password the xrdp login box asks for, change your account password: they are the same thing.

sudo passwd admin

To use a certificate of your own instead of the generated one, write it to /etc/xrdp/cert.pem and its key to /etc/xrdp/key.pem (owner root, group xrdp, mode 0640) and run sudo systemctl restart xrdp.

Patching

unattended-upgrades installs security updates automatically, and the desktop, SDDM and xrdp are part of that, because they come from the same Debian archive. To see how many updates are waiting:

echo "pending upgrades: $(apt-get -s dist-upgrade 2>/dev/null | grep -c '^Inst ' || true)"

pending upgrades: 0

To install everything now: sudo apt-get update && sudo apt-get -y dist-upgrade, and reboot if /var/run/reboot-required exists. Kernel updates arrive through linux-image-amd64, Debian's standard kernel, which this image boots so the login screen has a display device.

Troubleshooting

The RDP client connects but the screen is black, or the session closes immediately

Check what the session manager recorded, on the instance:

sudo tail -n 30 /var/log/xrdp-sesman.log

A healthy sign in logs Access permitted for user: admin, then the start of an X server on display 10. If instead you see AUTHFAIL: user=admin, the password is wrong or the account has none yet: set it with sudo passwd admin over SSH and try again. The first sign in to a new account takes longer than later ones while Plasma creates its settings; give it up to a minute.

I connected a second time and was immediately disconnected

You get one Plasma desktop session per account. If you disconnect and reconnect later, xrdp returns you to the session you left, which is the normal path. A second connection while the first is still attached starts a second Plasma session for the same account, and Plasma does not support two desktop sessions for one user at the same time. To use two desktops at once, sign in as two different accounts (create one with sudo adduser <name> and give it a password). To abandon a session you can no longer reach, sign out from inside it, or end it from SSH with sudo pkill -u admin ksmserver, then connect again.

The client refuses the connection or reports a security negotiation error

This image accepts TLS only. Every current RDP client supports it; very old clients that only offer the legacy RDP security layer are refused. Update the client.

The login box does not accept my password

The username is your Linux account name (admin), not an email address. If the account has no password yet, set it with sudo passwd admin over SSH. After repeated failed attempts the account is locked for 15 minutes (part of the CIS Level 1 remediation); unlock it early with sudo faillock --user admin --reset.

I get "connection refused" on localhost:3389

The tunnel is not up, or remote desktop is still off. Check sudo cloudimg-remote-desktop status on the instance, and confirm your ssh -N -L 3389:localhost:3389 command is still running on your workstation.

The desktop feels slow

Plasma renders in software on an instance without a GPU. Move to a larger instance type such as m5.xlarge for heavier work, and use a smaller window or a lower colour depth in your RDP client. Desktop effects can be reduced in System Settings (search for Desktop Effects).

Cannot connect via SSH

1. Check that port 22 is allowed in the security group from your address.
2. Use the user admin and the key pair you chose at launch. Password login over SSH is disabled by design.

Emergency access

There is no password on any account until you set one. EC2 Serial Console and single-user recovery need a local password: the one you set in Step 3 works for the serial console. Session Manager (SSM) is the other way in if SSH is unavailable.

Support

cloudimg provides 24/7 technical support for this image by email and live chat: support@cloudimg.co.uk.

Debian is free and open source, assembled from thousands of independently packaged components each under its own licence (see /usr/share/doc/<package>/copyright). KDE Plasma and the KDE applications are free software, mostly under the GPL and LGPL; SDDM is under the GPL; xrdp and xorgxrdp are under the Apache License 2.0. No subscription or licence key is required. "Debian" is a trademark of Software in the Public Interest, Inc.; "KDE" and "Plasma" are trademarks of KDE e.V. CIS and CIS Benchmarks are trademarks of the Center for Internet Security, Inc. The names are used only to identify the software this image contains; cloudimg is not affiliated with or endorsed by the Debian Project, KDE e.V. or CIS.