Lær Ins og Out of OpenSSH på din Linux-pc

Vi har fortalte SSH's dyder mange gange, både for sikkerhed og fjernadgang. Lad os tage et kig på serveren selv, nogle vigtige "vedligeholdelsesaspekter" og nogle quirks, der kan tilføje turbulens til en ellers glidende 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 er det sikkert

Vi har ofte nævnt, hvordan SSH er en fantastisk måde at sikkert forbinde og tunnel data fra et punkt til et andet. Lad os tage et meget kort kig på, hvordan tingene virker, så du får en bedre ide om hvorfor tingene kan gå underlige.

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 information til en ekstern server, og vi får bekræftelse om vores forbindelse. For at etablere en form for sikkerhed bruger disse protokoller ofte brugernavn og adgangskombinationer. Det betyder, at de er helt sikre, ikke? Forkert!

Hvis vi tænker på vores forbindelsesproces som post, så bruger FTP og Telnet og lignende ikke som at bruge standard-mailingkuverter. Det er mere som at bruge postkort. Hvis der sker en skridt i midten, kan de se alle de oplysninger, herunder adresserne på begge korrespondenter og det udmeldte brugernavn og adgangskode. De kan så ændre meddelelsen, holde oplysningerne ens og efterligne en korrespondent eller den anden. Dette er kendt som et "man-in-the-middle" -angreb, og det kompromitterer ikke kun din konto, men det stiller spørgsmålstegn ved hver besked, der sendes, og den modtagne fil. Du kan ikke være sikker på, om du taler til afsenderen eller ej, og selvom du er, kan du ikke være sikker på, at ingen ser på alt imellem imellem.

Lad os nu se på SSL-kryptering, den slags, der gør HTTP mere sikker. Her har vi et postkontor, der håndterer korrespondance, der kontrollerer, om din modtager er den, han eller hun hævder at være, og har love, der beskytter din mail fra at blive kigget på. Det er mere sikkert generelt, og den centrale myndighed - Verisign er en, for vores HTTPS eksempel - sørger for, at den person, du sender mail til, tjekker ud. De gør dette ved ikke at tillade postkort (ukrypterede legitimationsoplysninger); i stedet mandat de ægte konvolutter.

Endelig lad os se på SSH. Her er opsætningen lidt anderledes. Vi har ikke en central autentificering her, men tingene er stadig sikre. Det er fordi du sender breve til en person, hvis adresse, du allerede kender - sige, ved at chatte med dem på telefon - og du bruger nogle virkelig smarte matematik til at underskrive din konvolut. Du overleverer det til din bror, kæreste, far eller datter for at tage det til adressen, og kun hvis modtagerens fancy matematiske kampe antager, at adressen er, hvad den skal være. Derefter får du et brev tilbage, også beskyttet mod nysgerrige øjne af denne fantastiske matte. Endelig sender du dine legitimationsoplysninger i en anden hemmelig 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 som det er, tror vi, vi vil skære det der. Hvis du har mere indsigt, er du velkommen til at chatte i kommentarerne selvfølgelig. For nu, lad os se på det mest relevante træk ved SSH, værtsautentificering.

Værtsnøgler

Værtsautentificering er hovedsagelig den del, hvor en person, du stoler på, tager konvolutten (forseglet med magisk matematik) og bekræfter adressen på din modtager. Det er en temmelig detaljeret beskrivelse af adressen, og den er baseret på nogle komplicerede matematikker, som vi bare vil springe over lige over. Der er et par vigtige ting at tage væk fra dette, selvom:

Da der ikke er nogen central myndighed, ligger den reelle sikkerhed i værtsnøglen, de offentlige nøgler og de private nøgler. (Disse to nøgler 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 verbose).
Hvis værtsnøglen ændres, vil du højst sandsynligt blive varslet, og du skal være forsigtig!

Da værtsnøglen bruges før godkendelse for at identificere SSH-serveren, bør du sørge for at tjekke nøglen, før du tilslutter. Du får vist en bekræftelsesdialog som nedenfor.

Du bør ikke bekymre dig, selvom! 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 online ventures, vil det ofte være på et sikkert log-in eneste websted. Du skal muligvis (eller vælge at!) Ringe til din it-afdeling for at bekræfte denne tast over telefonen. Jeg har endda hørt om nogle steder, hvor nøglen er på dit arbejdskilt eller på den specielle "Emergency Numbers" liste. Og hvis du har fysisk adgang til målmaskinen, kan du også tjekke for dig selv!

Kontrol af systemets værtsnøgle

Der er 4 typer slags krypteringsalgoritmer, der bruges til at lave nøgler, men standard for OpenSSH som af tidligere på året er ECDSA (med nogle gode grunde). Vi vil fokusere på den ene i dag. Her er kommandoen du kan køre på SSH-serveren, du har adgang til:

ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l

Din output skal returnere noget som dette:

256 ca: 62: ea: 7c: e4: 9e: 2e: a6: 94: 20: 11: db: 9c: 78: c3: 4c /etc/ssh/ssh_host_ecdsa_key.pub

