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

Vi har uttalt dydene til SSH mange ganger, både for sikkerhet og ekstern tilgang. La oss ta en titt på selve serveren, noen viktige "vedlikehold" -aspekter, og noen quirks som kan legge turbulens til en ellers jevn tur.

Mens vi har skrevet denne guiden med Linux i tankene, kan dette også gjelde for OpenSSH i Mac OS X og Windows 7 via Cygwin.

Hvorfor det er sikkert

Vi har nevnt mange ganger hvordan SSH er en fin måte å sikkert koble til og tunnelere data fra ett punkt til et annet. La oss ta en veldig kort titt på hvordan tingene fungerer slik at du får en bedre ide om hvorfor ting kan bli rart noen ganger.

Når vi bestemmer oss for å starte en tilkobling til en annen datamaskin, bruker vi ofte protokoller som er enkle å jobbe med. Telnet og FTP kommer begge til tankene. Vi sender ut informasjon til en ekstern server, og vi får bekreftelse om forbindelsen vår. For å opprette en viss type sikkerhet bruker disse protokollene ofte brukernavn og passordkombinasjoner. Det betyr at de er helt sikre, ikke sant? Feil!

Hvis vi tenker på vårt tilkoblingsprosess som e-post, så bruker ikke FTP og Telnet og lignende ikke som å bruke standardutskrifts konvolutter. Det er mer som å bruke postkort. Hvis noen skjer i midten, kan de se all informasjon, inkludert adressene til begge korrespondentene og brukernavnet og passordet som sendes ut. De kan da endre meldingen, holde informasjonen den samme og etterligne en korrespondent eller den andre. Dette er kjent som et "man-i-midten" -angrep, og det kompromitterer ikke bare kontoen din, men det stiller spørsmålstegn ved hver melding som sendes og mottatt fil. Du kan ikke være sikker på om du snakker med avsenderen eller ikke, og selv om du er, kan du ikke være sikker på at ingen ser på alt fra mellom.

Nå, la oss se på SSL-kryptering, den typen som gjør HTTP sikrere. Her har vi et postkontor som håndterer korrespondansen, som sjekker for å se om mottakeren din er som han eller hun hevder å være, og har lover som beskytter e-posten din fra å bli sett på. Det er sikrere generelt, og den sentrale myndigheten - Verisign er en, for vårt HTTPS-eksempel - sørger for at personen du sender e-post til sjekker ut. De gjør dette ved å ikke tillate postkort (ukrypterte legitimasjonsbeskrivelser); i stedet de mandat ekte konvolutter.

Til slutt, la oss se på SSH. Her er oppsettet litt annerledes. Vi har ikke en sentral autentiserer her, men ting er fortsatt sikre. Det er fordi du sender brev til noen hvis adresse du allerede vet - si, ved å chatte med dem på telefonen - og du bruker noen veldig fancy matte til å signere konvolutten din. Du overleverer til din bror, kjæreste, pappa eller datter for å ta det til adressen, og bare hvis mottakerens fancy matte kamper antar at adressen er hva den burde være. Deretter får du et brev tilbake, også beskyttet mot nysgjerrige øyne av denne fantastiske matte. Til slutt sender du legitimasjonene dine i en annen hemmelig algoritmisk fortryllet konvolutt til destinasjonen. Hvis matematikken ikke stemmer, kan vi anta at den opprinnelige mottakeren flyttet, og vi må bekrefte adressen sin igjen.

Med forklaringen så lenge det er, tror vi at vi skal kutte det der. Hvis du har litt mer innsikt, kan du ikke snakke i kommentarene selvfølgelig. For nå, la oss se på den mest relevante funksjonen til SSH, vertsautentisering.

Vertsnøkler

Vertsautentisering er i hovedsak den delen der noen du stoler på, tar konvolutten (forseglet med magisk matte) og bekrefter adressen til mottakeren din. Det er en ganske detaljert beskrivelse av adressen, og den er basert på noe komplisert matte som vi bare vil hoppe over rett over. Det er et par viktige ting å ta bort fra dette, skjønt:

Siden det ikke er noen sentral myndighet, ligger den virkelige sikkerheten i vertsnøkkelen, offentlige nøkler og private nøkler. (Disse to nøklene er konfigurert når du får tilgang til systemet.)
Vanligvis, når du kobler til en annen datamaskin via SSH, lagres vertsnøkkelen. Dette gjør fremtidige handlinger raskere (eller mindre verbose).
Hvis vertsnøkkelen endres, vil du mest sannsynlig bli varslet, og du bør være forsiktig!

Siden vertsnøkkelen brukes før autentisering for å etablere identiteten til SSH-serveren, bør du være sikker på å sjekke nøkkelen før du kobler til. Du vil se en bekreftelsesdialog som nedenfor.

Du bør ikke bekymre deg, skjønt! Ofte når sikkerhet er en bekymring, vil det være et spesielt sted at vertsnøkkelen (ECDSA fingeravtrykk ovenfor) kan bekreftes. I helt online ventures, vil det ofte være på et sikkert innloggingssted. Du må kanskje (eller velge å!) Ringe IT-avdelingen din for å bekrefte denne nøkkelen over telefonen. Jeg har til og med hørt om noen steder hvor nøkkelen er på ditt arbeidskilt eller på den spesielle "Emergency Numbers" -listen. Og hvis du har fysisk tilgang til målmaskinen, kan du også sjekke for deg selv!

Kontrollerer systemets vertsnøkkel

Det finnes 4 typer typer krypteringsalgoritmer som brukes til å lage nøkler, men standard for OpenSSH fra tidligere i år er ECDSA (med noen gode grunner). Vi vil fokusere på den i dag. Her er kommandoen du kan kjøre på SSH-serveren du har tilgang til:

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

