Skåne Sjælland Linux User Group - http://www.sslug.dk Förstasida   Anmälning   Postarkiv   Översikt   Kalender   Sök
 

Remote login og netværksaflytning

Artikel 4 - Sikkerhed på Linux

Hanne Munkholm <hanne@geekgirl.dk> og Peter Toft <pto@sslug.dk>


Take One!
Forfatterne har copyright på artiklen, men udgiver den under OpenContent License.
Alle kan trykke artiklen så længe OPL licensen overholdes, men vi vil gerne vide hvor den bringes.

Licensen, der skal overholdes, kan findes på http://www.opencontent.org/opl.shtml.


Denne artikel er en del af en artikel serie om netværkssikkerhed, som kan findes på http://www.sslug.dk/artikler/Linux_sikkerhed

En af de store styrker ved en Linux (UNIX) maskine er, at man kan administrere den fra en anden maskine via netværk. For at være kompatibel med alle andre UNIX varianter følger de gode gamle værktøjer telnet og ftp med i Linux distributionerne, og de er meget anvendte til fjernadministration. Vi vil i denne artikel se på, hvorfor værktøjer som telnet og ftp ikke bør anvendes, hvis maskinen er koblet til Internet eller et andet usikkert netværk. Vi skal se på, hvordan netværkstrafik kan aflyttes. Derefter skal vi se nærmere på alternativer til telnet og ftp, hvor datastrømmen bliver krypteret. Specielt fokuserer vi på ssh (secure shell) og viser installation og anvendelse. Meget af det, der beskrives i artiklen, gælder ikke blot for Linux, men også for andre UNIX'er.

Nem men usikker netværkstrafik

Fra en Linux-maskine kan man nemt logge ind på en anden Linux-maskine og køre programmer, endog grafiske programmer. Dermed kan man køre tunge programmer på en stærk server og få vist resultater på en anden (måske langsommere) maskine.

Antag, at vi har et lokalnet bestående af tre maskiner. Vi anvender maskinen "sherwood" (IP adresse 192.168.0.1) med brugernavnet robin, men vi vil køre programmer fra maskinen "locksley" (192.168.0.2). I netværket finder vi desuden maskinen "nottingham" (192.168.0.3), som vi leger er en ondsindet maskine, der ønsker at bryde vores sikkerhed. I praksis kunne det være tre maskiner på Internet, hvor netværkstrafik mellem "sherwood" og "locksley" tilfældigvis også kommer forbi "nottingham".

Resten af artiklen vil handle om programmer til remote login, som telnet, rlogin og ssh, samt programmer til filoverførsel (ftp og scp). Men hvad bruges det til? Med remote login kan man udføre tekstkommandoer på den maskine, man er logget ind på, men man kan også køre X-programmer over nettet.

telnet og xhost

Hvis du på sherwood kører en X-baseret grafisk brugergrænseflade, og du vil køre X-programmer (grafiske programmer) fra maskinen locksley, skal du starte med at fortælle sherwood, at det er i orden, at locksley benytter dens display. Dette gøres ved at føje locksley til listen over godkendte hosts med kommandoen xhost:

[robin@sherwood robin]$ xhost + locksley
locksley being added to access control list 
Dermed vil grafiske programmer fra locksley vil blive accepteret af sherwood. Udelades maskinnavnet, betyder det, at alle maskiner kan vise grafik på din skærm. Lad være med det, da det sikkerhedsmæssigt er en dårlig ide.

Lad os nu logge ind på locksley med telnet,

[robin@sherwood robin]$ telnet locksley
Trying 192.168.0.2...
Connected to locksley.herne.dk.
Escape character is '^]'.
Debian GNU/Linux 2.1 locksley.herne.dk

locksley login: robin
Password:

Efter at have skrevet loginnavn og password på locksley maskinen får du en kommandolinie, og du kan udføre programmer på maskinen, som om du var logget ind lokalt.
For at kunne få de grafiske programmer, du starter på locksley, til at vise sig på sherwoods skærm er det nødvendigt at sætte DISPLAY environment variablen:
[robin@sherwood robin]$ export DISPLAY=sherwood:0.0
Mange X-programmer kan dog også kaldes med "-display" som option.

Nu kan du køre dit X-program, f.eks. "xload", som om du sad på locksley. Programmet kører på locksley, men alt grafik vises på sherwood, og programmet styres fra sherwood.

[robin@locksley robin]$  xload -display sherwood:0.0 -geometry 60x60 -nolabel & 
xload

