9.2. Fjärrinloggning

Det är viktigt för administratörer att kunna ansluta till en fjärrdator. Avskärmade servrar har sällan permanenta tangentbord och skärmar - men de är anslutna till nätverket.

9.2.1. Säker fjärrinloggning: SSH

Protokollet SSH (Secure SHell) togs fram med säkerhet och pålitlighet i åtanke. Anslutningar med SSH är säkra; användaren är autentiserad och all data utbyts krypeterat.

ORDFÖRRÅD Autentistering, kryptering

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

Autentisering och kryptering näms ofta ihop eftersom de vanligtvis används tillsammans, och eftersom de båda implementeras med liknande matematiska koncept.

SSH erbjuder två filöverföringstjänster. scp är ett kommandoradsverktyg som kan användas liknande kommandot cp förutom att sökvägar till en annan maskin inleds med maskinens namn, följt av kolon.

$ scp fil maskin:/tmp/

sftp är ett interaktivt kommando som liknar ftp. sftp kan överföra flera filer i en enda session, och det är möjligt att manipulera fjärrfiler med det (ta bort, byta namn, ändra behörigheter och så vidare).

Debian använder OpenSSH, en fri version av SSH underhållen av projektet OpenBSD (ett fritt operativsystem baserat på BSD-kärnan, fokuserat på säkerhet) och en gren av den ursprungliga SSH-programvaran utvecklad av företaget SSH Communications Security Corp, Finnland. Företaget utvecklade ursprungligen SSH som fri programvara, beslöt sig eventuellt att fortsätta utvecklingen under en sluten licens. OpenBSD-projektet skapade sedan OpenSSH för att bevara en fri version av SSH.

GRUNDERNA Grenar

I programvaruvärlden innebär en ”gren” att ett nytt projekt startar som en klon av det ursprunliga, och att det kommer att tävla med det. Därifrån kommer båda program att snabbt divergera vad gäller utveckling. En gren är ofta resultatet av meningsskiljaktigheter inom utvecklingsteamet.

Valet att grena ett projekt är ett direkt resultat av själva naturen i fri programvara; en gren är hälsosam när det låter projektet fortsätta att vara fri programvara (exempelvis om det sker licensändringar). En gren som tillkommer av tekniska eller personliga skäl är ofta ett slöseri med mänskliga resurser; en annan lösning vore önskvärd. Det händer att två projekt som tidigare delats i flera grenar åter sammanfogas.

OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. Nyckelbasera autentisering

Varje gång någon loggar in över SSH, frågar fjärrservern efter ett lösenord för att autentisera användaren. Det kan vara problematiskt om du vill automatisera en anslutning eller om du använder ett verktyg som återkommande kräver anslutningar till SSH. Därför erbjuder SSH ett nyckelbaserad autentiseringssystem.

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

SÄKERHETSkydda den privata nyckeln

Alla som har den privata nyckeln kan logga in på det inloggade kontot. Det är därför åtkomst till den är skyddad av en ”lösenfras”. Någon som kommer åt en kopia av en privat nyckelfil (exempelvis ~/.ssh/id_rsa) måste fortfarande veta denna fras för att kunna använda den. Detta ytterligare skydd är inte ogenomträngbart, och om du tror att filen har komprometeras är det bäst att inaktivera nyckeln på datorer i vilken den har installerats (genom att ta bort den från authorized_keys) och ersätta dem med en ny genererad nyckel.

KULTUR OpenSSL-svaghet i Debian Etch

OpenSSL-biblioteket, ursprungligen tillhandahållet i Debian Etch, hade ett allvarligt problem med dess slumptalsgenerator (RNG). Debianansvarige hade gjort en ändring så att program som använder det inte längre genererade varningar vid analys utförda av minnestestverktyg som valgrind. Tyvärr innebar ändringen också att RNG endast använde en entropikälla, motsvarande processid (PID) vars 32 000 möjliga värden inte erbjuder nog med slumpmässighet.

→ https://www.debian.org/security/2008/dsa-1571

Mer specifikt så gäller att när OpenSSH användes för att generera en nyckel producerade den alltid en nyckel inom en känd mängd av hundratusentals nycklar (32 000 gånger ett litet antal nyckellängder). Det påverkade SSH-nycklar, SSL-nycklar och X.509-certifikat använda att otaliga program, som OpenVPN. En cracker behövda endast prova alla nycklar för att få obehörig tillgång. För att minska problemets omfattning ändras SSH-demonen till att vägra använda problematiska nycklar som listades i paketen openssh-blacklist och openssh-blacklist-extra. Utöver det så gör kommandot ssh-vulnkey det möjligt att identifiera möjligen komprometerande nycklar i systemet.

En noggrannare analys av denna incident visar det är resultatet av flera (mindre) problem, både med OpenSSL-projektet och med Debianpaketets ansvariga. En välanvänt bibliotek som OpenSSL borde -- utan ändringar -- inte generera varningar under testning valgrind. Vidare bör koden (speciellt känsliga delar som RNG) vara bättre kommenterad för att förhindra sådan fel. Vad gäller Debian ville ansvariga validera ändringarna med OpenSSL-utvecklarna, men förklarade ändringarna utan att skicka in en programfix för granskning, och nämnde inte sin roll inom Debian. Slutligen var lösningsvalet inte det bästa: ändringarna gjorde i originalkoden blev inte dokumenterade; alla ändringar lagrades i ett Subversion-förråd, men slutade ihopklumpade in en programfix då källpaketet skapades.

Det är under dessa förhållanden svårt att förhindra sådana incidenter från att uppstå. Sens moral är att varje avvikelse Debian tillför i program uppströms måste vara berättigad, dokumenterad, insänd till uppströmsprojektet om möjligt, och vida publicerad. Det är utifrån detta perspektiv som det nya paketformatet (”3.0 (quilt)”) och webtjänsterna för Debiankällor utvecklades.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Avsnitt 10.2.2, ”Publik nyckelinfrastruktur easy-rsa”) by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Both, public key and certificate authentication, can be used alongside each other.

9.2.1.3. Använda X11-fjärrprogram

SSH-protokollet gör det möjligt att vidarebefordra grafiskt innehåll (”X11-session”, namngiven från det mest välanvända grafiksystemet i Unix); servern håller då reda på en dedikerad kanal för denna data. Det innebär att ett grafiskt program som fjärrexekveras kan visas på X.org-servern lokalt, och att hela sessionen (inmatning och visning) är säker. Eftersom denna egenskap låter fjärrprogram komma åt det lokala systemet är det inaktiverat som standard. Du kan aktivera det genom att ange X11Forwarding yes i serverns konfigurationsfil (/etc/ssh/sshd_config). Slutligen måste användare också begära den genom att lägga till flaggan -X kommandoraden för ssh.

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

9.2.1.4. 'Skapa krypterade tunnlar med portvidarebefordring

Flaggorna -R och -L gör att ssh kan skapa ”krypterade tunnlar” mellan två maskiner och på ett säkert sätt vidarebefodra en lokal TCP-port (se sidopanelen TILLBAKA TILL GRUNDERNA TCP/UDP) till en en fjärrmaskine och vice versa.

ORDFÖRRÅD TUNNEL

Internet och de flesta LAN som är anslutna till det körs i paketläge och inte i anslutet läge, vilket betyder att ett paket skickat från en dator till en annan kommer att stoppas vid flera mellanliggande routrar för att finna vägen till destinationen. Du kan fortfarande simulera en ansluten operation där strömmen kapslas in i normal IP-paket. Dessa paket följer sina vanliga rutter, men strömmen rekonstrueras oförändrad vid destinationen. Vi kallar detta en ”tunnel”, analogt med en vägtunnel där fordon kör direkt in i ingången (indata) till utgången (utdata) utan att träffa på intersektioner, i motsats till en en sökväg på ytan som skulle involvera intersektioner och ändrade riktningar.

Du kan ta detta tillfälle i akt till att lägga till kryptering till tunneln: strömmen som flödar genom den kan inte tolkas utifrån; men återfås dekrypterat i slutet av tunneln.

ssh -L 8000:server:25 mellanhand etablerar en SSH-session med värden mellanhand och lyssnar på lokala porten 8000 ( se Figur 9.3, ”Vidarebefordra en lokal port med SSH”). För varje anslutning etablerad på denna på denna port, kommer ssh att starta en anslutning från datorn mellanhand till port 25 på server, och kommer att binda samman alla anslutningar tillsammans.

ssh -R 8000:server:25 mellanhand etablerar också en SSH-session till datorn mellanhand, men på denna maskin lyssnar ssh till port 8000 (se Figur 9.4, ”Vidarebefordra en fjärrport med SSH”). Varje anslutning etablerad på denna port kommer också att få ssh att öppna en anslutning från den lokal maskinen till port 75 på server, och att binda ihop anslutningarna.

I båda fallen sker anslutningarna över port 25 på värden server som passerar genom SSH-tunneln etablerade mellan den lokala maskinen och maskinen mellanhand. I det första fallet är ingången till tunneln lokal port 8000, och datan flyttar mot maskinen mellanhand innan den riktas mot server på det ”publika” nätvärket. i det andra fallet har indata och utdata för tunneln kastats om; ingången är port 8000 på maskinen mellanhand, utgång är på den lokala värden och datan vidarebefordras till server server. I praktiken är servern antingen den lokala maskinen eller mellanhanden. På det sättet säkrar SSH anslutningen från en sida till en annan.

Figur 9.3. Vidarebefordra en lokal port med SSH

Figur 9.4. Vidarebefordra en fjärrport med SSH

9.2.2. Använda grafiska fjärrskrivbord

VNC (Virtual Network Computing) tillåter fjärråtkomst till grafiska skrivbord.

Detta verktyg används mest för teknisk assistans; administratören kan se felen som användare möter, och visa dem den rätta åtgärden utan att vara fysiskt närvarande.

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

SÄKERHET VNC över SSH

Om du vill ansluta genom VNC, och du inte vill att dina data skickar okrypterade över nätverket så är det möjligt att kapsla in datan i en SSH-tunnel (se Avsnitt 9.2.1.4, ”'Skapa krypterade tunnlar med portvidarebefordring”). Du behöver endast då veta att VNC använder port 5900 som standardport för den första skärmen (kallad ”localhost:0”), 5901 för den andra (kallad ”localhost:1”) också vidare.

Kommandot ssh -L localhost:5901:localhost:5900 -N -T maskin skapar en tunnel mellan lokala porten 5901 och port 5900 hos värdmaskin. Den första ”localħost” begränsar SSH till att endast lyssnar på det gränssnittet (på den lokala maskinen. Den andra ”localhost” är gränssnittet på fjärrmaskinen som ska ta emot nätverkstrafiken som kommer in från ”localhost:5901”. Sålunda kommer vncviewer localhost:1 att ansluta VNC-klienten till fjärrskärmen, även fast du bara indikerar namnet på den lokala maskinen.

När VNC-sessionen stängs, kom ihåg att stänga tunneln genom att också avsluta motsvarande SSH-session.