4.2. Nem og sikker netværkstrafik

Hvis der er risiko for, at andre lytter med på netværkstrafikken, er der behov for erstatningsprogrammer for telnet, ftp og rlogin. Samtidig ønsker vi stadig at kunne afvikle programmer fra en maskine og se resultater på en anden, naturligvis også de grafiske programmer. Med andre ord ønsker vi samme funktionalitet - men med sikkerheden i orden.

Der findes flere sikre alternativer til de gamle, ukrypterede protokoller. Vi vil mest beskæftige os med SSH, men der findes også andre muligheder. Et alternativ til telnet er stelnet, som står for secure telnet. Programmet baserer sig på SSL (Secure Sockets Layer), som er en måde at lave krypterering af datatrafikken. Kombinationen af stelnet og SSL er ikke så udbredt som SSH, og det er ikke så nemt at sætte op som SSH. Programmet stelnet kan findes på http://www.crufty.net/ftp/pub/sjg/ og selve krypteringslaget SSL til Linux kan findes på http://www.psy.uq.oz.au/~ftp/Crypto/. Denne sidste URL har også en hel del dokumentation.

Forhistorien er, at den gamle U.S. version af telnet allerede supporterede TELOPT_AUTHENTICATION og TELOPT_ENCRYPTION, men alle spor af krypteringskoden er fjernet fra den internationalt udbredte og anvendte telnet-kode.

Et andet alternativ til telnet og ftp, som er på vej, er SRP. Se mere om SRP på http://srp.stanford.edu/.

Det, der umiddelbart i dag er det bedste valg som erstatning for telnet og rlogin, er SSH (Secure SHell). Programmet er oprindeligt lavet af et finsk firma med navn SSH Communications Security med hjemmesiden http://www.ssh.fi. SSH har bl.a. den store fordel fremfor stelnet, at grafiske vinduer (XWindow) kan sendes over kryptererede linjer.

Det er et reelt problem, at den oprindelige kommercielle SSH ikke er Open Source, og derfor er der startet et GNU-projekt under navnet PSST for at genskrive koden. Du kan finde mere information om dette på http://www.net.lut.ac.uk/psst. PSST's hjemmeside bør følges fra tid til anden, men status i øjeblikket (April 2003) er en fungerende version 1.5.1, og den siges at fungere sammen med OpenSSH. LSH kører kun ssh-protokol version 2, men roser sig af at have god kryptering og bedre random-generator for maskiner uden /dev/random. For at køre sammen med ssh kræves nogle scripts, fordi filformater for nøglefiler ikke er det samme.

En anden implementation af SSH-protokollen er OpenSSH, som er fri og er lavet af OpenBSD-folkene. Et separat hold programmører sørger for at lave en version for andre platforme, den portable version. OpenSSH er allerede lagt ind i OpenBSD-distributionen, der har ry for at være særdeles sikker. OpenSSH er ligeledes at finde i de fleste Linux-distributioner. Hjemmesiden for OpenSSH er http://www.openssh.com/. OpenSSH er baseret på OpenSSL, som skal oversættes først (hvis man vil bygge sin egen) Læs den medfølgende dokumentation, da der er nogle options for library generation, som ikke er helt trivielle. Den kan hentes under "support" samme sted, som OpenSSH findes, eller direkte fra http://www.openssl.org/. Man kan enten oversætte programmerne selv eller installere de allerede oversatte RPM-pakker.

OpenSSH er en godt projekt. Den omfatter en server, en klient og omfattende dokumentation af konfigurationen. Den kan køre protokol version 2 og version 1. Hvis den er konfigureret til det, kan den endda starte rsh op, hvis alt andet fejler. Der er glimrende support fra OpenBSD teamet og det virker. Der er versioner af OpenSSH til alle Unix varianter også Linux, så i praksis er der ingen grund til at vælge den kommercielle SSH længere i forhold til OpenSSH.

