Kali Linux Remote Desktop: Access GNOME from Windows Using Native RDP

 Kali Linux + GNOME 50 + GNOME Remote Desktop + Windows Remote Desktop (MSTSC)

Getting a full GNOME desktop remotely on Kali Linux can be confusing because there are several different technologies involved: GNOME, GDM3, Wayland, gnome-remote-desktop, RDP, and the user/system systemd services.

This guide documents a working Kali Linux setup where a Windows machine connects to Kali using the built-in Remote Desktop Connection (mstsc) and receives a full GNOME desktop session.

The important part is that this configuration uses GNOME Remote Login, rather than traditional xrdp.

---

What We Are Building

The final architecture looks like this:

┌─────────────────────────────┐
│       Windows 10/11         │
│                             │
│  Remote Desktop Connection  │
│          mstsc.exe          │
└──────────────┬──────────────┘
               │
               │ RDP / TCP 3389
               │
               ▼
┌─────────────────────────────┐
│          Kali Linux         │
│                             │
│           GDM3              │
│             │               │
│             ▼               │
│      GNOME Remote Desktop  │
│             │               │
│             ▼               │
│       GNOME Desktop         │
│       GNOME Shell 50.x      │
│                             │
│         Wayland             │
└─────────────────────────────┘

GNOME's Remote Login implementation integrates with GDM and provides remote login through RDP. GNOME documents this as the headless multi-user remote login mode.

---

Why GNOME Instead of Xfce?

Kali supports several desktop environments, including GNOME and Xfce. The Kali GNOME desktop is provided by the kali-desktop-gnome metapackage and includes components such as gdm3, gnome-session, and gnome-shell.

For this configuration, the goal was specifically:

Windows
   ↓
RDP
   ↓
Kali
   ↓
GNOME

Rather than:

Windows
   ↓
xrdp
   ↓
Xfce

Both approaches are possible, but they are different architectures.

GNOME Remote Desktop has native support for RDP and can integrate with GDM for remote login.

---

Step 1 — Check the Current Desktop

When connecting to Kali through SSH, these commands may initially show:

echo "Desktop: $XDG_CURRENT_DESKTOP"
echo "Session: $XDG_SESSION_TYPE"

Output:

Desktop:
Session: tty

This does not mean GNOME is missing.

It simply means the current SSH session is a TTY rather than a graphical GNOME session.

For example, GNOME Shell itself can still be installed:

gnome-shell --version

In this setup, the system reported:

GNOME Shell 50.4

So the important distinction is:

SSH session
    ↓
TTY

RDP session
    ↓
GNOME graphical session

Do not use the SSH environment variables alone to determine whether GNOME is installed.

---

Linux Recovery Tools & Options: The Complete Guide to Fixing a Broken Linux System

LINUX TROUBLESHOOTING • RESCUE • RECOVERY

Linux Recovery Tools
The Complete Guide

From GRUB and rescue mode to fsck, chroot, LUKS, LVM, SystemRescue, Rescuezilla, Clonezilla and GParted — learn how to recover a broken Linux system step by step.

Explore Recovery Options Rescue Toolkit

Linux recovery is a layered process. When Linux stops booting, don't immediately reinstall the operating system. First determine whether the problem is related to the bootloader, filesystem, kernel, initramfs, storage, configuration, permissions, encryption, or hardware.

One of the biggest advantages of Linux is that even when the graphical desktop is completely unavailable, you can often boot into a recovery environment and repair the installation from a terminal.

A good Linux administrator should therefore understand both built-in recovery mechanisms and external bootable rescue environments.

📚 Table of Contents

• Linux Recovery Options
• Understanding Linux Boot Problems
• GRUB Bootloader Recovery
• Recovery Mode / Rescue Mode
• systemd Rescue & Emergency Targets
• Filesystem Recovery with fsck
• Disk & SMART Diagnostics
• chroot Recovery
• initramfs Recovery
• LUKS Encryption Recovery
• LVM Recovery
• Live USB Recovery
• Linux Rescue Tools
• Disk Imaging & Cloning
• Partition Recovery
• Network Troubleshooting
• Real-World Recovery Scenarios
• Recovery Decision Tree