Det er nemt, og allerede ved disse enkle operationer kan du have mistet hele din password-sikkerhed. Sagen er, at da man i sin tid designede telnet tænkte man ikke så meget på sikkerhed, men mere på driftstabilitet. Når man laver telnet fra en maskine til en anden, sender man først sit brugernavn og derefter password. Begge sendes klar tekst. Det kan selvfølgelig udnyttes til at stjæle passwords på Internet - og det gøres!

Pas på passwords sendt over netværk

For at aflytte netværkstrafikken kan man downloade programmet sniffit til Linux. Når det startes op vises alle kommunikationslinier, såsom telnet- og ftp-forbindelser, mellem maskinerne på netværket. Det kommer an på konfiguration af routere, firewalls, switche og hubs, hvor meget man reelt får at se. Sniffit kan downloades fra http://reptile.rug.ac.be/~coder/sniffit/sniffit.html. Sniffit skal køres som root.

Lad os antage, at den ondsindede "nottingham" (192.168.0.3) lytter med på, hvad vi laver mellem "sherwood" (192.168.0.1) og "locksley" (192.168.0.2). Programmet sniffit startes i interactive mode med angivelse af hvilket netværks-interface, der skal lyttes på:

[root@nottingham root]# sniffit -F eth0 -i 
hvor eth0 betyder første ethernet kort i maskinen, og i betyder interactive mode. Ud kommer nedenstående billede, hvor man ser, at maskinen med netværksadresse 192.168.0.1 (sherwood) har oprettet en forbindelse til port 23 på maskinen med netværksadresse 192.168.0.2 (locksley). Port 23 er den port, telnet lytter på. Port 3211, som man sender fra, er valgt blandt maskinens ledige porte, dvs. de porte, der ikke er nogen service, der lytter på. Der er valgt et portnummer, som er større end 1024, dvs. en ikke priviligeret port.

Trykkes return på en linie vil den blive markeret med "*LOGGED*", og det mindre vindue mod højre vil vise trafikken på den forbindelse. Først kommer login navn: "robin", og efter to punktummer kommer passwordet i klar tekst: "qwe123". Der skal ikke stor fantasi til at forestille sig, at dette program nemt kan sættes til at dumpe samhørende loginnavne og passwords ned i en fil over en periode, indtil der er gevinst.

Skærmbillede fra sniffit

Vi har vist, at man ikke skal bruge telnet til at kommunikere mellem to maskiner, hvis der er risiko for, at nogen lytter med, og slet ikke hvis man skal logge ind som root på maskinen. Det er simpelthen for nemt at lede efter loginnavn root og derefter få passwordet. Derfor har mange Linux distributioner per default forhindret, at root logger ind via netværket. Red Hat 6.0, Debian 1.3 og SuSE 6.2 har filen "/etc/securetty", der indeholder de konsoller, hvor root må logge ind. Dette kan være "tty1" til "tty6", som er de tekst login konsoller, der normalt er på selve Linux-maskinen - dvs. ikke via netværket. Hvis man absolut vil tillade root login via netværk, kan man tilføje "0", "1" og opefter (for Linux kerne 2.2.X) svarende til hvor mange logins, du forventer på maskinen fra netværket. Normalt er det ikke klogt at tillade direkte root login via netværk.

ftp

Hvis vi vil overføre filer fra "sherwood" (192.168.0.1) til "locksley" (192.168.0.2), er ftp et af de gennemprøvede og gamle værktøjer. Også her er der sikkerhedsproblemer. Vi sætter igen "nottingham" (192.168.0.3) til at køre sniffit som vist nedenfor. Denne gang sætter vi sniffit op til at vise alle pakker som ankommer til "locksley" (192.168.0.2), og man kan nemt se, hvad der sker.

