Fjärrskrivbord i GNOME: En komplett guide om Linux

Om du arbetar med Linux dagligen gör ett välkonfigurerat fjärrskrivbord i GNOME hela skillnaden: du kan hantera servrar, hjälpa andra användare eller fortsätta arbeta på din dator även när du inte fysiskt är där. I moderna miljöer som GNOME 44 eller GNOME 50 har alternativen förändrats avsevärt jämfört med äldre versioner, och de förinstallerade verktygen varierar beroende på distributionen (Debian, Oracle Linux, Ubuntu, etc.).

För att ytterligare komplicera saken samexisterar flera tekniker: RDP, VNC, proprietära lösningar som AnyDesk eller RealVNC Connect, och optimerade protokoll som X2Go . Var och en har konsekvenser för säkerhet, prestanda och användarvänlighet. I den här guiden ska vi reda ut detta kaos och lugnt undersöka hur fjärrskrivbordsfunktionalitet fungerar i GNOME och vilka alternativ du har om du vill använda den i Debian eller andra distributioner.

Fjärrskrivbord i GNOME: vad miljön inkluderar och varför det ibland inte visas

Skrivbordsmiljön GNOME erbjuder flera inbyggda sätt att fjärråtkomst till grafiska sessioner , men dessa metoder implementeras inte alltid på samma sätt i alla distributioner. Konceptuellt stöder GNOME två huvudscenarier:

Å ena sidan finns det skrivbordsdelning med en redan inloggad användare . Detta är vanligt när du ansluter till någons öppna session på deras dator för att ge support eller hantera samma session från en annan maskin. I GNOME hanteras detta vanligtvis från panelen Inställningar > Delning > Fjärrskrivbord med hjälp av komponenten gnome-remote-desktop.

Å andra sidan finns det fjärrinloggning med GNOME-inloggningsskärmen . I det här fallet ansluter inte fjärrklienten till en befintlig session, utan ser istället inloggningshanteraren (GDM) och kan öppna en ny grafisk GNOME-session som om de satt framför maskinen, vilket ofta kallas "fjärrinloggning".

När det finns fysisk åtkomst till servern och en bildskärm är ansluten, visar många GNOME-skrivbord alternativet för skrivbordsdelning direkt i inställningsgränssnittet. I distributioner som Debian trixie/sid med GNOME 44.8 kanske det här alternativet dock inte visas även om du installerar paket som gnome-remote-desktop, gnome-connections eller xrdp, antingen för att distributionsleverantören har ändrat förinställningarna, eller för att grafisk integration är inaktiverad eller ännu inte har anpassats till den versionen.

I headless-miljöer (servrar utan bildskärm, molnmaskiner, instanser i Oracle Cloud Infrastructure, Azure, etc.) förändras saker och ting: GNOME visar inte alltid den grafiska panelen "Fjärrskrivbord" och lösningar som FreeRDP eller X2Go används ofta, vilka startar grafiska sessioner utan behov av en fysisk bildskärm.

GNOME, RDP och gnome-remote-desktop som skrivbordsserver

I moderna GNOME-system är nyckelkomponenten för att tillhandahålla fjärrskrivbordsåtkomst via RDP gnome-remote-desktop. Denna daemon kan fungera både som en användartjänst (för att dela den aktuella sessionen) och en systemtjänst (för headless fleranvändaråtkomst), och hanteras med kommandoradsverktyget grdctl.

Generellt sett innebär processen för att konfigurera en RDP-server med GNOME som backend följande steg: installation av GNOME och FreeRDP, konfigurering av TLS, registrering av RDP-inloggningsuppgifter och aktivering av tjänsten . I miljöer som Oracle Linux görs detta på ett system utan grafisk miljö, och GNOME-skrivbordet installeras från grunden tillsammans med RDP-programvaran.

Först installeras en komplett GNOME-skrivbordsmiljö med alla dess beroenden , vilket säkerställer att systemet är uppdaterat och omstartas vid behov. Därefter läggs FreeRDP-paketet till, vilket är den fria implementeringen av RDP-protokollet som används för att hantera och/eller testa fjärranslutningar.