1. Linux Recovery Options at a Glance

🛠️

Recovery Mode

Many distributions provide a recovery option through the bootloader that can start a minimal environment.

🚀

GRUB

GRUB controls the boot process and can often be repaired without reinstalling Linux.

💽

fsck

Checks and repairs supported Linux filesystems.

🔧

chroot

Allows you to enter a damaged Linux installation from another boot environment.

🔐

LUKS

Provides tools for unlocking encrypted Linux storage during recovery.

📦

LVM

Allows recovery and management of logical volumes.

Windows Recovery Tools & Options: The Complete Guide to Fixing Windows

WINDOWS TROUBLESHOOTING & RECOVERY

Windows Recovery Tools
The Complete Guide

From built-in Windows Recovery Environment and Safe Mode to DISM, SFC, BCDBoot, installation media and professional WinPE rescue environments.

Explore Recovery Options Technician Toolkit

Quick idea: When Windows refuses to boot, crashes repeatedly, becomes corrupted or suffers from a damaged bootloader, you don't necessarily need to reinstall Windows. Windows provides several layers of recovery tools, ranging from simple graphical options to powerful command-line repair utilities.

Windows recovery is best approached as a layered troubleshooting process. Start with the least destructive option and move toward advanced recovery only when necessary.

📚 Table of Contents

• Windows Recovery Options
• Windows Recovery Environment
• Startup Repair
• Safe Mode
• System Restore
• Uninstall Updates
• Command Prompt Recovery
• SFC
• DISM
• Bootloader Repair
• Windows Installation Media
• Third-Party Recovery Tools
• Professional Technician Toolkit
• Which Recovery Tool Should You Use?

1. Windows Recovery Options at a Glance

🛠️

Startup Repair

Automatically attempts to repair problems preventing Windows from booting.

🧪

Safe Mode

Starts Windows with a minimal set of drivers and services.

↩️

System Restore

Returns system configuration to an earlier restore point.

💻

Command Prompt

Provides advanced offline troubleshooting capabilities.

🔧

DISM

Repairs Windows component-store corruption.

🧹

SFC

Checks and repairs protected Windows system files.

2. Windows Recovery Environment — WinRE

Windows Recovery Environment (WinRE) is Microsoft's built-in recovery environment. It is a lightweight Windows-based environment designed to help diagnose and repair problems when normal Windows cannot start correctly.

Windows

→

Recovery

→

WinRE

→

Repair

Typical WinRE options

• Startup Repair
• System Restore
• System Image Recovery
• Uninstall Updates
• Startup Settings
• Command Prompt
• UEFI Firmware Settings

SCP in Linux: A Comprehensive, Easy-to-Understand Guide










scp — Secure Copy — is one of the simplest ways to transfer files and directories between Linux machines over an SSH connection.

If you work with Linux servers, AWS, Azure, Docker, Kubernetes, Hadoop, DevOps, SRE, or system administration, scp is a command you will use frequently.

For example:

scp backup.tar.gz user@192.168.1.20:/home/user/

This means:

Take backup.tar.gz from my current machine and securely copy it to /home/user/ on 192.168.1.20.

Modern OpenSSH scp uses the SFTP protocol over an SSH connection by default, while retaining the familiar scp command syntax. It uses the same SSH authentication and security model as an SSH login.

---

1. What is SCP?

SCP stands for:

Secure Copy Protocol / Secure Copy

The scp command allows you to copy:

• Local → Remote
• Remote → Local
• Directory → Remote
• Remote → Directory
• Remote → Remote

The important concept is that SSH is used for authentication and encrypted communication.

Think of it this way:

Your Linux Machine
       |
       | SSH encrypted connection
       |
       v
Remote Linux Server

Instead of:

FTP
   |
   +---- username/password
   +---- potentially insecure depending on configuration

you can use:

SCP
 |
 +---- SSH authentication
 +---- encrypted connection
 +---- secure file transfer

---

2. Why Do We Use SCP?

Imagine you have this situation:

Your Laptop
10.10.10.5

and your server is:

Production Server
10.10.10.20

You created:

application.tar.gz

on your laptop and need to put it on the server.

Without SCP, you might need:

• FTP
• SFTP client
• cloud storage
• USB
• web upload
• email
• shared network storage

With SCP:

scp application.tar.gz user@10.10.10.20:/opt/apps/

Done.

---

3. Basic SCP Syntax

Podman: The Complete Guide to Rootless, Daemonless Containers

Podman is an open-source container engine designed to build, run, manage, and deploy OCI containers and pods. It provides a Docker-compatible CLI experience while taking a fundamentally different approach: Podman is daemonless and can run containers rootlessly as a regular Linux user.

For developers, DevOps engineers, SREs, platform engineers, and administrators, Podman is particularly interesting when you want containerization without depending on a permanently running privileged daemon.

---

1. What is Podman?

Podman originally stands for Pod Manager.

It provides commands for:

• Running containers
• Building images
• Managing images
• Managing pods
• Creating networks
• Managing volumes
• Running containers without root
• Integrating containers with systemd
• Running Kubernetes YAML locally
• Working with OCI-compatible images and runtimes

A major design characteristic is that Podman is daemonless. Unlike the traditional Docker architecture, there isn't a central Docker daemon that all local container operations must go through.

Conceptually:

Traditional Docker-style model

User
  |
  v
Docker CLI
  |
  v
Docker Daemon
  |
  +---- Container
  +---- Container
  +---- Image
  +---- Network

Podman:

User
  |
  v
Podman CLI
  |
  +---- Container
  +---- Container
  +---- Pod
  +---- Image
  +---- Network

That architectural difference becomes especially important for rootless containers and systemd-based deployments.

---

2. Podman vs Docker

OpenShift: A Comprehensive Guide to Enterprise Kubernetes

OpenShift is Red Hat's enterprise Kubernetes platform for building, deploying, securing, operating, and scaling containerized applications.

If Kubernetes provides the orchestration foundation, OpenShift adds an integrated platform around it: security controls, Operators, networking and Routes, a web console, image/build workflows, cluster lifecycle management, monitoring, and enterprise-oriented administration. OpenShift Container Platform 4.20 is built on Kubernetes and uses Red Hat Enterprise Linux CoreOS (RHCOS) and CRI-O as core node technologies.

This guide covers OpenShift from fundamentals through architecture, administration, application deployment, networking, storage, security, Operators, CI/CD, troubleshooting, and production design.

---

1. What Is OpenShift?

At its simplest:

Kubernetes
    +
Enterprise platform capabilities
    +
Security
    +
Developer tooling
    +
Operators
    +
Integrated networking
    +
Cluster lifecycle management
    +
Web console
    =
OpenShift

OpenShift is therefore not a completely separate alternative to Kubernetes.

It is a Kubernetes-based platform that adds significant functionality and opinionated operational components around Kubernetes. Red Hat describes OpenShift Container Platform as a Kubernetes platform for building, deploying, and managing enterprise container workloads.

---

2. Kubernetes vs OpenShift

A useful mental model is:

                 OpenShift
┌──────────────────────────────────────────┐
│ Web Console                              │
│ Developer Tools                          │
│ Routes                                   │
│ Operators / OperatorHub                  │
│ Builds / ImageStreams                    │
│ SCC / Security                           │
│ Monitoring                               │
│ Authentication                           │
│ Cluster Lifecycle                        │
├──────────────────────────────────────────┤
│              Kubernetes                  │
│ Pods / Deployments / Services             │
│ Scheduling / Controllers / API            │
├──────────────────────────────────────────┤
│              Container Runtime            │
│                  CRI-O                    │
├──────────────────────────────────────────┤
│                  RHCOS                   │
└──────────────────────────────────────────┘

OpenShift retains Kubernetes concepts such as:

• Pods
• Deployments
• ReplicaSets
• Services
• ConfigMaps
• Secrets
• PersistentVolumeClaims
• StatefulSets
• Jobs
• CronJobs
• RBAC
• NetworkPolicy

