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 opsætningen. 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
Hvis dit system ikke kommer med SSH-server- og -klientprogrammer, kan du hente kildeteksten til OpenSSH kan hentes fra http://www.openssh.com/. Bemærk at OpenSSH-udgaver før 3.4 og OpenSSL-udgaver før 0.9.6g har kendte sikkerhedsfejl. [1] Her installationen vist med openssh-3.4 og det fungerer på samme måde med nyeste version.
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 opsætning i /usr/local/etc, men Linux-folk vil oftest gemme opsætning 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 idé 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 løsen i stedet for at bruge en almindelig adgangskode til at logge ind. Det anses for mere sikkert, fordi man ikke kan logge ind på hvilken som helst konto selv om man skulle have skaffet sig den tilhørende adgangskode.
Man kører ssh-keygen som generer en identitetsnøgle, og undervejs kan man hertil selv vælge et løsen – svarende til en adganskode, 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 opsætningsfiler, der styrer ssh opsætningen. Det er kun /etc/ssh/sshd_config, du evt. skal rette i. [2] 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 idé at forbyde root remote login i det hele taget. Tilsvarende kan du forbyde tomme adgangskoder 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 din almindelige adgangskode, 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 din adgangskode, men kun med dit lange og kryptiske løsen.
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: Du bør udelukkende anvende SSH2 (SSH version 2); skriv 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 fjernmaskinen 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 foranstaltning 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 dit løsen og ikke din adgangskode. Bemærk, at i virkeligheden vises dit løsen 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 dit løsen.
[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 løsen. 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 dit løsen i resten af den X session. Brug "ssh-agent" med omtanke.
Tip: Det anbefales at du flytter SSH til en anden port end port 22 - hvis det kun er dig som benytter denne. Den valgte port kan på klienten skrives ind i ~/.ssh/config således at det stadig er nemt at logge ind. Eksempel:
~/.ssh/config:
host tyge
port 22123
host steno
port 955
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, adgangskoder, eller efterfølgende kommandoer i klar tekst - alt er krypteret. Den lille boks i sniffit, som for telnet viste login sekvensen med adgangskoder osv., vil med ssh være fyldt med en bunke tilfældige tegn uden sammenhæng - kun de to SSH-programmer der har etableret forbindelsen 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".
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 ske over SSH-protokollen 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 "hven.sslug.dk" med brugernavnet "tyge" skriver man i URL-feltet fish://tyge@hven.sslug.dk/usr. Har man SSH-adgang til maskinen vil filoversigten blive vist som om det var på egen maskine med fuld mulighed for træk-og-slip-kopiering, -flytning mv.
4.2.6. Epilog
Der er mange forskellige smarte features i ssh, såsom at maskinerne skal acceptere hinandens identitet, brugeres skal accepteres via et løsen, 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 systemvariabel (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.