Vi har hyldet dyderne ved SSH adskillige gange for både sikkerhed og fjernadgang. Lad os se på selve serveren, nogle vigtige aspekter af "vedligeholdelse" og nogle quirks, der kan tilføje turbulens til en ellers jævn tur.
Mens vi har skrevet denne vejledning med Linux i tankerne, kan dette også gælde for OpenSSH i Mac OS X og Windows 7 via Cygwin .
Hvorfor det er sikkert
Vi har nævnt mange gange, hvordan SSH er en fantastisk måde at oprette forbindelse til og sikre data sikkert fra et punkt til et andet. Lad os tage et meget kort kig på, hvordan ting fungerer, så du får en bedre idé om, hvorfor ting nogle gange kan gå underligt.
Når vi beslutter at starte en forbindelse til en anden computer, bruger vi ofte protokoller, der er lette at arbejde med. Telnet og FTP kommer begge til at tænke på. Vi sender oplysninger til en ekstern server, og så får vi bekræftelse tilbage om vores forbindelse. For at etablere en form for sikkerhed bruger disse protokoller ofte brugernavn og adgangskodekombinationer. Det betyder, at de er helt sikre, ikke? Forkert!
Hvis vi tænker på vores forbindelsesproces som mail, er det ikke som at bruge FTP og Telnet og lignende som at bruge standardforsendelseskonvolutter. Det er mere som at bruge postkort. Hvis nogen tilfældigvis træder i midten, kan de se alle oplysningerne, inklusive adresserne på begge korrespondenter og det sendte brugernavn og adgangskode. De kan derefter ændre beskeden, holde informationen den samme og efterligne den ene eller den anden korrespondent. Dette er kendt som et "mand-i-midten" -angreb, og det kompromitterer ikke kun din konto, men det sætter spørgsmålstegn ved hver sendt besked og modtaget fil. Du kan ikke være sikker på, om du taler med afsenderen eller ej, og selvom du er det, kan du ikke være sikker på, at ingen ser på alt imellem.
Lad os nu se på SSL-kryptering, den slags der gør HTTP mere sikker. Her har vi et posthus, der håndterer korrespondancen, som kontrollerer, om din modtager er, som han eller hun hævder at være, og har love, der beskytter din mail mod at blive set på. Det er generelt mere sikkert, og den centrale myndighed - Verisign er en, for vores HTTPS-eksempel - sørger for, at den person, som du sender mail til, tjekker ud. De gør dette ved ikke at tillade postkort (ukrypteret legitimationsoplysninger); i stedet pålægger de ægte konvolutter.
Lad os endelig se på SSH. Her er opsætningen lidt anderledes. Vi har ikke en central godkender her, men tingene er stadig sikre. Det skyldes, at du sender breve til en, hvis adresse du allerede kender - sig ved at chatte med dem i telefonen - og du bruger en rigtig fin matematik til at underskrive din konvolut. Du overdrager det til din bror, kæreste, far eller datter for at tage det til adressen, og kun hvis modtagerens smarte matematikmatcher antager du, at adressen er, hvad den skal være. Derefter får du et brev tilbage, også beskyttet mod nysgerrige øjne af denne fantastiske matematik. Endelig sender du dine legitimationsoplysninger i en anden hemmeligholdt algoritmisk fortryllet konvolut til destinationen. Hvis matematikken ikke stemmer overens, kan vi antage, at den oprindelige modtager flyttede, og vi skal bekræfte deres adresse igen.
Med forklaringen, så længe den er, tror vi, vi klipper den der. Hvis du har noget mere indblik, er du selvfølgelig velkommen til at chatte i kommentarerne. For nu skal vi dog se på den mest relevante funktion i SSH, værtsgodkendelse.
Værttaster
Værtsgodkendelse er i det væsentlige den del, hvor en, du stoler på, tager konvolutten (forseglet med magisk matematik) og bekræfter adressen på din modtager. Det er en ret detaljeret beskrivelse af adressen, og den er baseret på en kompliceret matematik, som vi bare springer lige over. Der er dog et par vigtige ting at tage væk fra dette:
- Da der ikke er nogen central myndighed, ligger den virkelige sikkerhed i værtsnøglen, de offentlige nøgler og de private nøgler. (Disse to sidstnævnte taster er konfigureret, når du får adgang til systemet.)
- Normalt, når du opretter forbindelse til en anden computer via SSH, gemmes værtsnøglen. Dette gør fremtidige handlinger hurtigere (eller mindre detaljerede).
- Hvis værtsnøglen ændres, vil du sandsynligvis blive advaret, og du bør være forsigtig!
Da værtsnøglen bruges før godkendelse til at fastslå SSH-serverens identitet, skal du sørge for at kontrollere nøglen, før du opretter forbindelse. Du vil se en bekræftelsesdialog som nedenfor.
Du skal dog ikke bekymre dig! Ofte når sikkerhed er et problem, vil der være et særligt sted, hvor værtsnøglen (ECDSA-fingeraftryk ovenfor) kan bekræftes. I helt onlinevirksomheder vil det ofte være på et sikkert websted, der kun er logget ind. Du skal muligvis (eller vælge!) Ringe til din IT-afdeling for at bekræfte denne nøgle over telefonen. Jeg har endda hørt om nogle steder, hvor nøglen er på dit arbejdsbadge eller på den specielle "Nødnumre" -liste. Og hvis du har fysisk adgang til målmaskinen, kan du også kontrollere det selv!
Kontrol af dit systems værtsnøgle
Der er 4 typer krypteringsalgoritmer, der bruges til at lave nøgler, men standard for OpenSSH som tidligere i år er ECDSA ( med nogle gode grunde ). Vi vil fokusere på den i dag. Her er den kommando, du kan køre på den SSH-server, du har adgang til:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Din output skal returnere noget som dette:
256 ца: 62: еа: щц: еч: яй: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
Det første tal er nøglens bitlængde, så er det selve nøglen, og til sidst har du den fil, den er gemt i. Sammenlign den midterste del med det, du ser, når du bliver bedt om at logge på eksternt. Det skal matche, og du er klar. Hvis det ikke gør det, kan der ske noget andet.
Du kan se alle de værter, du har oprettet forbindelse til via SSH, ved at se på din kendte_hosts-fil. Det er normalt placeret på:
~ / .ssh / known_hosts
Du kan åbne det i enhver teksteditor. Hvis du ser ud, skal du prøve at være opmærksom på, hvordan nøglerne opbevares. De gemmes med værtscomputerens navn (eller webadresse) og dens IP-adresse.
Ændring af værtsnøgler og problemer
Der er et par grunde til, at værtsnøgler ændres, eller at de ikke matcher det, der er logget ind i din kendte_hosts-fil.
- Systemet blev geninstalleret / genkonfigureret.
- Værtsnøglerne blev ændret manuelt på grund af sikkerhedsprotokoller.
- OpenSSH-serveren opdateres og bruger forskellige standarder på grund af sikkerhedsproblemer.
- IP- eller DNS-leasingkontrakten blev ændret. Dette betyder ofte, at du prøver at få adgang til en anden computer.
- Systemet blev kompromitteret på en eller anden måde, således at værtsnøglen blev ændret.
Mest sandsynligt er problemet et af de første tre, og du kan ignorere ændringen. Hvis IP / DNS-lease ændres, kan der være et problem med serveren, og du kan blive dirigeret til en anden maskine. Hvis du ikke er sikker på, hvad årsagen til ændringen er, skal du sandsynligvis antage, at det er den sidste på listen.
Sådan håndterer OpenSSH ukendte værter
OpenSSH har en indstilling for, hvordan den håndterer ukendte værter, afspejlet i variablen “StrictHostKeyChecking” (uden anførselstegn).
Afhængigt af din konfiguration kan SSH-forbindelser med ukendte værter (hvis nøgler ikke allerede er i din kendte_hosts-fil) gå tre måder.
- StrictHostKeyChecking er indstillet til nej; OpenSSH opretter automatisk forbindelse til enhver SSH-server uanset værtsnøglestatus. Dette er usikkert og anbefales ikke, undtagen hvis du tilføjer en masse værter efter en geninstallation af dit operativsystem, hvorefter du ændrer det igen.
- StrictHostKeyChecking er indstillet til at spørge; OpenSSH viser dig nye værtsnøgler og beder om bekræftelse inden du tilføjer dem. Det forhindrer forbindelser i at gå til ændrede værtsnøgler. Dette er standard.
- StrictHostKeyChecking er indstillet til ja; Det modsatte af "nej", dette forhindrer dig i at oprette forbindelse til enhver vært, der ikke allerede er til stede i din kendte_hosts-fil.
Du kan nemt ændre denne variabel på kommandolinjen ved hjælp af følgende paradigme:
ssh -o 'StrictHostKeyChecking [option]' bruger @ vært
Udskift [option] med "nej", "spørg" eller "ja". Vær opmærksom på, at der er enkelt lige citater omkring denne variabel og dens indstilling. Udskift også user @ host med brugernavnet og værtsnavnet på den server, du opretter forbindelse til. For eksempel:
ssh -o 'StrictHostKeyChecking ask' [email protected]
Blokerede værter på grund af ændrede nøgler
Hvis du har en server, du prøver at få adgang til, hvis nøglen allerede er ændret, forhindrer standard OpenSSH-konfigurationen dig i at få adgang til den. Du kunne ændre StrictHostKeyChecking-værdien for den vært, men det ville ikke være helt, grundigt, paranoid sikkert, ville det? I stedet kan vi simpelthen fjerne den krænkende værdi fra vores kendte_hosts-fil.
Det er bestemt en grim ting at have på din skærm. Heldigvis var vores grund til dette et geninstalleret OS. Så lad os zoome ind på den linje, vi har brug for.
Sådan der. Se hvordan den citerer den fil, vi skal redigere? Det giver os endda linjenummeret! Så lad os åbne den fil i Nano:
Her er vores fornærmende nøgle i linje 1. Alt, hvad vi skal gøre, er at trykke på Ctrl + K for at skære hele linjen ud.
Det er meget bedre! Så nu rammer vi Ctrl + O for at skrive (gemme) filen ud, derefter Ctrl + X for at afslutte.
Nu får vi en god prompt i stedet, som vi simpelthen kan svare med "ja."
Oprettelse af nye værtsnøgler
For ordens skyld er der virkelig ikke for meget af en grund til, at du overhovedet ændrer din værtsnøgle, men hvis du nogensinde finder behovet, kan du gøre det let.
Skift først til det relevante systemkatalog:
cd / etc / ssh /
Dette er normalt, hvor de globale værtsnøgler er, selvom nogle distroer har dem placeret andetsteds. I tvivlstilfælde skal du kontrollere din dokumentation!
Dernæst sletter vi alle de gamle nøgler.
sudo rm / etc / ssh / ssh_host_ *
Alternativt kan det være en god idé at flytte dem til en sikker backup-mappe. Bare en tanke!
Derefter kan vi bede OpenSSH-serveren om at konfigurere sig selv:
sudo dpkg-omkonfigurer openssh-server
Du får vist en meddelelse, mens din computer opretter sine nye nøgler. Ta-da!
Nu hvor du ved, hvordan SSH fungerer lidt bedre, skal du være i stand til at komme dig ud af hårde pletter. Advarslen / fejlen "Fjernværtidentifikation er ændret" er noget, der kaster mange brugere væk, selv dem der er fortrolige med kommandolinjen.
For bonuspoint kan du tjekke ud Sådan fjernkopieres filer over SSH uden at indtaste din adgangskode . Der lærer du lidt mere om de andre former for krypteringsalgoritmer, og hvordan du bruger nøglefiler til ekstra sikkerhed.