För att aktivera en headless RDP-server för flera användare måste du generera en självsignerad nyckel och ett TLS-certifikat . Du skapar en dedikerad katalog för att lagra dem, använder ett verktyg som winpr-makecert för att generera .key/.crt-paret och anger sedan för gnome-remote-desktop var dessa filer finns med hjälp av grdctl-kommandon.

Nästa steg är att definiera RDP-inloggningsuppgifterna . Dessa inloggningsuppgifter (användarnamn och lösenord) är vad RDP-klienten kommer att använda för att etablera sessionen som visar GNOME-inloggningsskärmen. Det är viktigt att förstå att detta inte ersätter systemets lokala konton: för att gå in i en riktig skrivbordssession måste användaren logga in med ett giltigt Linux-användarkonto och sitt vanliga lösenord.

När du har ställt in TLS-nyckeln, certifikatet och inloggningsuppgifterna är det en bra idé att köra kommandot `gnome-remote-desktop status` med alternativet att visa inloggningsuppgifter . Detta verifierar att nyckeln och certifikatet matchar (samma basnamn och sökväg) och att användarnamnet och lösenordet är korrekta. Denna preliminära kontroll kommer att bespara dig mycket problem senare.

Efter avsnittet TLS och konton aktiveras och startas RDP-tjänsten för fjärrskrivbord på systemnivå, det kontrolleras med systemctl att den är aktiv, GDM-tjänsten och fjärrinloggningstjänsten aktiveras på systemnivå och gnome-remote-desktop konfigureras som standardtjänsten som startar vid varje omstart.

Slutligen är det en bra idé att bekräfta att servern verkligen lyssnar på port 3389 , typiskt för RDP, med ett kommando som: `sudo ss -lnpA inet | grep -e gnome-remote`. Om du ser port 3389 öppen och associerad med rätt process är serversidan redo.

Headless-servrar och FreeRDP: åtkomst för en eller flera användare

Många moderna distributioner använder headless-servrar i molnet . I dessa fall visar inte GNOME paneler för skrivbordsdelning, och det är mer praktiskt att behandla maskinen som en generisk RDP-server med fleranvändarsessioner.

FreeRDP kommer här in som en gratis implementering av Remote Desktop Protocol som kan fungera både som en klient och, i vissa scenarier, integrera med servertjänster. Denna kombination möjliggör sessioner för en eller flera samtidiga användare, var och en med sin egen grafiska session, vilket är mycket användbart i övningslaboratorier eller utbildningsmiljöer , eller i en virtuell skrivbordsinfrastruktur där flera studenter har åtkomst till samma värdmaskin.

Att konfigurera miljön följer vanligtvis en liknande ordning som den som finns i Oracle Linux-guider: öppna en terminal, anslut till noden via SSH (till exempel ol-node-01), uppdatera paket, installera GNOME och FreeRDP och kontrollera om en omstart är nödvändig. Detta förvandlar en maskin utan skrivbord till en server som är redo att erbjuda grafiska sessioner över nätverket.

I automatiserade distributioner med Ansible är det ibland nödvändigt att justera variabler som `ansible_python_interpreter` för localhost när man installerar Oracle Cloud Infrastructure SDK. Detta beror på att paketet finns i systemets Python-modulkatalog, och Ansible behöver veta vilken interpreter som ska användas. Detaljer som instanstyp (t.ex. `VM.Standard3.Flex`) eller Oracle Linux-versionen som skickas via kommandoraden med `os_version` parametreras också ofta.

När automatiseringen körs visar playbooken vanligtvis de offentliga och privata IP-adresserna för instanserna, vilket gör att du kan bestämma vilken fjärradress du ska ansluta från via RDP eller SSH . Därifrån behöver du helt enkelt öppna tunnlar eller exponera portar enligt din definierade säkerhetspolicy.

Klientåtkomst: Remmina, Connections och andra RDP-gränssnitt

När du har konfigurerat din GNOME-server med RDP behöver du en kompatibel fjärrskrivbordsklient . Linux erbjuder flera alternativ, men alla fungerar inte lika bra med gnome-remote-desktop och FreeRDP.

Bland de klienter som är kända för att fungera bra finns Remmina och GNOME Connections på Linux, och xfreerdp på macOS. I labb som Oracle Linux är Remmina ofta förinstallerat på Luna Desktop för att förenkla testning, eftersom det erbjuder ett mycket flexibelt gränssnitt och stöder en lång lista med protokoll (RDP, VNC, SSH, etc.).

För att ansluta till en fjärransluten RDP-server via en SSH-tunnel kan du öppna en terminal och använda SSH med alternativet -L för lokal portvidarebefordran . Du kan till exempel mappa fjärrport 3389 till lokal port 13389. På så sätt görs RDP-anslutningen till localhost:13389 men krypteras inom SSH-tunneln.

När tunneln är konfigurerad, öppna Remmina, skapa en ny anslutning, välj RDP – Remote Desktop Protocol som protokoll och fyll i parametrar som:

• serverlocalhost:13389 (eller den lokala port du har valt).
• RDP-användarnamn: den som definieras när RDP-inloggningsuppgifterna konfigureras på servern.
• lösenord: den du angav i grdctl.

Om du föredrar kan du starta anslutningen direkt från en terminal med ett kommando som remmina -c rdp://user@localhost:13389. När du ansluter ser du vanligtvis GNOME Start Manager (GDM) ; därifrån loggar du in med dina Linux-användaruppgifter (till exempel användarnamn oracle / lösenord oracle i vissa labb).

Om du stöter på anslutningsproblem är den typiska lösningen att först kontrollera SSH-anslutningen och tunneln . I molnmiljöer som Oracle Cloud Infrastructure kan du behöva ytterligare nätverkssteg: öppna portar i det virtuella nätverksnätverket, konfigurera säkerhetslistor eller NAT-regler för att exponera instansen. I virtualiseringsprogramvara som Oracle VM VirtualBox används å andra sidan portvidarebefordran i den virtuella maskinens NAT-nätverk för att omdirigera RDP-anslutningar från värden.

Brandvägg och RDP-portsäkerhet: direktåtkomst kontra SSH-tunnel

RDP-tjänsten exponeras som standard på TCP-port 3389. På betrodda interna nätverk kan du öppna den här porten i brandväggen för att tillåta klienter att ansluta direkt, men det finns viktiga nyanser att beakta.

Även om det moderna RDP-protokollet, och implementeringar som gnome-remote-desktop med FreeRDP, använder TLS för att kryptera kommunikation , är det inte en bra idé att lämna port 3389 öppen för internet utan ytterligare skydd. Även på Linux leder exponering av ofiltrerad RDP ofta till brute-force-attacker, massskanningar och potentiella sårbarheter i RDP-stacken.

Därför anger många guider att det är valfritt och inte rekommenderat att öppna porten direkt i brandväggen. Helst bör RDP kombineras med en säker tunnel, till exempel SSH, eller med en VPN som dirigerar trafik från auktoriserade klienter till nätverket där servern finns.

Om du ändå väljer att öppna port 3389 för direktåtkomst på ett privat nätverk, måste du skapa brandväggsregler (till exempel med hjälp av firewalld, nftables eller iptables) som tillåter denna trafik, helst begränsa den till käll-IP-adress för att minska attackytan. Även då är det viktigt att användarkonton använder starka lösenord och att systemet hålls uppdaterat med patchar.

Fjärrskrivbordsprestanda: GNOME vs. XFCE, Xubuntu eller MATE

Prestandan för ett fjärrskrivbord beror på nätverket, den grafiska miljön och det valda protokollet . Att servera en fullständig GNOME-miljö med effekter och animationer över RDP är inte detsamma som att servera ett lätt XFCE-skrivbord som körs över X2Go.

I experiment med Ubuntu 20.04/22.04 LTS på Azure Lab Services observerades det att GNOME över RDP kan introducera märkbar latens , särskilt om anslutningen är dålig eller om skrivbordet är laddat med visuella effekter. Däremot tenderar lättviktiga skrivbord som XFCE, Xubuntu eller MATE att köras smidigare med färre resurser.

Ett mycket optimerat alternativ för långsamma nätverk är X2Go, som använder NX-protokollet och drar nytta av framsteg inom Xlibre . Denna metod komprimerar och optimerar skärmuppdateringar mycket bra, vilket möjliggör rimlig prestanda även på länkar med hög latens, särskilt i Linux-till-Linux-scenarier. Många labb rekommenderar kombinationen XFCE + X2Go just på grund av detta förhållande mellan prestanda och strömförbrukning.