Har du problemer med SSH, så læs http://sysadmin.oreilly.com/news/sshtips_0101.html. Der er et par gode råd.

4.2.1. Installation af OpenSSH

OpenSSH kan hentes fra http://www.openssh.com. Version bør være højere end 3.4 og openssl bør være nyere end 0.9.6g, hvis man vil undgå sårbarhed for buffer overflow.

Du kan hente tar-filer, som du selv kan oversætte, eller du kan få OpenSSH som RPM-filer. Som RPM-filer, skal du bruge openssh-*.i386.rpm, openssh-clients-*.i386.rpm og openssh-server-*.i386.rpm, hvor * betyder et versionsnummer, såsom 3.4.0. Du skal også bruge zlib, som sikkert allerede er installeret på din Linux-maskine. Er dette ikke tilfældet (se om du får fejl), så kan dette bibliotek hentes fra http://www.freesoftware.com/pub/infozip/zlib/. Igen kan du vælge mellem tar-filer og RPM.

OpenSSH anvender OpenSSL - et værktøj der implementerer Secure Socket Layer (SSL) til at lave stærk kryptering af transportlaget.

Fra RedHat-7.0 og senere er ssh en del af normal installation; det samme gælder de fleste andre Linux distributioner.


[tyge@hven ~]# su
[root@hven /home/tyge]# rpm -ivh zlib-1.1.3-i386.rpm
[root@hven /home/tyge]# rpm -ivh openssl-0.9.6g-i386.rpm
[root@hven /home/tyge]# rpm -ivh openssh-3.4-1.i386.rpm
[root@hven /home/tyge]# rpm -ivh openssh-clients-3.4-1.i386.rpm
[root@hven /home/tyge]# rpm -ivh openssh-server-3.4-1.i386.rpm

For at undgå de vanvittig lange indtastninger bruger man selvfølgelig tabulator tasten, når man har tastet de første par tegn ind, idet shell'en selv kan finde resten af filnavnet. Hvis der er flere filnavne der ligner, så taster man lidt flere tegn, og så igen tabulator.

Installerede du på denne måde, kan du springe det næste over og gå direkte frem til at generere bruger-nøgler med ssh-keygen. Vil du installere via tar-filer, så er det ret nemt, men der er et par skridt du skal igennem.

Først "zlib", hvis dette ikke er installeret (tjek om /usr/lib/libz.so findes).


[tyge@hven ~]# su
[root@hven /home/tyge]# tar xzvf zlib-1.1.3.tar.gz
[root@hven /home/tyge]# cd zlib-1.1.3
[root@hven zlib-1.3]# ./configure
[root@hven zlib-1.3]# make
[root@hven zlib-1.3]# make install

Dernæst skal OpenSSL installeres. Den har en variant af configure. Den er bl.a. god til at kryds-kompilere. Det nemmeste er at bruge kommandoen ./config idet den foretager bestemmelse af maskintype og system, og derefter starter ./Configure.


[tyge@hven ~]# su
[root@hven /home/tyge]# tar xzvf openssl-0.9.6g.tar.gz
[root@hven /home/tyge]# cd openssl-0.9.6g
[root@hven openssl-0.9.6g]# ./config
[root@hven openssl-0.9.6g]# make
[root@hven openssl-0.9.6g]# make install

Og slutteligt skal OpenSSH oversættes og installeres


[tyge@hven ~]# su
[root@hven /home/tyge]# tar xzvf openssh-3.4.tar.gz
[root@hven /home/tyge]# cd openssh-3.4
[root@hven openssh-3.4]# ./configure --sysconfdir=/etc/ssh
[root@hven openssh-3.4]# make
[root@hven openssh-3.4]# make install
[root@hven openssh-3.4]# make host-key

Det er normalt at OpenSSH vil installere konfiguration i /usr/local/etc, men Linux-folk vil oftest gemme konfiguration til SSH i /etc/ssh - dette gøres med option sysconfdir (og to minusser foran).