[root@nottingham root]# sniffit -t192.168.0.2 -a -F eth0  
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1299-192.168.0.2.21
 E . . 4 . . @ . @ . . . . . . . . . . . . . . . . . b . . . . . P . } x i !
 . . U S E R   r o b i n . .

Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1299-192.168.0.2.21
 E . . ( . . @ . @ . . . . . . . . . . . . . . . . . b ( . . . . P . } x . .
 . .

Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1299-192.168.0.2.21
 E . . 5 . . @ . @ . . . . . . . . . . . . . . . . . b ( . . . . P . } x N D
 . . P A S S   q w e 1 2 3 . .

På den første af de tre data-linier kan man se login navn, og som vist på den sidste data-linie, vil man direkte kunne læse passwordet. Ser man lidt nøjere efter, vises også ftp-porten, port 21. Port 1299 er ligesom ved telnet en ledig port, der vælges til denne session.

Som vi ser, er ftp også et meget usikkert program, hvor andre kan lytte med. Så brug det med omtanke. For en systemadministrator er paranoia ikke en sygdom, men en kvalifikation...

Det skal nævnes, at også resten af den nettrafik, du laver med telnet og ftp, kan læses i klar tekst via f.eks. sniffit. Starter du andre programmer, kan man se det. Laver du "su - root" og skriver root-passwordet, er sikkerheden på den maskine væk, for root passwordet er ude, hvis du bliver aflyttet.

Remote login, remote shell og remote copy

To andre velkendte programmer i samme kategori er "rlogin" og "rsh". Programmerne virker næsten ens. Begge giver interaktivt login på maskinen, men rsh kan udføre en kommando samtidig med, at man logger ind. F.eks. vil den følgende kommando logge ind direkte fra sherwood til locksley og køre kommandoen "df" (som viser hvor fyldte dine diske er).

[robin@sherwood robin]$ rsh locksley df

Nu prøver vi at køre sniffit på en rlogin session for at se, hvad man kan se. På maskinen "nottingham" kører vi sniffit:

[root@nottingham root]# sniffit -x -s192.168.0.1 -a -F eth0
Vi logger ind fra sherwood til locksley med kommandoen:
[robin@sherwood robin]$ rlogin locksley
Password:qwe123 
$ 
hvor password'et naturligvis ikke kan ses på skærmen, når man taster det ind. Udklip fra sniffit's output:
TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA41   ACK (hex): 105DA03F
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ? s . @ . @ . F Q . . . . . . . . . . . . . . . A . ] . ? P . } x C .
 . . r o b i n . r o b i n . x t e r m / 9 6 0 0 .     


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA58   ACK (hex): 105DA040
   FLAGS: -A----   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ( s . @ . @ . F g . . . . . . . . . . . . . . . X . ] . @ P . } x } A
 . .


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA58   ACK (hex): 105DA041
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . 4 s . @ . @ . F J . . . . . . . . . . . . . . . X . ] . A P . } x . .
 . . . . s s . . . P . . . l


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA64   ACK (hex): 105DA04B
   FLAGS: -A----   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ( s . @ . @ . F U . . . . . . . . . . . . . . . d . ] . K P . } x } *
 . .


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA64   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F S . . . . . . . . . . . . . . . d . ] . K P . } x . !
 . . q


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA65   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F R . . . . . . . . . . . . . . . e . ] . K P . } x .
 . . w


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA66   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F Q . . . . . . . . . . . . . . . f . ] . K P . } x . .
 . . e


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA67   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F P . . . . . . . . . . . . . . . g . ] . K P . } x L .
 . . 1


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA68   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F O . . . . . . . . . . . . . . . h . ] . K P . } x K .
 . . 2


TCP Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
   SEQ (hex): C2D0BA69   ACK (hex): 105DA04B
   FLAGS: -AP---   Window: 7D78
Packet ID (from_IP.port-to_IP.port): 192.168.0.1.1023-192.168.0.2.513
 E . . ) s . @ . @ . F N . . . . . . . . . . . . . . . i . ] . K P . } x J .
 . . 3

Igen ser man tydeligt brugernavn og password blive sendt ukrypteret over nettet. Man kan se, at rlogin på locksley bruger port 513, og at der på sherwood sendes fra port 1023.

Skal du kopiere filer mellem to maskiner, så er ftp som tidligere skrevet meget anvendt. Alternativt kan remote copy "rcp" anvendes. Skal du kopiere filen ".emacs" fra sherwood til locksley, sker dette med

[robin@sherwood robin]$ rcp .emacs locksley:
Sikkerhedsmæssigt er rcp på linie med rlogin og rsh. Vi skal senere i artiklen vende tilbage til et fuldt krypteret alternativ til rcp.

Med rlogin, rsh og rcp kan man vælge, at login kan ske uden password. Dette gøres ved at sætte sit hostnavn og evt. brugernavn ind i filen "~/.rhosts" i sit hjemmekatalog på den maskine, der skal logges ind på. Hvis du gerne vil kunne logge ind fra sherwood til locksley uden password, som brugeren robin, kan ".rhosts"-filen i dit hjemmekatalog på locksley se sådan ud:

sherwood robin
Der kan godt stå mange flere linier med andre hostnavne. Brugernavnet kan udelades, idet brugeren sættes til den, hvis hjemmekatalog filen ligger i. Hvis filen er læsbar for alle, er det kun en bruger med samme brugernavn som sit eget, der kan logge ind fra en anden maskine. Er filen ikke læsbar for andre, kan man anføre linier i ".rhosts"-filen med først maskinnavn og dernæst det brugernavn, som anvendes på den anden maskine. For at "marian" skal logge på ind på "sherwoord" som "robin", kan man således bruge "rlogin sherwood -l robin".

Den viste ".rhosts"-fil vil betyde, at du fra maskinen sherwood som brugeren robin, godt må komme ind på locksley som robin, uden password. Det kræver, at brugeren findes på begge maskiner, og ".rhosts" filen skal ligge i brugerens hjemmekatalog på den maskine, man prøver at logge ind på. Det er nemt og giver lynhurtig adgang til, at man hopper fra maskine til maskine og laver meget effektive arbejdsgange. Det lyder smart, men medaljen har en bagside. En med root-adgang på maskinen "nottingham" (eller andre maskiner i netværket) kan aflytte rsh/rlogin netværkstrafik et stykke tid, og derved finde ud af fra hvilken maskine og med hvilket bruger navn, man kan logge ind direkte. Derefter kan man med lidt snilde sætte maskinen "nottingham" lidt anderledes op, så "locksley" tror, at den er "sherwood".

Der kan imidlertid være situationer, hvor det kan virke mere sikkert at lade en bruger logge ind uden password fra en kendt host end at lade brugeren have et password. Har man tillid til sit interne netværk, og er det nødvendigt, at nogle brugere kan logge på en udsat maskine, kan man vælge, at disse brugere ikke har noget password på den udsatte maskine. I stedet får de en stjerne ("*") i "/etc/passwd", der hvor passwordet normalt ville stå. Dette vil forhindre dem i at logge ind fra andre maskiner end dem, der er angivet i deres "~/.rhosts" fil i deres hjemmekatalog på den udsatte maskine. Når en bruger ikke har et password, kan man ikke bryde ind på den udefra ved at gætte eller knække passwordet. Men kan kun logge ind som denne bruger, hvis man kan overbevise maskinen om, at man logger ind fra en betroet maskine. Der kan i øvrigt læses mere om passwords beskyttelse og håndtering i Artikel 3 - Root access - hvem, hvordan og hvorfor ikke?.

Hvis man ikke tillader ".rhosts"-filer, vil der ved hver login sendes passwords i klar tekst over nettet. Hvis der er ".rhosts"-filer, bliver der slet ikke sendt passwords over nettet - i stedet for at give sit password skal man logge ind fra en betroet host. Ingen kan nu opsnappe passwords - til gengæld kan de udgive sig for at være den betroede host. Stoler man ikke på sit interne netværk, eller er nogen "sluppet ind", er begge dele nok lige dårligt.

Vi vil anbefale, at man i stedet for rlogin bruger et program, der krypterer login såvel som selve dataoverførslen, som f.eks. ssh giver mulighed for.

Som systemadministrator kan du se om dine brugere har ".rhosts" filer, og hvis det ikke er ønsket, kan du slette dem (og skælde brugeren ud). Hvis brugerne har hjemmekataloger under "/home/", så kan dette gøres med

[root@sherwood root]# find /home/* -maxdepth 1 -name ".rhosts" -print;
Hvis man samtidigt vil slette de fundne .rhosts filer kan man anvende
[root@sherwood root]# find /home/* -maxdepth 1 -name ".rhosts" -print -exec rm {} \;
Det er enklere at disable brugernes egne ".rhosts"-filer ved, at man tilføjer parameteren "-l" efter "in.rshd" i filen "/etc/inetd.conf" og genstarter inetd-dæmonen. Læs mere om inetd i Artikel 2 - Services.

Et andet argument imod at tillade ".rhosts"-filer er, at brugeren kan komme til at køre et program, som skriver til en fil uden hans viden. Filen kunne "~/.rhosts" og dermed give adgang til en ekstern bruger, som ikke behøver at have en konto på maskinen.

