We hebben de deugden van SSH al meerdere keren geprezen, zowel voor beveiliging als voor externe toegang. Laten we eens kijken naar de server zelf, enkele belangrijke "onderhoudsaspecten" en enkele eigenaardigheden die turbulentie kunnen toevoegen aan een anders vlotte rit.
Hoewel we deze handleiding met Linux in gedachten hebben geschreven, kan dit ook van toepassing zijn op OpenSSH in Mac OS X en Windows 7 via Cygwin .
Waarom het veilig is
We hebben al vaak gezegd dat SSH een geweldige manier is om veilig verbinding te maken en gegevens van het ene punt naar het andere te tunnelen. Laten we eens heel kort kijken hoe de dingen werken, zodat u een beter idee krijgt waarom dingen soms raar kunnen gaan.
Wanneer we besluiten om een verbinding met een andere computer tot stand te brengen, gebruiken we vaak protocollen waarmee we gemakkelijk kunnen werken. Telnet en FTP komen beide voor de geest. We sturen informatie naar een externe server en dan krijgen we een bevestiging terug over onze verbinding. Deze protocollen gebruiken vaak combinaties van gebruikersnaam en wachtwoord om een bepaalde vorm van veiligheid tot stand te brengen. Dat betekent dat ze volledig veilig zijn, toch? Mis!
Als we ons verbindingsproces als e-mail beschouwen, dan is het gebruik van FTP en Telnet en dergelijke niet hetzelfde als het gebruik van standaard mailing-enveloppen. Het is meer zoals ansichtkaarten gebruiken. Als iemand toevallig in het midden stapt, kunnen ze alle informatie zien, inclusief de adressen van beide correspondenten en de verzonden gebruikersnaam en wachtwoord. Ze kunnen dan het bericht wijzigen, de informatie hetzelfde houden en zich voordoen als de ene correspondent of de andere. Dit staat bekend als een "man-in-the-middle" -aanval en brengt niet alleen uw account in gevaar, maar het roept ook vragen op over elk verzonden bericht en ontvangen bestand. Je kunt er niet zeker van zijn of je met de afzender praat of niet, en zelfs als je dat wel bent, weet je niet zeker of niemand alles tussendoor bekijkt.
Laten we nu eens kijken naar SSL-codering, het soort dat HTTP veiliger maakt. Hier hebben we een postkantoor dat de correspondentie afhandelt, controleert of uw ontvanger is wie hij of zij beweert te zijn, en dat er wetten zijn die voorkomen dat uw post wordt bekeken. Het is over het algemeen veiliger en de centrale autoriteit - Verisign is er een, in ons HTTPS-voorbeeld - zorgt ervoor dat de persoon naar wie u e-mail verzendt, uitcheckt. Ze doen dit door briefkaarten (niet-versleutelde inloggegevens) niet toe te staan; in plaats daarvan verplichten ze echte enveloppen.
Laten we tot slot eens kijken naar SSH. Hier is de opzet een beetje anders. We hebben hier geen centrale authenticator, maar alles is nog steeds veilig. Dat komt omdat je brieven stuurt naar iemand wiens adres je al kent, bijvoorbeeld door met hem te chatten aan de telefoon, en je gebruikt een paar heel mooie wiskunde om je envelop te ondertekenen. U overhandigt het aan uw broer, vriendin, vader of dochter om het naar het adres te brengen, en alleen als de ontvanger fraaie rekenovereenkomsten heeft, gaat u ervan uit dat het adres is wat het zou moeten zijn. Dan krijg je een brief terug, ook beschermd tegen nieuwsgierige blikken door deze geweldige wiskunde. Ten slotte stuurt u uw inloggegevens in een andere geheime, algoritmisch betoverde envelop naar de bestemming. Als de berekening niet overeenkomt, kunnen we aannemen dat de oorspronkelijke ontvanger is verhuisd en dat we zijn adres opnieuw moeten bevestigen.
Met de uitleg zolang die is, denken we dat we het daar zullen redden. Als je wat meer inzicht hebt, kun je natuurlijk chatten in de comments. Laten we voorlopig eens kijken naar de meest relevante functie van SSH, hostverificatie.
Hostsleutels
Hostauthenticatie is in wezen het gedeelte waar iemand die u vertrouwt de envelop (verzegeld met magische wiskunde) neemt en het adres van uw ontvanger bevestigt. Het is een vrij gedetailleerde beschrijving van het adres, en het is gebaseerd op ingewikkelde wiskunde die we meteen overslaan. Er zijn echter een aantal belangrijke dingen die u hieraan kunt onttrekken:
- Aangezien er geen centrale autoriteit is, ligt de echte beveiliging in de hostsleutel, de publieke sleutels en de privésleutels. (Deze laatste twee sleutels worden geconfigureerd wanneer u toegang tot het systeem krijgt.)
- Wanneer u via SSH verbinding maakt met een andere computer, wordt de hostsleutel meestal opgeslagen. Dit maakt toekomstige acties sneller (of minder uitgebreid).
- Als de hostsleutel verandert, wordt u waarschijnlijk gewaarschuwd en moet u op uw hoede zijn!
Aangezien de hostsleutel vóór authenticatie wordt gebruikt om de identiteit van de SSH-server vast te stellen, moet u de sleutel controleren voordat u verbinding maakt. U ziet een bevestigingsvenster zoals hieronder.
U hoeft zich echter geen zorgen te maken! Als de beveiliging een probleem is, is er vaak een speciale plaats waar de hostsleutel (ECDSA-vingerafdruk hierboven) kan worden bevestigd. In volledig online ondernemingen zal het vaak op een beveiligde site zijn om alleen in te loggen. Mogelijk moet u (of ervoor kiezen!) Uw IT-afdeling bellen om deze sleutel telefonisch te bevestigen. Ik heb zelfs wel eens gehoord van plaatsen waar de sleutel op je werkbadge staat of op de speciale lijst met noodnummers. En als u fysieke toegang tot de doelmachine heeft, kunt u dit ook zelf controleren!
De hostsleutel van uw systeem controleren
Er zijn 4 soorten versleutelingsalgoritmen die worden gebruikt om sleutels te maken, maar de standaard voor OpenSSH sinds eerder dit jaar is ECDSA ( met een aantal goede redenen ). We zullen ons daar vandaag op concentreren. Hier is de opdracht die u kunt uitvoeren op de SSH-server waartoe u toegang hebt:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Je output zou zoiets als dit moeten retourneren:
256 ца: 62: еа: щц: еч: яй: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
Het eerste getal is de bitlengte van de sleutel, daarna de sleutel zelf, en als laatste heb je het bestand waarin het is opgeslagen. Vergelijk dat middelste gedeelte met wat je ziet wanneer je wordt gevraagd om op afstand in te loggen. Het moet overeenkomen, en je bent helemaal klaar. Als dit niet het geval is, kan er iets anders gebeuren.
U kunt alle hosts waarmee u via SSH bent verbonden, bekijken door naar uw bekende_hosts-bestand te kijken. Het bevindt zich meestal op:
~ / .ssh / bekende_hosts
U kunt dat openen in elke teksteditor. Als je kijkt, probeer dan op te letten hoe sleutels worden bewaard. Ze worden opgeslagen met de naam (of het webadres) van de hostcomputer en het IP-adres.
Hostsleutels en problemen wijzigen
Er zijn een paar redenen waarom hostsleutels veranderen of ze komen niet overeen met wat er in uw bekende_hosts-bestand is vastgelegd.
- Het systeem is opnieuw geïnstalleerd / opnieuw geconfigureerd.
- De hostsleutels zijn handmatig gewijzigd vanwege beveiligingsprotocollen.
- De OpenSSH-server is bijgewerkt en gebruikt verschillende standaarden vanwege beveiligingsproblemen.
- De IP- of DNS-lease is gewijzigd. Dit betekent vaak dat u probeert toegang te krijgen tot een andere computer.
- Het systeem is op de een of andere manier gecompromitteerd, waardoor de hostsleutel is gewijzigd.
Hoogstwaarschijnlijk is het probleem een van de eerste drie en kunt u de wijziging negeren. Als de IP / DNS-lease is gewijzigd, is er mogelijk een probleem met de server en wordt u mogelijk doorgestuurd naar een andere machine. Als u niet zeker weet wat de reden voor de wijziging is, moet u er waarschijnlijk van uitgaan dat dit de laatste is op de lijst.
Hoe OpenSSH omgaat met onbekende hosts
OpenSSH heeft een instelling voor hoe het onbekende hosts behandelt, weerspiegeld in de variabele "StrictHostKeyChecking" (zonder aanhalingstekens).
Afhankelijk van uw configuratie kunnen SSH-verbindingen met onbekende hosts (waarvan de sleutels niet al in uw bekende_hosts-bestand staan) drie kanten op.
- StrictHostKeyChecking is ingesteld op nee; OpenSSH maakt automatisch verbinding met elke SSH-server, ongeacht de status van de hostsleutel. Dit is onveilig en wordt niet aanbevolen, behalve als u een aantal hosts toevoegt na een herinstallatie van uw besturingssysteem, waarna u het weer terugzet.
- StrictHostKeyChecking is ingesteld om te vragen; OpenSSH zal u nieuwe hostsleutels laten zien en om bevestiging vragen voordat ze worden toegevoegd. Het voorkomt dat verbindingen naar gewijzigde hostsleutels gaan. Dit is standaard.
- StrictHostKeyChecking is ingesteld op ja; Het tegenovergestelde van "nee", dit voorkomt dat u verbinding maakt met een host die nog niet aanwezig is in het bestand bekende_hosts.
U kunt deze variabele eenvoudig op de opdrachtregel wijzigen door het volgende paradigma te gebruiken:
ssh -o 'StrictHostKeyChecking [option]' gebruiker @ host
Vervang [option] door 'nee', 'vragen' of 'ja'. Houd er rekening mee dat er enkele rechte aanhalingstekens zijn rond deze variabele en zijn instelling. Vervang ook user @ host door de gebruikersnaam en hostnaam van de server waarmee u verbinding maakt. Bijvoorbeeld:
ssh -o 'StrictHostKeyChecking vraag' [email protected]
Geblokkeerde hosts vanwege gewijzigde sleutels
Als u een server heeft waartoe u toegang probeert te krijgen waarvan de sleutel al is gewijzigd, zal de standaard OpenSSH-configuratie voorkomen dat u er toegang toe krijgt. Je zou de StrictHostKeyChecking-waarde voor die host kunnen veranderen, maar dat zou niet helemaal, grondig, paranoïde veilig zijn, toch? In plaats daarvan kunnen we eenvoudig de aanstootgevende waarde verwijderen uit ons bekende_hosts-bestand.
Dat is absoluut lelijk om op je scherm te hebben. Gelukkig was onze reden hiervoor een opnieuw geïnstalleerd besturingssysteem. Laten we dus inzoomen op de lijn die we nodig hebben.
Daar gaan we. Zie je hoe het het bestand citeert dat we moeten bewerken? Het geeft ons zelfs het regelnummer! Dus laten we dat bestand openen in Nano:
Hier is onze aanstootgevende sleutel, in regel 1. Het enige wat we hoeven te doen is op Ctrl + K drukken om de hele regel uit te knippen.
Dat is veel beter! Dus nu drukken we op Ctrl + O om het bestand weg te schrijven (op te slaan) en vervolgens op Ctrl + X om af te sluiten.
Nu krijgen we in plaats daarvan een leuke prompt, waarop we eenvoudig kunnen reageren met "ja".
Nieuwe hostsleutels maken
Voor de goede orde, er is echt niet al te veel reden om uw hostsleutel helemaal te wijzigen, maar als u ooit de behoefte vindt, kunt u het gemakkelijk doen.
Ga eerst naar de juiste systeemdirectory:
cd / etc / ssh /
Dit is meestal waar de globale hostsleutels zijn, hoewel sommige distributies ze ergens anders hebben geplaatst. Raadpleeg bij twijfel uw documentatie!
Vervolgens verwijderen we alle oude sleutels.
sudo rm / etc / ssh / ssh_host_ *
U kunt ze ook naar een veilige back-upmap verplaatsen. Alleen een gedachte!
Vervolgens kunnen we de OpenSSH-server vertellen om zichzelf opnieuw te configureren:
sudo dpkg-reconfigure openssh-server
U ziet een prompt terwijl uw computer de nieuwe sleutels aanmaakt. Ta-da!
Nu je weet hoe SSH een beetje beter werkt, zou je uit lastige situaties moeten kunnen komen. De waarschuwing / fout "Remote Host Identification Has Changed" is iets dat veel gebruikers in de war brengt, zelfs degenen die bekend zijn met de opdrachtregel.
Voor bonuspunten kunt u uitchecken Hoe u op afstand bestanden kunt kopiëren via SSH zonder uw wachtwoord in te voeren . Daar leert u wat meer over de andere soorten versleutelingsalgoritmen en hoe u sleutelbestanden kunt gebruiken voor extra beveiliging.