I Xubuntu- och X2Go-inställningar rekommenderas det generellt att inaktivera fönsterkomposition för att ytterligare förbättra prestandan, eftersom kompositionen lägger till onödig grafisk belastning på ett fjärrskrivbord. Efter att ha inaktiverat den och startat om maskinen är upplevelsen vanligtvis mycket smidigare.

MATE är ett annat mellanalternativ, med något högre resursförbrukning än XFCE men lägre än GNOME, och det integreras också bra med X2Go med samma port 22 som SSH, vilket förenklar nätverksinstallationen i laboratorier och utbildningsmiljöer.

Typiska fjärrskrivbordskonfigurationer i Linux-labb

I plattformar som Azure Lab Services eller utbildningsmiljöer används flera vanliga kombinationer av skrivbords- och fjärråtkomstteknik , var och en med sina egna fördelar:

Kombinationen XFCE + X2Go rekommenderas ofta som det alternativ med bäst prestanda totalt sett. Installationen innebär att man lägger till XFCE-miljön, installerar X2Go-servern och sedan ansluter studenterna med X2Go-klienten, utan att behöva ändra några brandväggsinställningar eftersom X2Go återanvänder den redan öppna SSH-porten 22.

Ett annat alternativ är Xubuntu + X2Go , som i huvudsak är likartad men inkluderar de anpassningar och paket som Xubuntu erbjuder. För att säkerställa optimal prestanda rekommenderas det starkt att inaktivera fönsterkomposition och starta om mallen innan du publicerar den till studenter.

Med MATE + X2Go är tillvägagångssättet identiskt: installera MATE, lägg till X2Go-servern och använd X2Go-klienten från studenternas arbetsstationer. I alla dessa fall utnyttjas det faktum att X2Go förlitar sig på SSH, vilket undviker behovet av att öppna ytterligare portar.

Om du däremot vill erbjuda ett komplett GNOME-skrivbord i Azure Lab Services rekommenderas att du använder RDP. Detta kräver ett ytterligare steg under skapandet av labbet: att aktivera RDP-anslutningstypen för att öppna port 3389, eftersom som standard endast port 22 är öppen för SSH och detta inte kan ändras efter att labbet har skapats.

När RDP har aktiverats installeras GNOME på den virtuella mallen, RDP-servern läggs till, prestandajusteringar tillämpas (begränsning av grafiska effekter, justering av RDP-komprimering etc.) och du kan sedan ansluta från studentens operativsystems RDP-klient.

RDP- och VNC-klienter från Linux: Remmina, Vinagre och andra

Från Linux-klientsidan har du flera verktyg för att ansluta till fjärrskrivbord med hjälp av RDP, VNC eller SSH . Ett av de mest omfattande är Remmina, som också används flitigt i GNOME- och Debian-miljöer.

Remmina är ett fritt programvaruprojekt som stöder protokoll som RDP, VNC, SSH, SPICE och X2Go , bland andra. På Debian innebär en typisk installation att uppdatera paketlistan, tillämpa uppdateringar och sedan installera Remmina tillsammans med nödvändiga plugins, såsom remmina-plugin-rdp och remmina-plugin-secret, för att ge fullständigt RDP-stöd och säker lagring av autentiseringsuppgifter.

När Remmina är installerat kan du starta den från Aktiviteter eller terminalen. Det låter dig göra snabba anslutningar genom att skriva IP-adressen eller fjärrvärdnamnet direkt i den översta fältet, eller skapa sparade profiler med detaljer som upplösning, bildkvalitet, inloggningsuppgifter etc.

Om du behöver arbeta regelbundet med en Windows-server från en Debian med GNOME, är det vanliga att skapa en RDP-profil i Remmina, peka på serverns DNS-namn eller IP-adress (till exempel en Windows Server 2016), ange domänens användarnamn och lösenord och justera helskärms- eller fönsterläge.

Remmina erbjuder också en liten flytande panel när du är i helskärmsläge , som glider in från toppen. Därifrån kan du växla till fönsterläge, logga ut eller justera vissa inställningar utan att släppa musen.

En annan klassisk GNOME-applikation är Vinagre, ursprungligen designad som en enkel fjärrskrivbordsklient . Den stöder VNC, RDP och SSH, och för att installera den på Debian-baserade distributioner, lägg helt enkelt till vinagre-paketet. Den är mindre kraftfull än Remmina vad gäller funktioner, men för tillfälliga anslutningar eller mycket GNOME-centrerade miljöer är den fortfarande ett giltigt verktyg.

