$Date: 2007/01/23 12:27:25 $
Mange benytter SSH uden at kende særligt meget til det, hvilket sænker sikkerhedsniveauet der ellers kan opnås ved at bruge SSH korrekt. Denne artikel vil forsøge at forklare på korrekt og simpelt dansk, hvad SSH kan og ikke kan, og hvordan man udnytter det bedst.
Det antages, at du benytter OpenSSH. Hvis du ikke gør det, er det muligt, at du skal foretage små ændringer i fil og sti navne.
SSH dækker over programmerne ssh, sshd,
scp og sftp. Dertil kommer diverse støtteprogrammer
til at generere og manipulere nøgler.
SSH kan funktionelt overtage roller som ellers tidligere blev klaret seperat
af ftp, telnet, rcp, rsh,
rlogin og rexec. SSH er langt mere flexsibel end
tidligere services, og samtidigt tilbyder det stærkere beviser for brugerens
identitet, samt bedre kontrol af TCP forbindelser og brugere.
Det kræver dog, at brugerne forstår diverse små ændringer i deres dagligdag, men når de først gør det, vil de finde livet ganske meget lettere.
SSH er ikke egnet til at give anonym adgang til filer, som f.eks. FTP er kendt for. Til den slags bør man alligevel benytte HTTP, da FTP protokollen er svær at tage højde for i et sikkert miljø (hvor både klient og server har IP filtre af en art sat op). Yderligere bliver mange implementationer af FTP servere regelmæssigt offer for sikkerhedsfejl, der kan give root adgang.
(Matasano forklarer nogle af problemerne med ftp protokollen.)
Der er intet magisk ved SSH. Det er en kryptoprotokol og samling programmer skrevet i C, og dette medfører de muligheder for fejl der nu engang findes i kryptoprotokoller og C programmer.
De ansvarlige for OpenSSH forsøger dog at tage højde for den slags fejl. De har stor erfaring med at levere sikker og robust kode, og de efterser deres egen kode for fejl i stedet for at vente på at andre finder fejlene. Der benyttes også privilege seperation, som betyder at kun en ganske lille del af OpenSSH nogensinde kører med root rettigheder. Alt det komplicerede kode der måske har fejl er enten spærret inde i en process der kører som en begrænset bruger, eller det bliver først kørt efter at brugeren har logget ind.
Det nedsætter risikoen for katastrofer betydeligt, men det betyder blot, at system administratorer har mere tid at opdage forsøg på indbrud og patches deres maskiner. Det betyder på ingen måde, at man ikke skal installere nye versioner, når der rettes sikkerhedsfejl.
I tillæg til, at implementationen skal være grundigt efterset, skal der tages højde for brugerfejl. Før en implementation rulles ud i et produktionsmiljø, bør man opnå enighed om hvordan den skal virke, og det skal gøres klart hvordan man senere vil bekræfte at den faktisk virker som forventet.
Udefrakommende kan naturligvis ikke diktere sikkerhedspolitikken på dit netværk, så den første del må du selv tage beslutninger om. Et punkt kunne indebære, at man, enten manuelt eller automatisk, læser opsætningsfilerne med jævne mellemrum, og sikrer sig, at de ser fornuftige ud og passer ind i den sikkerhedspolitik man har bestemt sig for.
Hvis man f.eks. forventer at der kun er adgang til netværket v.h.a. SSH nøgler, og det viser sig, at de fleste maskiner tillader logins blot baseret på adgangskoder, sænker det sikkerhedsniveauet drastisk.
Der skal også en smule brugeruddannelse til. SSH forsørger at forhindre en 3. part, der sidder midt imellem dig og modtageren, og sender alt frem og tilbage. Det gøres ved at opbevare "fingeraftrykket" af serverens offentlige nøgle på klienten. Det er derfor vigtigt at brugerne ved hvordan de skal reagere hvis deres ssh klient bemærker at dette fingeraftryk har ændret sig. Mere om det lidt senere.
OpenSSH er en del af de fleste (gratis) UNIX systemer nu om dage.
Hvis OpenSSH ikke er en del af dit OS, kan du hente det fra http://www.openssh.com (bemærk .com, ikke .org) hvor det er tilgængeligt i kode format, RPM og Debian pakker, og mange andre.
Det er muligt, at dine opsætningsfiler bliver lagt et andet sted end mine,
f.eks. /usr/local/etc/ssh_config istedet for
/etc/ssh/ssh_config. Denne tekst antager, at du har nok kendskab
til dit OS, at du kan finde ud af den slags.
ssh_config som ligger i /etc/ssh giver
administratoren mulighed for at angive retningsliner til hvordan ssh clienterne
på hans system skal opføre sig.
Der er opsætningsmuligheder for både brugere og administratorer. Brugere kan
oprette en fil ved navn ~/.ssh/config, hvilket er deres egen
lokale kopi af ssh_config, hvori de kan bruge et antal ord til at beskrive
maskiner de forbinder sig til ofte.
Ordet 'Host' er en unik reference til en maskine i brugerens config fil. Den behøver ikke have noget med det rigtige DNS navn på maskinen at gøre. Ordet 'Hostname' fortæller ssh hvilken maskine eller IP den i virkeligheden skal forbinde sig til. Ordet 'User' giver os mulighed for at specificere et brugernavn. Dette er kun nødvendigt hvis brugernavnet på vores lokale maskine er forskelligt fra brugernavnet på den fjerne maskine.
=== ~/.ssh/config Host sjov Hostname sjov.langt.domain.navn.tld User benny Host u Hostname underligt.langt.domain.navn.tld User viggo
Med ovenstående 3 linier vil kommandoen:
$ ssh sjov
forsøge at logge os ind i sjov.langt.domain.navn.tld med
brugernavnet 'benny', og kommandoen:
$ ssh u
vil forsøge at logge os ind i underligt.langt.domain.navn.tld
med brugernavnet viggo.
Jeg hader systemer der er baseret alene på et brugernavn og et kodeord. Jeg hader dem, fordi det er så let at miste dem, uden man ved det, og fordi det er så svært at finde ud af om et kodeord er blevet "væk", eller hvordan det er sket. Kodeord kan let blive gættet af et program eller et menneske, og der er en tendens til at skrive kodeord ned på farlige steder, fordi man har så mange, at de er svære at huske.
Kodeord er en-faktor ("noget man ved"), og på det basis bliver man lukket ind på en maskine.
Jeg kan langt bedre lide princippet "noget man ved" OG "noget man har," og det er her SSH nøgler kommer ind i billedet; det kaldes to-faktor validering. For at logge ind kræves en SSH nøgle i form af en fil på sin harddisk ("noget man har") og et langt kodeord ("noget man ved") til denne fil.
Du kan lave dit eget SSH nøglepar, ved at skrive følgende kommando på din arbejdsmaskine. Sørg for at bruge et langt kodeord på mindst 15 til 20 tegn, gerne længere. Det skal være noget som ikke kan gættes, så lad være med at bruge Shakespeare citater, eller linier fra din yndlingssang. Jeg kan godt lide at danne en sætning som ikke giver meningen, evt. på forskellige sprog.
$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): [return] Enter passphrase (empty for no passphrase): [indtast langt kodeord her] Enter same passphrase again: [gentag langt kodeord her] Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: 61:27:36:5c:f9:bf:2f:f9:25:85:55:7c:86:82:14:f9 dig@din.maskine.her
Som du kan se, har ssh-keygen nu lavet nogle SSH nøgler til
dig. Den fortæller dig hvor de ligger, og den fortæller dig hvad det digitale
fingeraftryk af din nøgle er.
Kommentaren som udskrives til sidst er i dette tilfælde dit brugernavn og maskine navn. Dette felt bruges udelukkende til at identifiere en nøgle overfor mennesket der logger ind, så du kan ændre den til hvad du har lyst, så længe kommentaren betyder noget i dit hoved. Brug enten en text editor eller brug kommandoen:
$ ssh-keygen -C "Anders And"
Dette er især nyttigt når du har flere nøgler på samme maskine, f.eks. én
til arbejde og én til privat brug. Du kan bruge -f argumentet til at specifere
et andet filnavn end id_dsa.
Du skal beskytte dine private nøgler godt. Sørg for at ingen kan læse dine private nøgler, og at ingen kan skrive til dine private nøgler. Hvis du har utilstrækkelige permissions på dit hjemmebibliotek eller dine nøgler vil ssh klienten nægte at fuldføre forbindelsen:
$ ssh -v foo [..] debug: Trying RSA authentication via agent with 'Anders And' debug: Remote: Bad file modes for /home/anda debug: Server refused our key. debug: RSA authentication using agent refused. debug: Trying RSA authentication with key 'Anders And' debug: Remote: Bad file modes for /home/anda
Hvis vi bruger vores viden om .ssh/config filen kan vi gøre livet lidt lettere for os selv.
==== ~/.ssh/config ==== Host foo Hostname foo.subdomain.domain.tld User brugernavn Identityfile ~/.ssh/id_dsa ===
Ovenstående vil gøre os i stand til at skrive:
$ ssh foo
hvilket vil logge os ind som brugernavn i foo.subdomain.domain.tld, med id_dsa som SSH nøgle. Hvis du giver rette kodeord til din SSH nøgle får du lov til at logge ind.
SSH kan bruges sammen med mange applikationer, blandt andet CVS, subversion, rsync og andet. Disse opretter mange forbindelser i løbet af en dag, og det kan være ubelejligt at skulle taste sit 30 tegns lange kodeord hver gang man forbinder sig til en anden maskine.
Vi skal altså bruge en metode der kan lade os beholde det høje sikkerhedsnivea (undgå SSH nøgler med blanke kodeord) men samtidigt gøre det så let at bruge SSH, at folk vil skifte fra telnet til SSH, blot for at de kan være lidt mere dovne.
Svaret på vores bønner er ssh-agent. ssh-agent er et lille program der
kører i baggrunden sålænge du er logget på. Den modtager autentifikationsdata
fra ssh-add kommandoen, og samtlige efterfølgendelogins der benytter den
pågældende SSH nøgle bliver klaret af ssh-agent.
Der er ikke længere behov for at indtaste dit lange kodeord 40 gange om
dagen.
Du skal starte ssh-agent fra .xsession (eller .xinitrc hvis du bruger
startx) sammen med resten af dine programmer:
=== ~/.xsession === eval `ssh-agent -s` exec blackbox ===
Når du så har logget ind, kan du starte en terminal og skrive ssh-add for
at tilføje nøglen til ssh-agent:
$ ssh-add Need passphrase for /home/anda/.ssh/id_dsa:
Det kan betale sig at have flere nøgler, alt efter hvilken type maskine du tilgår, og du kan let tilføje flere nøgler til ssh-agent:
$ ssh-add ~/.ssh/hjemme.identity
eller bruge dette stykke kode fra OpenBSD som findes i
/etc/X11/xdm/Xsession:
# if we have private ssh key(s), start ssh-agent and add the key(s)
id1=$HOME/.ssh/identity
id2=$HOME/.ssh/id_dsa
id3=$HOME/.ssh/id_rsa
if [ -x /usr/bin/ssh-agent ] && [ -f $id1 -o -f $id2 -o -f $id3 ];
then
eval `ssh-agent -s`
ssh-add $id2 $id2 $id3 < /dev/null
fi
do_exit() {
if [ "$SSH_AGENT_PID" ]; then
ssh-add -D < /dev/null
eval `ssh-agent -s -k`
fi
exit
}
Dette vil tilføje ~/.ssh/identity, ~/.ssh/id_dsa
og ~/.ssh/id_rsa til agenten og spørge efter kodeord for hver
nøgle. Det burde være simpelt at tilføje flere nøgler til ovenstående kode.
Husk at personer der har adgang til din maskine, nu kan logge ind som dig. Gør det derfor til en vane at låse din session eller slette nøglerne fra ssh-agent når du forlader maskinenen:
$ ssh-add -d
Du skal så tilføje nøglerne når du igen er klar til at arbejde. ssh-agent gør det utroligt nemt at arbejde sikkert på tværs af et stort antal maskiner.
Authentication forwarding kræver at ssh-agenten kører på den lokale maskine
og for hver fjernmaskine du vil forwarde authentication til, skal det specifikt
angives på kommandolinien med -A, eller med ForwardAgent
yes i ~/.ssh/config.
Funktionen gør, at når der oprettes en SSH forbindelse fra maskineA til maskineB, så behøves der ikke en privat nøgle på maskineB for at logge videre ind i maskineC. Dette nedbringer drastisk risikoen for at din private nøgle opsnappes.
Rent teknisk sker det ved, at ssh klienten opretter en UNIX socket på
maskineB og lægger stien på denne i variablen SSH_AUTH_SOCK. Når
maskineC så sender et challenge til maskineB bliver det sendt gennem denne
socket til maskineA hvor svaret beregnes og sendes tilbage gennem maskineB
til maskineC.
Hvis andre, f.eks. en ondsindet root, kan tilgå den socket som oprettes og
lægges i SSH_AUTH_SOCK kan vedkommende udgive sig for at være dig
sålænge der forwardes authentication requests frem og tilbage.
SSH behøver ikke give dig en fuld terminal hver gang du skal udføre en kommando på et fjernt system. Det kan være noget så simpelt som:
$ ssh foo uptime 09:16AM up 76 days, 18 users, load averages: 0.10, 0.09, 0.08
eller
$ ssh foo xterm
eller
$ ssh foo "cd ~/html; for i in *.html; do tidy \$i; done"
Hvis du undlader at escape variable (ved at sætte \ foran $) vil din lokale shell udvide dem før kommandoen bliver sendt. Dette har én gang bidt mig i halen, da jeg ikke kunne forstå hvorfor et bestemt program ikke var i $PATH på en remote maskine. Kommandoen:
$ ssh bar echo $PATH
gav nemlig det forventede resultat, så jeg begyndte at lede efter andre fejl. Jeg kom endeligt i tanke om, at fjern maskinen blot er blevet er bedt om at skrive den lokale path ud. Et \ foran $ viste at min $PATH var forkert, så jeg rettede problemet.
OpenSSH indeholder programmet scp, som giver tilsvarende funktion du måske er vant til fra rcp. scp kan kopiere filer via en krypteret tunnel, godt pakket ind i dit SSH cipher og authentication, og kan gøre dette mellem en lokal maskine og en fjern maskine.
Syntaxen er:
scp [-pqrvC46] [-S program] [-P port] [-c cipher] [-i identity_file] [-o
option] [[user@]host1:]file1 [...] [[user@]host2:]file2
Hvilket betyder blandt andet følgende kombinationer er lovlige. I hver af
de nedenstående eksempler går vi ud fra at RSA keys er sat korrekt op, og
evt. at ~/.ssh/config filen har korte navne for nogle af
maskinerne.
Vi starter med at kopiere en lokal fil til en backup maskine:
$ scp vigtig.html backup:~/html
Det gik jo fint. Nu skal vi hente en anden fil ned til vores lokale maskine.
$ scp backup:~/src/hello.c ~/working/world/
Eller alle *.c filer i et katalog.
$ scp backup:~/src/\*.c ~/working/world/
Det er også muligt at hente et hierarki af filer og kataloger rekursivt
med scp -r, men så er sftp ofte et mere
hensigtsmæssigt valg.
scp kan også kopiere mellem to fjernmaskiner, hvis der ikke
står IP filtre eller andet i vejen der forhindrer TCP forbindelser mellem de to
maskiner.
workstation$ scp -r web.private.net:/var/www backup.private.net:/safe
Basalt set løser sftp samme opgave som scp, nemlig
at flytte filer mellem servere.
sftp har circa samme brugerflade som ftp
kommandolinieklienten, og mange af de grafiske sftp klienter ligner til
forveksling en almindelig ftp klient. De fleste PC brugere bør forholdsvis let
kunne skifte ftp ud med sftp.
sftp er ftp overlegen på en række punkter. Blandt andet benyttes en almindelig ssh forbindelse (tcp port 22), ikke tcp port 21 + dynamiske porte. Yderlige har sftp support for alle de samme valideringsmetoder som ssh har, og det er trivielt for en server administrator at begrænse en ssh forbindelse til kun at kunne aktivere sftp i stedet for en komplet kommandoprompt.
sftp er lidt langsommere end ftp der ikke bliver krypteret, men med det standard hardware der bliver købt i dag, kan det ikke mærkes. Ved tilstrækkeligt mange samtidige sftp forbindelser kan en server blive belastet fordi den skal kryptere masser trafik. Det kan heldigvis løses ved at købe et stykke hardware designet til at hjælpe servere med netop kryptering. De hedder krypteringsaccelleratorer og koster ca. kr. 500-1000,-
builder$ sftp athena Connecting to athena... sftp> ls *.xml hest.xml sftp> ^D builder$
Hvis du ikke har slået "X forwarding" fra (og den pågældende maskine du logger ind i heller ikke har), vil ssh sætte variablen $DISPLAY på hver fjern maskine du logger ind i. Den vil blive sat til at pege tilbage på din arbejdsstation, hvilket du sikkert også kender fra rsh og rlogin.
Forskellen er her, at alt X traffik vil blive pakket ind i den kryptering som ssh smider i hovedet på os, så der er ikke længere grund til at åbne port 6000 i evt. IP filtre. Alt bliver sendt via port 22.
Der er ikke rigtigt nogle begrænsninger på mulighederne. Eksempler kunne være:
$ ssh gateway xterm
eller
$ ssh monster gimp
Filen ~/.ssh/authorized_keys tillader at der per nøgle specificeres
en bestemt opførsel. F.eks. kunne man forestille sig et netværk med en central
backup maskine. Hver nat logger et automatisk job ind som root på de andre
maskiner og kører et backup script. For at dette skal virke uden menneskelig
indgriben er der behov for en SSH nøgle uden et kodeord. Men det betyder også,
at enhver som kommer i besiddelse af den private SSH nøgle der bruges til at
logge ind som root kan få fuld adgang til alle dine maskiner.
Det er naturligvis ikke ønskeligt, så vi bliver nødt til at gøre noget! SSH
kan heldigvis hjælpe os. Vi antager at root's authorized_keys ser
sådan ud:
1024 37 12612222246989878934981693191901046773440333968586102481572523..... 1024 37 13898868333014216489385109888257089319924184718758180745943779.....
Som du kan se indeholder filen to nøgler. Den første nøgle tilhører en administrator som har brug for at logge ind som root, og den anden nøgle er den nøgle som bruges af backup maskinen. Vi kan nu sætte forskellige begrænsninger på hvad der sker når netop den nøgle bliver brugt til at logge ind.
I dette tilfælde kan vi begrænse skaden der kan udfalde ved at en angriber
får fat i nøglen på backup maskinen. Vi vil tvinge backup maskinen til kun at
kunne køre ét bestemt script på hver maskine, og vi ønsker kun at tillade
at nøglen bruges fra backup maskinens IP adresse, 192.168.42.9. Dette gøres
ved at tilføje command og from til authorized_keys,
adskilt med et komma:
1024 37 12612222246989878934981693191901046773440333968586102481572523..... command="/usr/local/bin/run_backup",from="192.168.42.9" 1024 37 138933.....
Det betyder at enhver forbindelse som bliver valideret med denne nøgle bliver tvunget til at køre den angivet kommando, samt at hvis valideringen sker fra en anden IP adresse end den førnævnte, vil en besked blive skrevet til logfilen og forbindelsen vil blive afvist. Det er så op til dit logsystem at gøre de systemansvarlige opmærksomme på denne overtrædelse af sikkerhedspolitikken.
F.eks. bruges command ofte til at begrænse brugere på dedikerede
maskiner til kun at kunne udføre /usr/bin/cvs med "server" som
argument:
command="/usr/bin/cvs server" 1024 37 1389881693191901044033948688333.....
Bemærk at din systemadministrator kan have lagt authorized_keys
et andet sted, så hvis du logger ind ved brug af nøgler men ikke har en
~/.ssh/authorized_keys fil skal du snakke med ham eller hende.
OpenSSH giver dig mulighed for at dele én TCP forbindelse til den samme server mellem flere klienter. "Prisen" i tid for at oprette en TCP forbindelse, forhandle kryptering og validere brugeren kan være for høj hvis man har behov for at oprette mange forbindelser per sekund, f.eks. i forbindelse med subversion, rsync, cvs, distccd eller lignende værktøjer der benytter SSH som transport.
Hvis du logger ind og/eller kopierer mange ting fra den samme server vil du
opleve meget store hastighedsforbedringer på alle logins ud over det første.
Du aktiverer denne egenskab med kommandolinjeparametrene -M og -S, eller
nemmere med din konfigurationsfil.
Tilføj følgende linjer til ~/.ssh/config for at aktivere multiplexing:
ControlMaster auto ControlPath ~/.ssh/ControlPath_%h_%p_%r
Dette får SSH til at gemme en socket i .ssh i dit homedir, som andre SSH- klienter kan forbinde sig til for at nå den samme server.
zsh er en avanceret UNIX-shell, der bl.a. har mange forskellige tab- expansion-muligheder. Hvis du kombinerer ssh-nøgler, ssh-agent og zsh vil du kunne expande filnavne på en fremmed server blot ved at skrive:
scp <navn på server>:<begyndelse af filnavn>
Og efterfølgende trykke på din tabulator-tast.
Denne funktion burde allerede være aktiveret i zsh med standard-opsætningen ellers burde følgende i din .zshrc aktivere det:
autoload -Uz compinit compinit
Husk også at slå multiplexing af forbindelser til for at spare noget ventetid
sshd_config ligger enten i /etc/ssh eller
/usr/local/etc, og den bestemmer hvordan din server kører.
Som administrator af et tilsyneladende sikkert netværk bør du absolut tage
dig tid til at læse man siderne til ssh og sshd, så
du ved hvad programmet er i stand til.
Vi vil kort gennemgå nogle af de mest vigtige aspekter af din ssh server.
Jeg har blandt andet følgende i min /etc/ssh/sshd_config:
Port 22
Dette er standard porten for SSH, ligesom 23 er det for telnet.
Du har sjældent behov for at ændre dette, medmindre din netværksarkitektur
kræver det. Hvis du har brug for, at sshd lytter på mere end én
port, kan du bruge dette ord flere gange.
Protocol 2
Hvis din sikkerhedspolitik nævner det, skal du her beslutte hvilke versioner af SSH protokollen din sshd skal understøtte, og hvilken der er en foretrukne. SSH protokol 2 er nu understøttet af de fleste SSH klienter, og hvor det er muligt bør man udelukkende bruge denne.
ListenAddress 0.0.0.0
Dette angiver hvilken adresse sshd til lytte på. Dette er meget rart i
tilfælde hvor du har flere adresser på dine maskiner. Det giver mulighed
for, at fjerne SSH som en service fra netværk hvor den ikke er nødvendig.
Hvis f.eks. du har et privat netværk som du udelukkende tilgår dine
maskine fra, er der ingen grund til, at sshd lytter på det
offentlige netværk, da det blot er en mulig indgang for en angriber.
PermitRootLogin no
Opsætningen af dette punkt skal dikteres af din sikkerhedspolitik. Jeg har bestemt, at root ikke skal have mulighed for at logge ind via SSH -- ikke fordi jeg er bange for nogen skal få fat i root's SSH nøgle og ødelægge mine maskiner, men fordi det giver et spor i logfilerne om hvem der gør hvad ved maskinen. Dette er rart i tilfælde af, at en administrator har splittet noget ad, og ikke kan huske hvad han har skrevet.
Moderne systemer bør alligevel administereres ved brug af automatiske værktøjer som versionsstyring, policy engines, etc. Hvis man har brug for at logge ind som root, er det nok fordi systemet er helt offline.
IgnoreRhosts yes
Filen ~/.rhosts og venner, som traditionelt bruges af rsh
, rlogin og andre funktioner, er også understøttet af SSH.
Min sikkerhedspolitik dikterer at .rhosts ikke er tilstrækkeligt
bevis på, at brugeren der logger ind, er hvem de påstår. Derfor vil jeg have
sshd til at se bort fra disse filer.
StrictModes yes
Jeg vil have at sshd forhindrer mine brugere i at logge ind, hvis deres SSH nøgle eller andre dele af ssh kan være blive manipuleret af andre end brugeren selv.
X11Forwarding no
Som jeg vil beskrive senere, støtter ssh at sende X traffik
igennem dens krypterede tunnel. Dette er en fremragende funktion, bortset fra,
at min sikkerhedspolitik siger, at der ikke må findes X klienter på mine
produktionsmaskiner. Ved at min sshd ikke sender X trafikken igennem den
krypterede tunnel, vil mit IDS opdage X traffik på netværket og vække mig. Hvis
du tillader X klienter på dine produktionsmaskiner, bør du helt klart sige
'yes' til dette punkt.
RhostsAuthentication no RhostsRSAAuthentication no
Jeg stoler ikke på rhosts, eller noget der ligner, så
sshd siger "Nej tak til reklamer", hvis den modtager sådan en
forespørgsel.
RSAAuthentication yes
Jeg kan rigtigt godt lide RSA nøgler af grunde som jeg forklarer i næste afsnit. Hvis du logger ind fra mange forskellige maskiner, som ikke altid er under din kontrol bør du sige 'no' her. Hvis du siger ja, skal du nemlig slæbe din hemmelige RSA nøgle rundt på en diskette, og den slags kan nemt blive væk eller kopieret. Desuden kan du heller ikke stole på, at den ssh klient du bruger til at koble dig op til dine maskine med ikke gemmer en kopi af dine RSA nøgle og tilhørende kodeord.
PasswordAuthentication no PermitEmptyPasswords no
Jeg stoler ikke på kodeord, igen af grunde som jeg vil forklare om lidt, og jeg vil bestemt ikke have, at folk kan logge sig ind min maskine, hvis deres konto ikke har et kodeord. Der er yderligere fundet sikkerhedsfejl i protokol 1 som gør netværks sniffere i stand til at finde længden på dit password, selvom du bruger SSH kryptering. Jeg vil kraftigt fraråde at bruge passwords til noget der er vigtigt for dig.
ChallengeResponseAuthentication no
Dette dækker i øjeblikket kun over S/Key som jeg ikke benytter, men hvis du ofte har brug for at logge på din maskine fra netværk og maskiner du ikke stoler på, bør du helt klart tage dig tid til at forstå hvad S/key er, og hvordan det virker.
AllowTcpForwarding no
Dette ord bestemmer om brugere skal have mulighed for at fremsende
(`forwarde') TCP forbindelser enten lokalt, fra én port til en anden, eller
fra en lokal port til en fjern maskine. Dette kan bruges til at pakke
telnet, POP3 og andet ind i kryptering, plus det kan bruges til at
omgå firewalls.
Det giver ikke øget sikkerhed at slå det fra, hvis brugerene kan compile eller uploade deres egne 'bounce' programmer.
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
Bestemmer hvor nøglerne for hver konto ligger. %u udvides til det aktuelle brugernavn.
Det er normalt ~/.ssh/authorized_keys der indeholder listen
over hvilke nøgler en konto accepterer som validering. Som nævnt kan
administratoren begrænse en eller flere nøgler til kun at logge ind fra
bestemte netværk eller kun køre bestemte kommandoer.
Hvis brugeren (eller en der har stjålet brugerens private nøgle og
adgangskode) kan komme til at redigere eller overskrive sin
authorized_keys fil kan sådanne begræsninger omgås. Derfor kan en
administrator vælge at lægge nøglerne et andet sted på filsystemet, hvor
brugeren ikke har skriveadgang.
På den måde stoppes visse typer angreb på den bekostning, at hver gang brugeren vil tilføje eller ændre sin nøgle, skal administratoren blandes ind i opgaven. Sørg for, at administratoren har en måde at verificere brugerens identitet når brugeren spørger om ændringer.
Når du nu har tygget dig igennem dette dokument bør du bruge lidt på til at forstå hvad du har læst. Derefter kan du fortsætte med: