Vi har hyllet fordelene med SSH flere ganger, både for sikkerhet og ekstern tilgang. La oss ta en titt på selve serveren, noen viktige "vedlikehold" -aspekter og noen særegenheter som kan gi turbulens til en ellers jevn tur.
Mens vi har skrevet denne veiledningen med tanke på Linux, kan dette også gjelde OpenSSH i Mac OS X og Windows 7 via Cygwin .
Hvorfor det er sikkert
Vi har mange ganger nevnt hvordan SSH er en fin måte å koble til og tunnelere data sikkert fra et punkt til et annet. La oss ta en kort titt på hvordan ting fungerer, slik at du får en bedre ide om hvorfor ting kan gå rart noen ganger.
Når vi bestemmer oss for å koble til en annen datamaskin, bruker vi ofte protokoller som er enkle å jobbe med. Telnet og FTP kommer begge til å tenke på. Vi sender ut informasjon til en ekstern server, og deretter får vi bekreftelse om forbindelsen vår. For å etablere en slags sikkerhet bruker disse protokollene ofte brukernavn og passordkombinasjoner. Det betyr at de er helt sikre, ikke sant? Feil!
Hvis vi tenker på vår tilkoblingsprosess som e-post, er det ikke som å bruke FTP og Telnet og lignende som å bruke standard postkonvolutter. Det er mer som å bruke postkort. Hvis noen kommer inn i midten, kan de se all informasjonen, inkludert adressene til begge korrespondentene og brukernavnet og passordet som sendes ut. De kan da endre meldingen, holde informasjonen den samme og utgi seg for den ene korrespondenten eller den andre. Dette er kjent som et "mann-i-midten" -angrep, og ikke bare kompromitterer det kontoen din, men den setter spørsmålstegn ved hver melding som sendes og mottatte filer. Du kan ikke være sikker på om du snakker med avsenderen eller ikke, og selv om du er det, kan du ikke være sikker på at ingen ser på alt imellom.
La oss nå se på SSL-kryptering, den typen som gjør HTTP sikrere. Her har vi et postkontor som håndterer korrespondansen, som sjekker om mottakeren din er den han eller hun hevder å være, og har lover som beskytter e-posten din fra å bli sett på. Generelt er det sikrere, og den sentrale autoriteten - 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 (ukryptert legitimasjon); i stedet mandater de ekte konvolutter.
Til slutt, la oss se på SSH. Her er oppsettet litt annerledes. Vi har ikke en sentral godkjenning her, men ting er fortsatt sikre. Det er fordi du sender brev til noen hvis adresse du allerede kjenner - si, ved å chatte med dem på telefonen - og du bruker litt fancy matte for å signere konvolutten din. Du overleverer det til broren, kjæresten, pappaen eller datteren din for å ta den med til adressen, og bare hvis mottakerens fancy matteoppgjør antar du at adressen er slik den skal være. Så får du et brev tilbake, også beskyttet mot nysgjerrige øyne av denne fantastiske matematikken. Til slutt sender du legitimasjonen din i en annen hemmelighetsfull algoritmisk fortryllet konvolutt til destinasjonen. Hvis matematikken ikke stemmer overens, kan vi anta at den opprinnelige mottakeren flyttet, og vi må bekrefte adressen deres på nytt.
Med forklaringen så lenge den er, tror vi vi vil kutte den der. Hvis du har litt mer innsikt, kan du selvfølgelig gjerne chatte i kommentarene. For nå, skjønt, la oss se på den mest relevante funksjonen i SSH, vertsautentisering.
Vertsnøkler
Vertsautentisering er egentlig den delen der noen du stoler på tar konvolutten (forseglet med magisk matematikk) og bekrefter adressen til mottakeren din. Det er en ganske detaljert beskrivelse av adressen, og den er basert på litt komplisert matte som vi bare hopper rett over. Det er et par viktige ting å ta bort fra dette, skjønt:
- Siden det ikke er noen sentral autoritet, ligger den virkelige sikkerheten i vertsnøkkelen, de offentlige nøklene og de private nøklene. (Disse to sistnevnte tastene er konfigurert når du får tilgang til systemet.)
- Når du kobler til en annen datamaskin via SSH, lagres vertsnøkkelen vanligvis. Dette gjør fremtidige handlinger raskere (eller mindre detaljerte).
- 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 å fastslå 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! Ofte når sikkerhet er en bekymring, vil det være et spesielt sted som vertsnøkkelen (ECDSA fingeravtrykk ovenfor) kan bekreftes. I helt elektroniske virksomheter vil det ofte være på et sikkert innloggingsside. Du må kanskje (eller velge å!) Ringe IT-avdelingen din for å bekrefte denne nøkkelen over telefon. Jeg har til og med hørt om noen steder der nøkkelen er på arbeidsmerket ditt eller på den spesielle listen "Nødnumre". Og hvis du har fysisk tilgang til målmaskinen, kan du også sjekke selv!
Kontrollerer systemets vertsnøkkel
Det er fire typer krypteringsalgoritmer som brukes til å lage nøkler, men standard for OpenSSH som 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
Produksjonen din skal returnere noe sånt som dette:
256 ца: 62: еа: щц: еч: яй: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
Det første tallet er bitlengden på nøkkelen, så er det selve nøkkelen, og til slutt har du filen den er lagret i. Sammenlign den midtre delen med det du ser når du blir bedt om å logge på eksternt. Det skal stemme overens, og du er klar. Hvis den ikke gjør det, kan noe annet skje.
Du kan se alle vertene du har koblet til via SSH ved å se på filen kjent_hosts. Det ligger vanligvis på:
~ / .ssh / kjent_hosts
Du kan åpne det i hvilken som helst tekstredigerer. Hvis du ser, kan du prøve å ta hensyn til hvordan nøkler lagres. De lagres med vertsdatamaskinens navn (eller nettadresse) og IP-adressen.
Endre vertsnøkler og problemer
Det er noen grunner til at vertsnøkler endres, eller at de ikke samsvarer med det som er logget inn i kjent_hosts-filen.
- Systemet ble reinstallert / re-konfigurert.
- Vertsnøklene ble endret manuelt på grunn av sikkerhetsprotokoller.
- OpenSSH-serveren er oppdatert og bruker forskjellige 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 eller annen måte slik at vertsnøkkelen endret seg.
Mest sannsynlig er problemet en av de tre første, og du kan ignorere endringen. Hvis IP / DNS-leieavtalen endret seg, kan det være et problem med serveren, og du kan bli dirigert til en annen maskin. Hvis du ikke er sikker på hva årsaken til endringen er, bør du sannsynligvis 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-forbindelser med ukjente verter (hvis nøkler ikke allerede er i filen kjent_hosts) gå tre måter.
- StrictHostKeyChecking er satt til nei; OpenSSH kobles automatisk til en hvilken som helst SSH-server uavhengig av vertsnøkkelstatus. Dette er usikkert og anbefales ikke, bortsett fra hvis du legger til en rekke verter etter at du har installert operativsystemet på nytt, hvoretter 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 dem til. 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 deg til en hvilken som helst vert som ikke allerede er tilstede i filen kjent_hosts.
Du kan endre denne variabelen enkelt på kommandolinjen ved å bruke følgende paradigme:
ssh -o 'StrictHostKeyChecking [option]' bruker @ vert
Erstatt [option] 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å user @ host med brukernavnet og vertsnavnet til serveren du kobler til. For eksempel:
ssh -o 'StrictHostKeyChecking ask' [email protected]
Blokkerte verter på grunn av endrede nøkler
Hvis du har en server du prøver å få tilgang til når nøkkelen allerede er endret, vil standard OpenSSH-konfigurasjon forhindre deg i å få tilgang til den. Du kan endre verdien av StrictHostKeyChecking for den verten, men det ville ikke være helt, grundig, paranoid sikkert, ikke sant? I stedet kan vi bare fjerne den krenkende verdien fra filen kjent_hosts.
Det er definitivt en stygg ting å ha på skjermen. Heldigvis var årsaken til dette et installert operativsystem på nytt. Så la oss zoome inn på den linjen vi trenger.
Der går vi. Se hvordan den siterer filen vi trenger å redigere? Det gir oss til og med linjenummeret! Så la oss åpne filen i Nano:
Her er vår fornærmende 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å traff vi Ctrl + O for å skrive ut (lagre) filen, deretter Ctrl + X for å avslutte.
Nå får vi en hyggelig melding i stedet, som vi ganske enkelt kan svare med "ja."
Opprette nye vertsnøkler
For ordens skyld er det egentlig ikke så mye grunn til at du i det hele tatt skifter vertsnøkkel, men hvis du noen gang finner behovet, kan du gjøre det enkelt.
Først bytter du til riktig systemkatalog:
cd / etc / ssh /
Dette er vanligvis der de globale vertsnøklene er, selv om noen distroer har dem plassert andre steder. Hvis du er i tvil, sjekk dokumentasjonen din!
Deretter sletter vi alle de gamle tastene.
sudo rm / etc / ssh / ssh_host_ *
Alternativt kan det være lurt å flytte dem til en sikker sikkerhetskopikatalog. Bare en tanke!
Deretter kan vi be OpenSSH-serveren å konfigurere seg selv:
sudo dpkg-omkonfigurere openssh-server
Du får se en melding mens datamaskinen lager de nye nøklene. Ta-da!
Nå som du vet hvordan SSH fungerer litt bedre, bør du kunne få deg ut av tøffe steder. Advarselen / feilen “Remote Host Identification has Changed” er noe som kaster mange brukere, selv de som er kjent med kommandolinjen.
For bonuspoeng kan du sjekke ut Hvordan kopiere filer eksternt over SSH uten å oppgi passordet ditt . Der lærer du litt mer om de andre typer krypteringsalgoritmer og hvordan du bruker nøkkelfiler for ekstra sikkerhet.
