Varför SSH bara kan visa text, och vad som krävs för att ändra på det

SSH överför en ström av tecken, inget annat. Protokollet öppnar en krypterad tunnel över TCP port 22 och i den tunneln skickas tangenttryckningar in och text ut. Det finns ingen inbyggd förståelse för fönster, knappar eller bilder. Vill du ha ett grafiskt gränssnitt mot en fjärrmaskin måste du bygga det själv ovanpå textströmmen och det är precis den utmaningen som gjort att idén om ett nativt grafiskt skal för SSH dyker upp med jämna mellanrum.

Enkelt uttryckt: SSH vet inte vad en bild är. Det vet bara hur man flyttar byte säkert från en dator till en annan.

SSH byggdes för att ersätta ett osäkert kommandoskal, inte för att rita fönster

När SSH konstruerades var uppgiften att kryptera en textbaserad inloggning. Föregångaren, telnet, skickade allt i klartext, inklusive lösenord. SSH löste det genom att lägga en krypteringslager runt samma sorts terminaltrafik. Resultatet är ett protokoll som är oöverträffat på en sak: att ge dig ett kommandoskal på en annan maskin utan att någon på vägen kan läsa med.

Den styrkan är också begränsningen. En SSH-session är i grunden en pseudoterminal, en virtuell skrivmaskin där servern skickar tecken och styrkoder. Färger, markörens position och radbrytningar hanteras med escape-sekvenser som terminalen tolkar. Det finns ingen kanal för en muspekare som klickar på en fil, ingen struktur som säger ”det här är en knapp”. Allt som ser grafiskt ut i en terminal, som en filhanterare byggd med ramar och färgblock, är fortfarande bara text som ritas tecken för tecken.

Det är därför grafiska verktyg ofta slår terminalen för vissa uppgifter. Att bläddra genom hundra filer, jämföra processer som äter minne eller redigera en konfiguration blir enklare med ett riktigt gränssnitt. Terminalen tvingar dig att komma ihåg kommandon och läsa kolumner av text. Ett grafiskt skal skulle kunna visa samma information som klickbara listor och grafer. Skillnaden märks direkt när du felsöker en server som beter sig konstigt och bara har `top` och `ps` att luta dig mot.

Frågan är hur man får dit den grafiska informationen. Ett sätt är att inte röra SSH-lagret alls, utan att köra en liten webbserver på fjärrmaskinen och skicka HTTP genom SSH-tunneln. Krypteringen sköts då av SSH och webbservern behöver inte hantera säkerhet själv. Ett mer intressant grepp är att låta den webbservern lyssna på en Unix-domän-socket i stället för en localhost-port. Socket-filen får då vanliga filsystemrättigheter, vilket betyder att operativsystemet redan avgör vem som får ansluta. Du slipper konfigurera portar och brandväggsregler och åtkomsten blir explicit på filnivå. Ovanpå det kan enskilda appar registrera sig, till exempel en textredigerare, så att en filhanterare kan be den öppna en fil via ett API. Det börjar likna en skrivbordsmiljö, fast serverad genom en krypterad tunnel. Om du vill förstå hur ett sådant klient-server-upplägg skalar kan matematiken bakom lastbalansering vara en bra fortsättning.

De befintliga alternativen löser redan halva problemet

Innan du bygger ett helt nytt skal är det värt att veta vad som redan finns, för mycket av det fungerar bra. X11-vidarebefordring (`ssh -X`) är det klassiska svaret. Den skickar ett grafiskt program som körs på servern och ritar upp fönstret på din lokala skärm. Det fungerar men känns ofta trögt över långsamma anslutningar eftersom X11-protokollet är pratigt och skickar mycket data fram och tillbaka. VNC tar en annan väg och streamar hela skrivbordet som bilder, vilket är enkelt att förstå men bandbreddskrävande. Mosh attackerar ett helt annat problem, nämligen att SSH-sessioner dör när nätet vinglar och håller din terminal levande över dålig uppkoppling men den ger dig fortfarande bara text. Eternal Terminal gör något liknande med automatiska återanslutningar.

Det vanligaste och mest pragmatiska alternativet är sshfs. Den monterar fjärrmaskinens filsystem som om det låg lokalt. Plötsligt kan du öppna filerna i vilket vanligt program du vill, VSCode, en bildredigerare, en textredigerare, utan att fjärrmaskinen behöver veta något om grafik. Det är därför en del utvecklare rycker på axlarna åt idén om ett nytt grafiskt skal, en åsikt som diskuterats livligt på Lobsters och menar att problemet redan är löst.

Men sshfs löser bara filhantering. Det hjälper dig inte att se vilka processer som drar minne, starta om en tjänst med ett klick eller övervaka systemet i realtid. Det är där ett enhetligt grafiskt skal skulle ha ett verkligt värde, inte för att flytta filer utan för allt runtomkring. Så debatten handlar egentligen inte om huruvida tekniken går att bygga, utan om hur mycket den tillför utöver det du redan kan göra med en monterad katalog och dina vanliga verktyg.

SSH-nycklarna är den obekväma delen ingen vill prata om

Ett grafiskt skal ändrar inte grundproblemet med hur du loggar in. SSH-nycklar är långlivade inloggningsuppgifter och till skillnad från lösenord har de ingen inbyggd utgångstid. En nyckel som skapades för fem år sedan fungerar fortfarande i dag om ingen aktivt tagit bort den.

De registrerar heller inte vem som skapade dem eller varför. Nycklar är sällan kopplade till katalog- eller HR-system, vilket gör dem svåra att inventera. När maskiner och automatiska processer nu använder fler nycklar än människor gör växer högen av inloggningsuppgifter som ingen har full koll på. Många organisationer kan inte svara på de enklaste frågorna: vem äger den här nyckeln, varför finns den och borde den finnas kvar. För svenska verksamheter som vill strukturera det arbetet driver CERT-SE, Sveriges nationella CSIRT och MSB:s metodstöd för informationssäkerhet råd som går att luta sig mot. Om du vill ha starkare inloggningar i vardagen har vi också en lösenordsgenerator och hashverktyg på sajten.

Ett vackert grafiskt skal ovanpå en dåligt hanterad nyckelpark gör bara det lättare att komma åt system som kanske inte borde vara åtkomliga alls.

FAQ

Kan man köra grafiska program över SSH i dag?

Ja, med X11-vidarebefordring startar du `ssh -X` och kör ett grafiskt program på servern som ritas upp lokalt. Det fungerar bäst på snabba anslutningar eftersom protokollet skickar mycket data. Över långsamt nät blir det ofta segt och då är VNC eller en monterad katalog med sshfs oftast smidigare.

Varför använder ett webbaserat SSH-skal Unix-domän-socket i stället för en port?

En socket-fil har vanliga filsystemrättigheter, så operativsystemet avgör redan vem som får ansluta. Du slipper öppna en localhost-port och konfigurera vem som får nå den. Åtkomsten blir explicit på filnivå, vilket är enklare att resonera kring säkerhetsmässigt än en öppen port.

Vilken port använder SSH?

TCP port 22 är standard.

Är sshfs bättre än ett grafiskt skal?

För ren filhantering är sshfs oftast tillräckligt, eftersom du kan öppna fjärrfilerna i vilka lokala program du vill. Ett grafiskt skal blir intressant först när du vill göra mer än att flytta filer, som att övervaka processer, starta om tjänster eller läsa systemloggar i ett sammanhållet gränssnitt i stället för via lösryckta terminalkommandon.