Et alternativ til "~/.rhosts" metoden er "hosts level equivalence" via filen "/etc/hosts.equiv". Dine brugere har ikke adgang til denne fil, og kun root kan rette i den. Root kan vælge at sætte en række hostnavne ind i denne fil eller evt. bare et plus. Det betyder, at disse hosts (+ betyder alle maskiner) har adgang til at udføre rlogin og rsh kommandoer uden password. Dette gælder alle brugere (dog ikke root) - brugeren skal dog findes på begge maskiner. Filen "/etc/hosts.equiv" kan være en bekvem løsning, men den er en bombe under systemsikkerheden - find en anden løsning, hvis du har et åbent eller halvåbent netværk.

Her i User Friendly fra den 12. december 1997 kan Greg fra Columbia Internet aflytte netværkstrafikken i forsvarsministeriet...
images/uf16x122.gif
Fortsættelsen kan findes på http://www.userfriendly.org/cartoons/archives/97dec/19971216.html :-)

Nem og sikker netværkstrafik

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.quick.com.au/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.

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

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 linier.

Det er et reelt problem, at den tilsvarende kommecielle ssh ikke er Open Source, og derfor er der et frit GNU program igang med at reimplementere koden under navnet PSST. Du kan finde mere information om dette på http://www.net.lut.ac.uk/psst. Hjemmesiden for PSST bør følges fra tid til anden, men status i øjeblikket (december 2000) er, at man er stadig igang med at implementere, og derfor ikke kan garantere for at koden virker, eller at den er sikker. Status er ikke ændret meget det sidste år...

En anden, forholdsvis ny implementering af ssh-protokollen er OpenSSH, som er Open Source og er lavet af OpenBSD folkene. Den er allerede er lagt ind i OpenBSD distributionen, der har ry for at være særdeles sikker. OpenSSH er ligeledes på vej ind i Debian distributionen. Hjemmesiden for OpenSSH er http://www.openssh.com/. OpenSSH er baseret på OpenSSL, som kan downloades under support samme sted, som OpenSSH findes. Man kan enten compile programmerne selv eller installere de RPM-pakker, som findes præ-compilerede.

OpenSSH er en godt projekt, som har lavet en fri implementering af SSH og SSH2. 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.

Installation af OpenSSH

OpenSSH kan hentes fra http://www.openssh.com. Version bør være højere end 2.3.0. Der kan henter 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 2.3.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. Du skal fra også bruge dette - det kan hentes samme sted som OpenSSH RPM-filerne findes, eller fra http://www.openssl.org.

Skal du installere SSH via RPM så er det fra og med Red Hat 7.0 rigtig nemt, idet alle filerne følger med distibutionen.

[robin@sherwood ~]# su
[root@sherwood /home/robin]# rpm ivh zlib-1.1.3-i386.rpm
[root@sherwood /home/robin]# rpm ivh openssl-0.9.5a-i386.rpm
[root@sherwood /home/robin]# rpm ivh openssh-2.3.0p1-1.i386.rpm
[root@sherwood /home/robin]# rpm ivh openssh-clients-2.3.0p1-1.i386.rpm
[root@sherwood /home/robin]# rpm ivh openssh-server-2.3.0p1-1.i386.rpm

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 (check om /usr/lib/libz.so findes).

[robin@sherwood ~]# su
[root@sherwood /home/robin]# tar zxvf zlib-1.1.3.tar.gz
[root@sherwood /home/robin]# cd zlib-1.1.3
[root@sherwood zlib-1.3]# ./configure
[root@sherwood zlib-1.3]# make
[root@sherwood zlib-1.3]# make install

Dernæst skal OpenSSL installeres

[robin@sherwood ~]# su
[root@sherwood /home/robin]# tar zxvf openssl-0.9.5a.tar.gz
[root@sherwood /home/robin]# cd openssl-0.9.5a
[root@sherwood openssl-0.9.5a]# ./configure
[root@sherwood openssl-0.9.5a]# make
[root@sherwood openssl-0.9.5a]# make install

Og slutteligt skal OpenSSH oversættes og installeres

[robin@sherwood ~]# su
[root@sherwood /home/robin]# tar zxvf openssh-2.3.0p1.tar.gz
[root@sherwood /home/robin]# cd openssh-2.3.0p1
[root@sherwood openssh-2.3.0p1]# ./configure --sysconfdir=/etc/ssh
[root@sherwood openssh-2.3.0p1]# make
[root@sherwood openssh-2.3.0p1]# make install
[root@sherwood openssh-2.3.0p1]# 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.

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