Det første tal er den lidt længde på nøglen, så er selve nøglen, og til sidst har du filen den er gemt i. Sammenlign det midterste del til, hvad du ser, når du bliver bedt om at logge ind via fjernadgang. Det skal matche, og du er helt klar. Hvis det ikke gør det, kan der ske noget andet.

Du kan se alle de værter, du har tilsluttet via SSH, ved at kigge på din known_hosts-fil. Det er normalt placeret på:

~ / .Ssh / known_hosts

Du kan åbne det i ethvert tekstredigeringsprogram. Hvis du ser, så prøv at være opmærksom på, hvordan nøglerne gemmes. De gemmes med værtscomputerenes navn (eller webadresse) og dens IP-adresse.

Ændring af værtsnøgler og problemer

Der er nogle få grunde til, at værtsnøglerne ændrer sig, eller de svarer ikke til, hvad der er logget ind i din known_hosts-fil.

Systemet blev geninstalleret / genkonfigureret.
Værtsnøglerne blev manuelt ændret på grund af sikkerhedsprotokoller.
OpenSSH-serveren opdateres og bruger forskellige standarder på grund af sikkerhedsproblemer.
IP- eller DNS-leasing ændret. Dette betyder ofte, at du forsøger at få adgang til en anden computer.
Systemet blev kompromitteret på en eller anden måde, således at værtsnøglen ændrede sig.

Mest sandsynligt er problemet et af de første tre, og du kan ignorere ændringen. Hvis IP / DNS leasing ændret, kan der være et problem med serveren, og du kan blive sendt til en anden maskine. Hvis du ikke er sikker på, hvorfor årsagen til ændringen er, skal du nok antage, at det er den sidste på listen.

Hvordan OpenSSH håndterer ukendte værter

OpenSSH har en indstilling til, hvordan den håndterer ukendte værter, der afspejles i variablen "StrictHostKeyChecking" (uden citater).

Afhængigt af din konfiguration kan SSH-forbindelser med ukendte værter (hvis taster ikke allerede findes i din known_hosts-fil) gå tre måder.

StrictHostKeyChecking er indstillet til nej; OpenSSH vil automatisk oprette forbindelse til enhver SSH-server uanset værtsnøgle status. Dette er usikkert og anbefales ikke, undtagen hvis du tilføjer en masse værter efter en geninstallation af dit operativsystem, hvorefter du vil ændre 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 fra 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 en vært, der ikke allerede er til stede i din known_hosts-fil.

Du kan nemt ændre denne variabel på kommandolinjen ved at bruge følgende paradigme:

ssh -o 'StrictHostKeyChecking [option]' bruger @ vært

Erstat [valg] med "nej", "spørg" eller "ja". Vær opmærksom på, at der er enkelte lige citater, der omgiver denne variabel og dens indstilling. Udskift også bruger @ vært med brugernavnet og værtsnavnet på den server, du opretter forbindelse til. For eksempel:

ssh -o 'StrictHostKeyChecking spørg' [email protected]

Blokerede værter på grund af ændrede nøgler

Hvis du har en server, forsøger du at få adgang til, hvis dens nøgle allerede er ændret, forhindrer standard OpenSSH-konfigurationen dig fra at få adgang til den. Du kan ændre StrictHostKeyChecking-værdien for den pågældende vært, men det ville ikke være helt, grundigt, paranoid sikkert, ville det? I stedet kan vi blot fjerne den overtrædende værdi fra vores known_hosts-fil.

Det er helt sikkert en grim ting at have på skærmen. 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 det citerer den fil, vi skal redigere? Det giver os endda linjenummeret! Så lad os åbne den fil i Nano:

Her er vores offend-nøgle i linje 1. Alt vi skal gøre er at trykke Ctrl + K for at skære hele linjen.

Det er meget bedre! Så nu rammer vi Ctrl + O for at skrive (gem) filen, så Ctrl + X for at afslutte.

Nu får vi en god prompten i stedet, som vi simpelthen kan svare med "ja".

Oprettelse af nye værtsnøgler

Til posten 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 nemt.

Først skal du skifte til den relevante systemkatalog:

cd / etc / ssh /

Dette er normalt hvor de globale værtsnøgler er, selv om nogle distroer har dem placeret andetsteds. Når du er i tvivl, tjek din dokumentation!

Dernæst sletter vi alle de gamle nøgler.

sudo rm / etc / ssh / ssh_host_ *

Alternativt kan du flytte dem til en sikker backup-mappe. Bare en tanke!

Så kan vi fortælle OpenSSH-serveren om at omkonfigurere sig selv:

sudo dpkg -konfigurere openssh-server

Du får vist en prompt, mens din computer opretter sine nye nøgler. Ta-da!

Nu hvor du ved, hvordan SSH virker lidt bedre, bør du være i stand til at komme ud af hårde pletter. "Advarsel / fejl ved fjernværtsidentifikation er ændret" er noget, der smider mange brugere af, selv dem, der er bekendt med kommandolinjen.