VNC och alternativ: TigerVNC, TightVNC och VNC Viewer

VNC är en annan familj av fjärrskrivbordstekniker som är djupt rotade i Linux. Den består vanligtvis av två komponenter: en VNC-server på fjärrdatorn och en klient, till exempel VNC Viewer, på datorn du ansluter från.

TigerVNC är en högpresterande implementering som följer en klassisk klient/server-modell. För att använda den på Linux kan du installera paketet från din distributions programvarucenter eller pakethanterare. När den är installerad har du verktyg för att starta en VNC-server på den maskin du vill kontrollera och ett visningsprogram för att ansluta från en annan.

TigerVNC-klienten innehåller vanligtvis konfigurationsflikar som Komprimering, Säkerhet, Inmatning och Visning , där du kan justera komprimeringsnivå, krypterings- och autentiseringsmetoder, accepterade inmatningsenheter och skärmskalning. Dessa alternativ är mycket användbara för att anpassa upplevelsen till långsamma anslutningar eller skärmar med varierande upplösning.

TightVNC är ett annat gratisalternativ riktat mot både fjärradministration och mer rutinmässiga uppgifter. På Linux kan du installera servern med tightvncserver och konfigurera separata grafiska sessioner, medan klienten ofta hanteras med VNC Viewer, som är tillgänglig för flera plattformar.

VNC Viewer installeras från paketet som motsvarar din distribution och integreras med VNC-servrarna i ditt nätverk. Upplevelsen är vanligtvis mycket enkel: du anger serverns IP-adress eller namn, åtkomstlösenordet och du kan sedan interagera med fjärrskrivbordet.

Kommersiella lösningar och lösningar för flera plattformar: RealVNC Connect, AnyDesk och RustDesk

Utöver ren RDP och VNC finns det kompletta fjärrskrivbordslösningar som erbjuder förmedlingstjänster, avancerad kryptering och centraliserad hantering . För Linux utmärker sig RealVNC Connect, AnyDesk och RustDesk, alla tillgängliga från en modern GNOME-skrivbordsmiljö.

AnyDesk är mycket populärt för sin enkelhet och prestanda. Det använder en egenutvecklad kodek, DeskRT, som är speciellt utformad för fjärrskrivbordsanslutningar, vilket gör att det kan erbjuda låg latens och god bildkvalitet även på anslutningar med begränsad bandbredd. I scenarier med låg bandbredd kan viss pixelering eller oskärpa uppstå, men upplevelsen förblir användbar.

När det gäller säkerhet krypterar AnyDesk sessioner med TLS 1.2 och RSA 2048 nyckelutbyte , vilket skyddar kommunikationen mot avlyssning. Den stöder också flera sessioner och obevakade anslutningar, perfekt för åtkomst till datorer på avlägsna platser eller utan personal på plats.

RealVNC Connect , å andra sidan, är starkt inriktat på företag. Det erbjuder end-to-end-kryptering, multifaktorautentisering (MFA) , SSO-integration och kan ansluta till kataloginfrastruktur som Windows- eller Azure-domänservrar. En viktig fördel är dess fokus på efterlevnad och centraliserad hantering av behörigheter, enheter och åtkomstloggar.

Prestandamässigt är RealVNC Connect, baserat på VNC, ganska anpassningsbart : det justerar grafikkvaliteten till anslutningen och låter dig manuellt definiera skalning och bildkvalitet, prioritera detaljer eller jämnhet som du önskar, redan innan sessionen påbörjas.

RustDesk presenterar sig som ett gratis alternativ som i princip inte kräver någon konfiguration: du kan använda den publika servern, vara värd för din egen server eller ansluta peer-to-peer. Det är utvecklat i Rust och använder RFB-protokollet för att skicka skärmuppdateringar, med funktioner som filöverföring, behörighetskontroll, obevakat läge och möjligheten att enkelt konfigurera din egen infrastruktur om du vill ha fullständig kontroll.