while adding OpenShift-specific APIs and platform components.

---

3. OpenShift Architecture

HashiCorp Nomad: A Comprehensive Guide to Workload Orchestration

HashiCorp Nomad is a distributed workload orchestrator designed to deploy and manage containers, batch jobs, long-running services, legacy applications, and other workloads across clusters of machines.

If Docker answers:

“How do I run this container?”

and Kubernetes answers:

“How do I orchestrate containers across a cluster?”

Nomad takes a somewhat broader and simpler approach:

“How do I schedule and operate different kinds of workloads across my infrastructure?”

Nomad can run Docker containers, binaries, Java applications, QEMU workloads, and other task-driver-based workloads. HashiCorp describes it as a highly available, distributed, datacenter-aware scheduler designed for services, batch jobs, and more.

---

1. What Is HashiCorp Nomad?

Nomad is a cluster scheduler and workload orchestrator developed by HashiCorp.

Its core responsibilities include:

• Scheduling workloads
• Allocating CPU and memory
• Placing workloads on appropriate nodes
• Running long-lived services
• Running batch jobs
• Running jobs on every node
• Handling workload failures
• Rolling out updates
• Managing task lifecycle
• Service registration
• Integrating with Consul
• Integrating with Vault
• Supporting multiple datacenters
• Supporting heterogeneous workloads

A simplified architecture is:

                    NOMAD
                      │
             ┌────────┴────────┐
             │                 │
        Nomad Servers      Nomad Clients
             │                 │
        Scheduling         Run workloads
        Cluster State      Containers
        Coordination       Binaries
             │             Batch jobs
             │             Services
             ▼
          Allocations

Nomad's servers handle scheduling and cluster management, while clients execute the workloads assigned to them.

---

2. Why Nomad?

Traditional application deployment might look like:

Server 1 → Application A
Server 2 → Application B
Server 3 → Application C
Server 4 → Application D

As infrastructure grows, you need to answer:

• Where should an application run?
• Does the server have enough CPU?
• Does it have enough memory?
• Does it have the required runtime?
• What happens if the server fails?
• How do we deploy five copies?
• How do we update them?
• How do we run a job every night?
• How do we deploy something to every node?
• How do services discover each other?

Nomad provides a scheduling and reconciliation layer.

Desired State
      │
      ▼
   Nomad Job
      │
      ▼
   Scheduler
      │
      ▼
 Allocation Plan
      │
      ▼
 Nomad Clients
      │
      ▼
 Workloads

---

3. Nomad vs Kubernetes

How to Fix Missing Dual-Boot Entries in Kali Linux GRUB (Enable OS-Prober)

📅 September 18, 2026 Kali Linux GRUB Dual Boot os-prober Linux

If you have dual-booted Kali Linux alongside another distribution like Ubuntu, Windows, or another Linux variant, you might notice something frustrating after installation: your secondary operating system completely vanishes from the boot screen.

Don't panic—your files and alternative operating systems are perfectly safe. Modern versions of Kali Linux explicitly disable automated OS discovery (os-prober) out of the box to mitigate potential security vulnerabilities (like unauthorized background mounting).

To bring your secondary operating system back to your launch menu, you need to manually unlock this feature. Here is a quick step-by-step guide to updating your GRUB bootloader matrix.

Step 1 Open the GRUB Configuration File

To change how your bootloader behaves, you must modify its primary configurations template. Open your terminal in Kali Linux and open the file using the nano text editor:

sudo nano /etc/default/grub

Step 2 Unlocking the OS Prober Engine

Scroll down through the configuration lines inside the editor. Look for the dedicated section regarding multiple operating systems.

You need to locate or create a parameter variable called GRUB_DISABLE_OS_PROBER.

• If the line is already there: Check if it says =true. Change it directly to false so it looks exactly like this:

GRUB_DISABLE_OS_PROBER=false

• If the line is commented out (has a # in front of it): Delete the # symbol to activate the configuration command.
• If the line is completely missing: Navigate to the absolute bottom of the document and add it manually:

GRUB_DISABLE_OS_PROBER=false