Kommandoen make host-key installerer RSA og DSA nøgler for din maskine. RSA anvendes af SSH version 1, mens DSA er en nyere version, der anvendes i SSH2 protokollen.

Vi mangler stadig få ting, hvis du har oversat SSH selv (ikke ved RPM). Mange Linux-systemer anvender PAM til at styre login på maskinen. For Red Hat og SuSE skal du kopiere den generelle PAM-ssh fil til /etc/pam.d under navnet sshd. Samme ide anvendes nok af de andre store Linux-distributioner.


[tyge@hven ~]# su
[root@hven /home/tyge]# cp contrib/sshd.pam.generic /etc/pam.d/sshd

Har du oversat OpenSSH selv, mangler du stadig et start/stop script, som kan starte OpenSSH efter reboot. Som regel finder man et af de simple start/stop scripts i /etc/init.d og kopierer, retter til. I OpenSSH distributionen er der nogle eksempler på start/stop-scripts. Du kan for SuSE kopiere


[root@hven openssh-3.4]# cp contrib/rc.config.sshd /etc/rc.config.d/sshd.rc.config

og for Red Hat


[root@hven openssh-3.4]# cp contrib/rc.config.sshd /etc/init.d/sshd
[root@hven openssh-3.4]# chkconfig --level 234 sshd on
[root@hven openssh-3.4]# # eller bare 
[root@hven openssh-3.4]# chkconfig sshd on

For SuSE skal du nok rette i filen en sti fra /usr/sbin over til /usr/local/sbin.

Nu skal vi prøve at start SSH dæmonen "sshd", så man kan logge ind på maskinen udefra. For Red Hat køres


[root@hven openssh-3.4]# /etc/init.d/sshd start

eller


[root@hven openssh-3.4]# service sshd start

og tilsvarende for SuSE køres


[root@hven openssh-3.4]# /sbin/init.d/sshd start

Tjek at SSH dæmonen (dvs. serveren) kører ved at skrive telnet localhost 22


Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'.
SSH-1.99-OpenSSH_3.4

4.2.2. Brugeropsætning af OpenSSH

Hver bruger skal have sit eget sæt af privat/offentlig nøgle. Den private må aldrig sendes via netværk, idet den kan dekryptere datatrafik. Den offentlige nøgle anvendes til at kryptere data med, og den kan man så distribuere til andre maskiner, man skal kunne logge ind på.

Den fjerne maskine (remote-maskinen) kan nu kryptere trafikken på en måde, så kun os, der udleverede den offentlige nøgle, kan afkryptere datastrømmen. Dertil bruger vi naturligvis den private nøgle. Det er derfor, denne privat-nøgle ikke må gå over nettet.

Brugeren kan selv generere nøgler til login med pass-phrase i stedet for anvendelse af almindeligt password login. Det anses for mere sikkert, fordi man ikke kan logge ind på hvilken som helst konto selv om man skulle have skaffet sig det tilhørende password.

Man kører ssh-keygen som generer en identitets-nøgle, og undervejs kan man hertil selv vælge en "pass-phrase" - svarende til et password, men et, som kan være meget langt. Lav det tilpas kryptisk, dog på en måde, så du har nemt ved at huske det.


[tyge@hven ~]$ ssh-keygen -d 
Generating DSA parameter and key.
Enter file in which to save the key (/home/tyge/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): V1 hANDLER me spaghett1
Enter same passphrase again: V1 hANDLER me spaghett1
Your identification has been saved in /home/tyge/.ssh/id_dsa.
Your public key has been saved in /home/tyge/.ssh/id_dsa.pub.
The key fingerprint is:
ea:20:20:ae:b3:39:6f:d9:1b:a2:ef:02:0c:05:c5:fb tyge@hven

Når du kører ssh-keygen spørges du om du vil gemme i default stedet /home/tyge/.ssh/id_dsa. Dette giver dig mulighed for at have mere end et sæt nøgler. Din private nøgle gemmes i $HOME/.ssh/id_dsa (for DSA nøglen). Tilsvarende er den offentlige nøgle gemt med samme filnavn med et ".pub" tilføjet.