När du väljer måste flera faktorer beaktas: om du hanterar känsliga data och kräver strikt efterlevnad är RealVNC Connect vanligtvis det mest pålitliga alternativet. För snabb, plattformsoberoende fjärrsupport med minimal konfiguration erbjuder AnyDesk och Chrome Remote Desktop mycket enkla upplevelser. Och för miljöer som är starkt beroende av Linux och som även hanterar Windows och macOS erbjuder RealVNC Connect och RustDesk en bra balans mellan kompatibilitet, säkerhet och flexibilitet.

RDP jämfört med andra alternativ: enkel installation och säkerhet

Många guider varnar för att RDP-baserade lösningar kräver betydande ytterligare säkerhetsarbete . Till skillnad från tjänster som levereras med molnförmedling eller inbyggd avancerad autentisering är ofiltrerad RDP som exponeras för internet ofta en magnet för attacker.

Om du vill använda RDP på ​​Linux med acceptabel säkerhet rekommenderas det nästan alltid att skydda det bakom ett VPN , använda åtkomstkontrolllistor i brandväggen och undvika att exponera port 3389 fritt till varje pris. Däremot kräver inte verktyg som RealVNC Connect eller AnyDesk att du konfigurerar portvidarebefordran eller SSH-tunnlar eftersom de hanterar trafik via sina egna tjänster och vanligtvis inkluderar ytterligare autentiseringsmekanismer som standard.

När det gäller enkel installation har varje lösning sin plats: medan Remmina på Debian eller Ubuntu installeras med ett par kommandon och börjar fungera direkt, innebär konfigurationen av xRDP eller X2Go att man öppnar portar, skapar brandväggsregler och, i strängare miljöer, hanterar listor över tillåtna eller blockerade IP-adresser på nätverks- och användarnivå.

Chrome Remote Desktop är förmodligen ett av de enklaste verktygen att konfigurera för personligt bruk: länka det bara till ett Google-konto och följ guiden. Men just för att det förlitar sig på Googles autentiserings- och hanteringsinfrastruktur anser vissa företag att det är dåligt anpassat till deras säkerhetspolicyer.

Användningsfall: företag, fjärrsupport och Linux-entusiaster

Alla miljöer har inte samma behov, så det är bra att urskilja några typiska scenarier för att använda fjärrskrivbord i Linux med GNOME och andra skrivbord.

För företag som hanterar känslig information är säkerhet, regelefterlevnad och centraliserad hantering högsta prioritet . I detta sammanhang utmärker sig RealVNC Connect för sina end-to-end-krypteringsfunktioner, MFA-, SSO- och RADIUS-integrationer samt verktyg för användar- och enhetshantering.

För små supportteam som hjälper användare på avlägsna platser är verktyg som AnyDesk eller Chrome Remote Desktop ett utmärkt val, eftersom de möjliggör snabba, plattformsoberoende anslutningar med minimal installation, perfekt för att hantera engångsincidenter utan att fastna i VPN-tjänster eller avancerade brandväggsregler.

I Linux-entusiaster och systemadministratörer möjliggör kombinationer som X2Go, xRDP eller VNC med GNOME, XFCE eller MATE skapandet av anpassade miljöer med maximal kontroll över portar, kryptering och resurser. För de som föredrar att arbeta från en Linux-skrivbordsmiljö men också behöver hantera Windows- och macOS-servrar erbjuder RealVNC Connect och Remmina en intressant balans mellan funktionalitet och användbarhet.

Oavsett fallet är nyckeln att vara tydlig med vad som är viktigast för dig: om du letar efter säkerhet på företagsnivå , om det är värt att prioritera användarvänlighet för icke-tekniska användare, eller om du främst behöver prestanda på begränsade nätverk.

Med tanke på denna översikt är det tydligt att fjärrskrivbordsåtkomst i GNOME och Linux i allmänhet inte är ett enda verktyg, utan snarare en rad alternativ. Dessa sträcker sig från RDP som hanteras av gnome-remote-desktop med FreeRDP och är tillgängliga via Remmina, till X2Go och lätta skrivbordsmiljöer som XFCE eller MATE för förbättrad prestanda, och till och med kommersiella lösningar som RealVNC Connect, AnyDesk eller RustDesk som fokuserar på säkerhet och bekvämlighet. Att välja rätt kombination att använda på din Debian med GNOME eller en annan distribution innebär att man beaktar nätverkskrav, resurser, säkerhet och framför allt hur du och ditt team kommer att arbeta dagligen.