Har du oversat OpenSSH selv, mangler du stadig at få OpenSSH startet op på maskinen efter system-genstart. Du kan for SuSE kopiere

[root@sherwood openssh-2.3.0p1]# cp contrib/rc.config.sshd /etc/rc.config.d/sshd.rc.config

og for Red Hat

[root@sherwood openssh-2.3.0p1]# cp contrib/rc.config.sshd /etc/rc.d/init.d/sshd.rc.config

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@sherwood openssh-2.3.0p1]# /etc/rc.d/init.d/sshd start

og tilsvarende for SuSE køres

[root@sherwood openssh-2.3.0p1]# /sbin/init.d/sshd start

Check 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_2.3.0p1

Brugeropsætning af OpenSSH

Hver bruger skal have sit eget sæt af privat/offentlig nøgle. Den private skal 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å. Brugeren skal selv generere sine nøgler og selv vælge en "pass-phrase" - svarende til et password, dog kan det være meget langt. Lav det tilpas kryptisk, men du skal kunne huske det.

[robin@sherwood robin]$ ssh-keygen -d 
Generating DSA parameter and key.
Enter file in which to save the key (/home/robin/.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/robin/.ssh/id_dsa.
Your public key has been saved in /home/robin/.ssh/id_dsa.pub.
The key fingerprint is:
ea:20:20:ae:b3:39:6f:d9:1b:a2:ef:02:0c:05:c5:fb robin@sherwood

Anvender man ikke option "-d" fås en RSA-nøgle, som anvendes til SSH version 1 servere, mens option "-d" danner en DSA nøgle svarende til SSH2 servere (begge generationer af servere anvendes i dag - spørg evt. systemadministratoren om hvad der skal bruges. Kan du selv vælge så brug SSH2 server). Når du kører ssh-keygen spørges du om du vil gemme i default stedet /home/robin/.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/identity (for RSA nøglen) or $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, som vi nu vil se nærmere på.

[robin@sherwood robin]$ 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. 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 initd-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.

Brug af SSH

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

[robin@sherwood robin]$ ssh locksley
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.

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 (sherwood) 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.

[robin@sherwood robin]$ cd ~/.ssh
[robin@sherwood .ssh]$ scp id_dsa.pub locksley:authorized_keys2

Nu skal du lave den sidste opsætning på locksley. 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.

[robin@sherwood robin]$ ssh locksley
[robin@locksley robin]$ mkdir ~/.ssh
[robin@locksley robin]$ mv authorized_keys ~/.ssh
[robin@locksley robin]$ chmod go-w ~
[robin@locksley robin]$ chmod -R go-rwx .ssh
[robin@locksley robin]$ exit

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å locksley. F.eks. kan du starte et grafik program såsom "xload" ved at skrive

[robin@sherwood robin]$ ssh locksley xload
Enter passphrase for RSA key 'robin@locksley': 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 locksley og vises på din egen maskine (sherwood). Skal du logge ind på locksley, så skriver du blot "ssh locksley", og skal du have udført et program derfra, tilføjer du blot programnavnet til denne ordre.

Skal du kopiere en fil fra sherwood til locksley, skriver du

[robin@sherwood robin]$ scp LOKALT_FILNAVN locksley:FJERN_FILNAVN

Du har altså ikke en fuld erstatning for ftp, men 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.

[robin@sherwood robin]$ ssh-agent bash
[robin@sherwood robin]$ ssh-add
Need passphrase for /home/robin/.ssh/identity (robin@sherwood).
Enter passphrase:        

Derefter kan du med ssh fra den terminal logge ind og ud af "locksley" 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.

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å locksley 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 linie 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

Sniffit

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. ftp://ftp.replay.com/pub/crypto/crypto/SSH/3rd_party/putty, http://www.mindbright.se/mindterm. Der findes også en kommerciel Windows ssh-version, som kan købes fra http://www.datafellows.com.

Endelig så skal du vide, at ssh koster ekstra belastning af din CPU, idet data krypteres og dekrypteres. Performance tabet afhænger af maskinerne som anvendes. For moderne PC'ere (Pentium 120 Mhz eller nyere) er det dog ikke mærkbart.


Revisionshistorie

 
Förstasida   Anmälning   Postarkiv   Översikt   Kalender   Sök

 
 
Fel och synpunkter angående webb-sidorna skickas till <www_admin>. Senaste ändring 2004-03-07, klockan 21:25 .
 

Denne side vedligeholdes af Peter Toft (<pto@sslug.dk>)