Vi har lovordat SSHs fördelar flera gånger, både för säkerhet och fjärråtkomst. Låt oss ta en titt på själva servern, några viktiga "underhåll" -aspekter och några konstigheter som kan ge turbulens till en annars smidig körning.
Även om vi har skrivit den här guiden med Linux i åtanke kan detta också gälla OpenSSH i Mac OS X och Windows 7 via Cygwin .
Varför är det säkert?
Vi har nämnt många gånger hur SSH är ett utmärkt sätt att säkert ansluta och tunnelera data från en punkt till en annan. Låt oss ta en mycket kort titt på hur saker fungerar så att du får en bättre uppfattning om varför saker och ting kan gå konstigt ibland.
När vi bestämmer oss för att ansluta till en annan dator använder vi ofta protokoll som är lätta att arbeta med. Telnet och FTP kommer båda att tänka på. Vi skickar ut information till en fjärrserver och sedan får vi en bekräftelse om vår anslutning. För att skapa någon typ av säkerhet använder dessa protokoll ofta användarnamn och lösenordskombinationer. Det betyder att de är helt säkra, eller hur? Fel!
Om vi tänker på vår anslutningsprocess som e-post är det inte som att använda FTP och Telnet och liknande som att använda vanliga e-postkuvert. Det är mer som att använda vykort. Om någon råkar gå i mitten kan de se all information, inklusive adresserna till båda korrespondenterna och användarnamnet och lösenordet som skickats ut. De kan sedan ändra meddelandet, hålla informationen densamma och efterlikna en korrespondent eller den andra. Detta är känt som en "man-i-mitten" -attack, och inte bara äventyrar det ditt konto, utan det ifrågasätter varje meddelande som skickas och mottagen fil. Du kan inte vara säker på om du pratar med avsändaren eller inte, och även om du är det kan du inte vara säker på att ingen tittar på allt däremellan.
Låt oss nu titta på SSL-kryptering, den typ som gör HTTP säkrare. Här har vi ett postkontor som hanterar korrespondensen, som kontrollerar om din mottagare är den han eller hon påstår sig vara, och har lagar som skyddar din e-post från att ses. Det är överlag säkrare och den centrala myndigheten - Verisign är en, för vårt HTTPS-exempel - ser till att personen som du skickar e-post till checkar ut. De gör detta genom att inte tillåta vykort (okrypterade referenser); istället föreskriver de riktiga kuvert.
Slutligen, låt oss titta på SSH. Här är installationen lite annorlunda. Vi har ingen central autentiserare här, men saker och ting är fortfarande säkra. Det beror på att du skickar brev till någon vars adress du redan känner - säg genom att chatta med dem i telefon - och du använder en riktigt snygg matematik för att underteckna ditt kuvert. Du överlämnar det till din bror, flickvän, pappa eller dotter för att ta det till adressen, och bara om mottagarens fina matematiska matchningar antar du att adressen är som den ska vara. Då får du ett brev tillbaka, också skyddad från nyfikna ögon av denna fantastiska matte. Slutligen skickar du dina referenser i ett annat hemligt algoritmiskt förtrollat kuvert till destinationen. Om matematiken inte matchar kan vi anta att den ursprungliga mottagaren flyttade och vi måste bekräfta deras adress igen.
Med förklaringen så länge den är tror vi att vi kommer att klippa den där. Om du har lite mer insikt kan du naturligtvis gärna chatta i kommentarerna. Låt oss dock för närvarande titta på den mest relevanta funktionen i SSH, värdautentisering.
Värdnycklar
Värdautentisering är i princip den del där någon du litar på tar kuvertet (förseglat med magisk matematik) och bekräftar adressen till din mottagare. Det är en ganska detaljerad beskrivning av adressen och den är baserad på lite komplicerad matematik som vi bara hoppar över. Det finns dock ett par viktiga saker att ta bort från detta:
- Eftersom det inte finns någon central myndighet ligger den verkliga säkerheten i värdnyckeln, de offentliga nycklarna och de privata nycklarna. (Dessa två nycklar konfigureras när du får åtkomst till systemet.)
- När du ansluter till en annan dator via SSH lagras vanligtvis värdnyckeln. Detta gör framtida åtgärder snabbare (eller mindre detaljerade).
- Om värdnyckeln ändras kommer du troligen att bli varnad och du bör vara försiktig!
Eftersom värdnyckeln används före autentisering för att fastställa identiteten på SSH-servern bör du vara noga med att kontrollera nyckeln innan du ansluter. Du kommer att se en bekräftelsedialog som nedan.
Du bör dock inte oroa dig! Ofta när säkerhet är ett problem kommer det att finnas en speciell plats där värdnyckeln (ECDSA fingeravtryck ovan) kan bekräftas. I helt online-satsningar kommer det ofta att finnas på en säker inloggningssida. Du kan behöva (eller välja!) Ringa din IT-avdelning för att bekräfta den här knappen via telefon. Jag har till och med hört talas om några platser där nyckeln finns på ditt arbetsmärke eller på den speciella listan "Nödnummer". Och om du har fysisk tillgång till målmaskinen kan du också kolla själv!
Kontrollerar ditt systems värdnyckel
Det finns fyra typer av krypteringsalgoritmer som används för att skapa nycklar, men standard för OpenSSH från och med tidigare i år är ECDSA ( med några goda skäl ). Vi kommer att fokusera på den idag. Här är kommandot du kan köra på SSH-servern du har tillgång till:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Din produktion ska returnera ungefär så här:
256 ца: 62: еа: щц: еч: яй: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
Det första numret är nyckelns bitlängd, sedan är det nyckeln i sig, och slutligen har du filen som den är lagrad i. Jämför den mellersta delen med vad du ser när du uppmanas att logga in på distans. Det borde matcha, och du är redo. Om det inte gör det kan något annat hända.
Du kan visa alla värdarna du har anslutit till via SSH genom att titta på din kända_hosts-fil. Det ligger vanligtvis på:
~ / .ssh / kända_hostar
Du kan öppna det i valfri textredigerare. Om du tittar, försök vara uppmärksam på hur nycklar lagras. De lagras med värddatorns namn (eller webbadress) och dess IP-adress.
Ändra värdnycklar och problem
Det finns några anledningar till att värdnycklar ändras eller att de inte matchar det som är inloggat i din kända värdfil.
- Systemet installerades om / konfigurerades om.
- Värdnycklarna ändrades manuellt på grund av säkerhetsprotokoll.
- OpenSSH-servern har uppdaterats och använder olika standarder på grund av säkerhetsproblem.
- IP- eller DNS-hyresavtalet har ändrats. Detta innebär ofta att du försöker komma åt en annan dator.
- Systemet komprometterades på något sätt så att värdnyckeln ändrades.
Troligtvis är problemet en av de tre första, och du kan ignorera förändringen. Om IP / DNS-hyresavtalet ändras kan det vara ett problem med servern och du kan dirigeras till en annan maskin. Om du inte är säker på orsaken till ändringen bör du antagligen anta att den är den sista på listan.
Hur hanterar OpenSSH okända värdar
OpenSSH har en inställning för hur den hanterar okända värdar, vilket återspeglas i variabeln "StrictHostKeyChecking" (utan citat).
Beroende på din konfiguration kan SSH-anslutningar med okända värdar (vars nycklar inte redan finns i din kända_hosts-fil) gå tre sätt.
- StrictHostKeyChecking är satt till nej; OpenSSH ansluter automatiskt till vilken SSH-server som helst, oavsett värdnyckelstatus. Detta är osäkert och rekommenderas inte, förutom om du lägger till en massa värdar efter en ominstallation av ditt operativsystem, varefter du kommer att ändra tillbaka det.
- StrictHostKeyChecking är inställd på att fråga; OpenSSH visar nya värdnycklar och ber om bekräftelse innan du lägger till dem. Det förhindrar att anslutningar går till ändrade värdnycklar. Detta är standard.
- StrictHostKeyChecking är satt till ja; Motsatsen till "nej", detta kommer att hindra dig från att ansluta till någon värd som inte redan finns i din kända_hosts-fil.
Du kan enkelt ändra denna variabel på kommandoraden med hjälp av följande paradigm:
ssh -o 'StrictHostKeyChecking [option]' användare @ värd
Byt ut [option] med "nej", "fråga" eller "ja". Var medveten om att det finns enstaka raka citat kring denna variabel och dess inställning. Ersätt också user @ host med användarnamnet och värdnamnet på servern du ansluter till. Till exempel:
ssh -o 'StrictHostKeyChecking ask' [email protected]
Blockerade värdar på grund av ändrade nycklar
Om du har en server som du försöker komma åt som hade nyckeln redan ändrats, kommer OpenSSH-standardkonfigurationen att hindra dig från att komma åt den. Du kan ändra StrictHostKeyChecking-värdet för den värden, men det skulle inte vara helt, grundligt, paranoid säkert, eller hur? Istället kan vi helt enkelt ta bort det kränkande värdet från vår kända_hosts-fil.
Det är definitivt en ful sak att ha på skärmen. Lyckligtvis var vår anledning till detta ett ominstallerat operativsystem. Så, låt oss zooma in på den linje vi behöver.
Där går vi. Se hur den citerar filen vi behöver redigera? Det ger oss till och med linjenumret! Så, låt oss öppna filen i Nano:
Här är vår stötande nyckel, i rad 1. Allt vi behöver göra är att trycka på Ctrl + K för att klippa ut hela raden.
Det är mycket bättre! Så nu slår vi Ctrl + O för att skriva ut (spara) filen, sedan Ctrl + X för att avsluta.
Nu får vi en trevlig uppmaning istället, som vi helt enkelt kan svara med "ja".
Skapa nya värdnycklar
För ordens skull finns det verkligen inte för mycket av en anledning för dig att byta värdnyckel alls, men om du någonsin hittar behovet kan du göra det enkelt.
Byt först till lämplig systemkatalog:
cd / etc / ssh /
Det är vanligtvis där de globala värdnycklarna finns, även om vissa distros har dem placerade någon annanstans. Om du är osäker, kontrollera din dokumentation!
Därefter tar vi bort alla gamla nycklar.
sudo rm / etc / ssh / ssh_host_ *
Alternativt kanske du vill flytta dem till en säker säkerhetskopieringskatalog. Bara en tanke!
Sedan kan vi be OpenSSH-servern att konfigurera om sig själv:
sudo dpkg-omkonfigurera openssh-server
Du får en uppmaning medan din dator skapar sina nya nycklar. Ta-da!
Nu när du vet hur SSH fungerar lite bättre, borde du kunna ta dig ur svåra fläckar. Varningen / felet ”Fjärrvärdidentifiering har ändrats” är något som kastar många användare bort, även de som är bekanta med kommandoraden.
För bonuspoäng kan du kolla in Hur man fjärrkopierar filer över SSH utan att ange ditt lösenord . Där lär du dig lite mer om andra typer av krypteringsalgoritmer och hur du använder nyckelfiler för ökad säkerhet.