Lad os først se på et par af de filer, der blev installeret. Der er kommet filer tre steder. (1) /etc/ssh, (2) /etc/init.d/, (3) /usr/sbin/sshd og så også i hjemmekataloget, ~/.ssh .


[tyge@hven ~]$ ls -al /etc/ssh/*
-rw-r--r-- 1 root root  932 okt  6 00:09 ssh_config
-rw------- 1 root root  668 okt 11 01:33 ssh_host_dsa_key
-rw-r--r-- 1 root root  604 okt 11 01:33 ssh_host_dsa_key.pub
-rw------- 1 root root  529 okt 11 01:33 ssh_host_key
-rw-r--r-- 1 root root  333 okt 11 01:33 ssh_host_key.pub
-rw------- 1 root root 1194 okt  6 00:09 sshd_config      

Filerne /etc/ssh/* er konfigurationsfiler, der styrer ssh opsætningen. Det er kun /etc/ssh/sshd_config, du evt. skal rette i. [1] F.eks. kan du ændre "PermitRootLogin yes" til "PermitRootLogin no", hvis du mener, at root ikke må logge ind via ssh. Det kan være en god ide at forbyde root remote login i det hele taget. Tilsvarende kan du forbyde tomme passwords ved at ændre "PermitEmptyPasswords yes" til "PermitEmptyPasswords no" - vent lige med at lave disse ændringer til du har fået ssh til at virke.

Vi skal også lige nævne, at ssh forbindelser normalt ikke styres via inetd-systemet, som du i øvrigt kan finde beskrevet tidligere i Kapitel 2. Grunden er, at det ville være for langsomt, idet der ved opstart af sshd skal genereres en server-nøgle. Dette kan tage flere sekunder for hver opstart.

4.2.3. Brug af SSH

Hvis sshd er startet op, er alt klar til at kommunikere sikkert, også over usikre netværk. Start med at skrive


[tyge@hven ~]$ ssh bohr
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?          

Første gang du kobler til en fremmed maskine, der ligeledes har fået installeret ssh, skal ssh acceptere at udveksle nøgler med en ukendt maskine. Dette spørgsmål skal du således acceptere, og næste gang du anvender samme fremmede maskine, skal du ikke igennem dette spørgsmål. Efter at have svaret "yes" skal du aflevere dit almindelige password, og du er så logget ind på maskinen. Dette kan du fortsætte med, men hvis du vil højne sikkerheden yderligere, bør du gemme din offentlige nøgle på fjernmaskinen. Har du denne nøgle gemt, kan man ikke logge ind med dit password, men kun med din lange og kryptiske passphrase.

Hvis du ikke fik adgang til maskinen, så kan der være flere grunde. Enten kan det skyldes, at du bruger den forkerte protokol. Nyere versioner af OpenSSH kan både køre SSH version 1 og 2. Version 2 og DSA-nøglen hænger sammen som nævnt ovenfor.


[tyge@hven ~]$ ssh -2 tuck@bohr

I dette eksempel tvinges OpenSSH til at anvende SSH version 2, og brugeren tyge prøver at logge ind på maskinen bohr med brugernavn tuck.

Tip: Hvis du permanent vil anvende SSH2 (SSH version 2), så kan du skrive følgende ind i din ~/.ssh/config


# Tillad også grafiske programmer gennem SSH-forbindelse
ForwardX11 yes
# Anvend SSH2-identitet
IdentityFile ~/.ssh/id_dsa
# Anvend SSH2-protokol
Protocol 2
# Komprimer forbindelsen
compression yes

Log ud ved at skrive exit (eller trykke Ctrl-D) for at komme tilbage til din egen maskine. Kopier nu din public key fra din egen maskine (hven) til fjern maskinen og gem den under ~/.ssh/authorized_keys (for SSH1, dvs. RSA nøglen) og ~/.ssh/authorized_keys2 (for SSH2, dvs. DSA nøglen). Ingen andre end dig skal kunne læse den fil du laver. Denne kopiering laver vi med en ny kommando "scp" (secure copy) eller beder systemadministratoren at lægge filen ind hvis du ikke kan få adgang.


[tyge@hven ~]$ cd ~/.ssh
[tyge@hven .ssh]$ scp id_dsa.pub bohr:authorized_keys2

Nu skal du lave den sidste opsætning på bohr. Du laver kataloget ~/.ssh, hvor du gemmer din offentlige nøgle, og sikrer, at andre ikke kan læse denne. Dit hjemmekatalog skal andre heller ikke have lov til at skrive i - denne foranstantning er altid klog, men det er også nødvendig for at din offentlige nøgle "id_dsa2.pub" virker efter, at den er kopieret til fjernmaskinens "authorized_keys2". Det er en egenskab ved ssh.


[tyge@hven ~]$ ssh bohr
[tyge@bohr tyge]$ mkdir ~/.ssh
[tyge@bohr tyge]$ mv authorized_keys ~/.ssh
[tyge@bohr tyge]$ chmod go-w ~
[tyge@bohr tyge]$ chmod -R go-rwx .ssh
[tyge@bohr tyge]$ exit

4.2.4. Krypteret dataoverførsel

Nu kan du slappe af. Alt er sat op, og du kan uden at skulle frygte for netværkssikkerheden logge ind på bohr. F.eks. kan du starte et grafik program såsom "xload" ved at skrive


[tyge@hven ~]$ ssh bohr xload
Enter passphrase for RSA key 'tyge@bohr': V1 hANDLER me spaghett1

Du blev nu mødt af noget nyt igen, idet du skulle skrive din passphrase og ikke dit password. Bemærk, at i virkeligheden vises din passphrase naturligvis ikke på skærmen. xload vil nu køre fra bohr og vises på din egen maskine (hven). Skal du logge ind på bohr, så skriver du blot "ssh bohr", og skal du have udført et program derfra, tilføjer du blot programnavnet til denne ordre.

Skal du kopiere en fil fra hven til bohr, skriver du


[tyge@hven ~]$ scp LOKALT_FILNAVN bohr:FJERN_FILNAVN

Tilsvarende erstattes ftp med sftp, og scp erstatter rcp (remote copy), som arbejder med samme syntaks.

Hvis du ikke frygter, hvem der kan tilgå din egen maskine, kan du få endnu nemmere adgang til de andre maskiner ved, at du en gang for alle i den X session, du har igang, giver din passphrase.


[tyge@hven ~]$ ssh-agent bash
[tyge@hven ~]$ ssh-add ~/.ssh/id_dsa
Enter passphrase for /home/pto/.ssh/id_dsa:

Derefter kan du med ssh fra den terminal logge ind og ud af "bohr" og andre ssh maskiner uden at skulle bruge passphrase. Vil du have at alle terminal-vinduer skal kunne dette, skal du rette i din "~/.xsessionrc", "~/.xinitrc" eller lignende, hvor din window manager startes op. Er det f.eks. KDE, skal du ændre "startkde" til "ssh-agent startkde" og kun en enkelt gang køre "ssh-add". Derefter kan du slippe for at indtaste din passphrase i resten af den X session. Brug "ssh-agent" med omtanke.

En af de (mange) meget elegante ting man kan med SSH (og OpenSSH) er at lave en sikker krypteret tunnel gennem en firewall og endda kunne transmittere grafiske programmer (X-programmer). Skal man administere servere (evt. via grafiske programmer) på et lukket netværk er en SSH-server i firewallen yderside en god måde at give adgang til netværket hjemmefra (husk dog at følge sikkerhedslisten for den SSH-variant der installeres). For at grafiske programmer kan transmitteres fra en maskine til en anden via SSH, kræves at man har programmet xauth installeret.

Anvender du ssh, kan andre med sniffit se, at der laves kommunikation på port 22, men prøver de at følge netværkstrafikken, kommer der ikke login navne, passwords, eller efterfølgende kommandoer i klar tekst - alt er krypteret. Den lille boks i sniffit, som for telnet viste login sekvensen med passwords osv., vil med ssh være fyldt med en bunke tilfældige tegn uden sammenhæng - kun ssh selv kan i praksis afkode kommunikationen.

Lad os vende tilbage til sniffit og se, hvad der med ssh kommer over netværket under login via ssh. På næste billede kan vi se, at port 22 på bohr modtager tekst, der er krypteret og dermed ikke læseligt for andre. Igen er det "sniffit -F eth0 -i", som køres. Derefter har vi valgt at følge den linje fra 192.168.0.1, som kommer ind via port 22 til 192.168.0.2. I det lille vindue kan du se resultatet af vilkårlige og almindelige Linux-kommandoer - i dette tilfælde "ls -al /home".

Figur 4-4. Sniffit

Endelig kan det nævnes at følgende link giver en god gennemgang af SSH http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/custom-guide/s1-openssh-client-config.html.

4.2.5. Brugervenlighed

Som det er beskrevet ovenfor så bør kommunikation mellem maskiner baseres på OpenSSH hvor det er muligt. Det er et tekst-baseret program hvor man kan logge ind på en fjernmaskine og udføre kommandoer - men det er ikke hele historien. Man kan også sætte OpenSSH op til at køre grafiske programmer eller få andre programmer til at bruge OpenSSH til at danne en krypteret kanal mellem maskinerne og mellem maskinerne køre alle programmer transparent. Med Konqueror til KDE kan man f.eks. installere en lille udvidelse med navn fish http://ich.bin.kein.hoschi.de/fish/. Normalt angiver man i URL-feltet til Konqueror at man vil ser filerne i /usr/ som file:/usr/. Vil man se filerne i kataloget /usr/ på maskinen www.sslug.dk med bruger-ID "anne" skriver man i URL-feltet fish://anne@www.sslug.dk/usr. Har man OpenSSH adgang til maskinen vil filoversigten blive vist som om det var på egen maskine med fuld mulighed for drag-and-drop kopiering og flytning mv.

Figur 4-5. fish giver direkte adgang til filer på andre maskiner via sikker ssh-krypteret tunnel

4.2.6. Epilog

Der er mange forskellige smarte features i ssh, såsom at maskinerne skal acceptere hinandens identitet, brugeres skal accepteres via en passphrase, og en gang hver time vil maskiner endda skifte nøgler, så en eventuel ondsindet person, som vil lytte med skal begynde forfra i dekodning af krypterings-nøgler.

Vi skal også nævne, at ssh kan anvendes til at lave VPN løsninger (Virtual Private network) mellem to lokale netværk, der forbindes via et usikkert net. Skal man køre revisionssystemer på Linux, kan vi anbefale CVS, som drager nytte af ssh til at skabe krypteret tilgang til ens server. Det er kun en environment variabel (sæt $CVS_rsh=ssh), så kører det. Tilsvarende kan rsync kobles med ssh (sæt $RSYNC_rsh=ssh) for at lave synkroniseret data mellem flere maskiner, hvor dataudveksling sker med secure shell.

Ud over Linux (UNIX) server og klient programmer, som er indeholdt i ssh-pakken, så kan du måske også have glæde af klienter til Windows.

Med en af disse kan du fra en Windows maskine logge sikkert ind på din Linux-maskine. Du kan på hhv. http://www.chiark.greenend.org.uk/~sgtatham/putty/, http://www.mindbright.se/mindterm. Der findes også en kommerciel Windows ssh-version, som kan købes fra http://www.datafellows.com.

Slutbemærkning:

[1]

Hvis du har installeret fra source-tar-balls er disse filer default lagt i /usr/local/etc