Din produksjon skal returnere noe slikt:

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 tallet er nøkkelbiten, da er nøkkelen i seg selv, og til slutt har du filen den er lagret i. Sammenlign den midterste delen til det du ser når du blir bedt om å logge på eksternt. Det burde matche, og du er helt klar. Hvis det ikke gjør det, kan noe annet skje.

Du kan vise alle vertene du har koblet til via SSH, ved å se på your known_hosts-filen. Det er vanligvis plassert på:

~ / .Ssh / known_hosts

Du kan åpne det i et tekstredigeringsprogram. Hvis du ser, prøv å være oppmerksom på hvordan nøklene lagres. De er lagret med vertsdatamaskinens navn (eller nettadresse) og dens IP-adresse.

Endre vertsnøkler og problemer

Det er noen grunner til at vertsnøkler endrer seg, eller de samsvarer ikke med det som er logget inn i filen known_hosts.

Systemet ble installert / re-konfigurert.
Vertsnøklene ble manuelt endret på grunn av sikkerhetsprotokoller.
OpenSSH-serveren oppdateres og bruker ulike standarder på grunn av sikkerhetsproblemer.
IP- eller DNS-leieavtalen endret seg. Dette betyr ofte at du prøver å få tilgang til en annen datamaskin.
Systemet ble kompromittert på en måte slik at vertsnøkkelen endret seg.

Sannsynligvis er problemet et av de tre første, og du kan ignorere endringen. Hvis IP / DNS-leieavtalen endret, kan det være et problem med serveren, og du kan bli sendt til en annen maskin. Hvis du ikke er sikker på hva årsaken til endringen er, bør du antakelig anta at den er den siste på listen.

Hvordan OpenSSH håndterer ukjente verter

OpenSSH har en innstilling for hvordan den håndterer ukjente verter, reflektert i variabelen "StrictHostKeyChecking" (uten anførselstegn).

Avhengig av konfigurasjonen din, kan SSH-tilkoblinger med ukjente verter (hvis tastene ikke allerede finnes i filen known_hosts) gå tre måter.

StrictHostKeyChecking er satt til nei; OpenSSH vil automatisk koble til en hvilken som helst SSH-server uansett vertsnøkkelstatus. Dette er usikkert og anbefales ikke, unntatt hvis du legger til en haug med verter etter en ominstallering av operativsystemet ditt, hvorpå du vil endre det tilbake.
StrictHostKeyChecking er satt til å spørre; OpenSSH vil vise deg nye vertsnøkler og be om bekreftelse før du legger til dem. Det vil forhindre at tilkoblinger går til endrede vertsnøkler. Dette er standard.
StrictHostKeyChecking er satt til ja; Det motsatte av "nei", dette forhindrer deg i å koble til noen vert som ikke allerede er til stede i filen known_hosts.

Du kan enkelt endre denne variabelen på kommandolinjen ved å bruke følgende paradigme:

ssh -o 'StrictHostKeyChecking [option]' bruker @ vert

Erstatt [alternativ] med "nei", "spør" eller "ja". Vær oppmerksom på at det er enkle rette anførselstegn rundt denne variabelen og dens innstilling. Erstatt også bruker @ verten med brukernavnet og vertsnavnet til serveren du kobler til. For eksempel:

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

Blokkerte verter på grunn av endrede taster

Hvis du har en server du prøver å få tilgang til som hadde nøkkelen allerede endret, vil standard OpenSSH-konfigurasjonen forhindre deg i å få tilgang til den. Du kan endre StrictHostKeyChecking-verdien for den verten, men det ville ikke være helt, grundig, paranoid sikker, ville det? I stedet kan vi bare fjerne den fornærmende verdien fra vår known_hosts-fil.

Det er definitivt en stygg ting å ha på skjermen. Heldigvis var grunnen til dette et reinstallert OS. Så, la oss zoome inn på linjen vi trenger.

Der går vi. Se hvordan det citerer filen vi trenger å redigere? Det gir oss selv linjenummeret! Så la oss åpne den filen i Nano:

Her er vår offending nøkkel, i linje 1. Alt vi trenger å gjøre er å trykke Ctrl + K for å kutte ut hele linjen.

Det er mye bedre! Så, nå treffer vi Ctrl + O for å skrive ut (lagre) filen, og deretter Ctrl + X for å avslutte.

Nå får vi en fin prompten i stedet, som vi ganske enkelt kan svare med "ja".

Opprette nye vertsnøkler

For posten er det egentlig ikke for mye grunn til at du kan endre vertsnøkkelen i det hele tatt, men hvis du noen gang finner behovet, kan du lett gjøre det.

Først skift til riktig systemkatalog:

cd / etc / ssh /

Dette er vanligvis der de globale vertsnøklene er, selv om noen distroer har dem plassert andre steder. Når du er i tvil, sjekk dokumentasjonen!

Deretter sletter vi alle de gamle nøklene.

sudo rm / etc / ssh / ssh_host_ *

Alternativt kan du flytte dem til en sikker sikkerhetskatalog. Bare en tanke!

Da kan vi fortelle OpenSSH-serveren om å omkonfigurere seg selv:

sudo dpkg-omkonfigurere openssh-server

Du får en melding når datamaskinen lager sine nye nøkler. Ta-da!

Nå som du vet hvordan SSH fungerer litt bedre, bør du være i stand til å komme deg ut av vanskelige flekker. Feilmeldingen "Fjern vertsidentifikasjon har endret" er noe som kaster mange brukere av, selv de som er kjent med kommandolinjen.