Leer de ins en outs van OpenSSH op uw Linux-pc

We hebben de deugden van SSH talloze malen geprezen, zowel voor beveiliging als externe toegang. Laten we eens kijken naar de server zelf, enkele belangrijke 'onderhouds'-aspecten en enkele eigenaardigheden die turbulentie kunnen toevoegen aan een anderszins vloeiende 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 vaak genoemd hoe SSH een uitstekende manier is om veilig gegevens met elkaar te verbinden en te tunnelen van het ene punt naar het andere. Laten we eens kort kijken hoe de dingen werken, zodat u een beter idee krijgt van waarom dingen soms vreemd kunnen gaan.

Wanneer we besluiten om een verbinding met een andere computer tot stand te brengen, gebruiken we vaak protocollen die gemakkelijk zijn om mee te 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. Om een bepaald soort veiligheid vast te stellen, gebruiken deze protocollen vaak combinaties van gebruikersnaam en wachtwoord. Dat betekent dat ze helemaal veilig zijn, toch? Fout!

Als we denken aan ons verbindingsproces als e-mail, dan is het gebruik van FTP en Telnet en dergelijke niet hetzelfde als het gebruik van standaard mailing-enveloppen. Het is meer zoals het gebruik van ansichtkaarten. Als iemand toevallig in het midden staat, kunnen ze alle informatie zien, inclusief de adressen van beide correspondenten en de verzonden gebruikersnaam en wachtwoord. Ze kunnen vervolgens het bericht wijzigen, de informatie hetzelfde houden en zich voordoen als correspondent of correspondent. Dit staat bekend als een "man-in-the-middle" -aanval, en niet alleen vormt het een compromis voor je account, maar het stelt ook elk verzonden bericht en bestand in vraag. Je weet niet zeker of je tegen de afzender praat of niet, en zelfs als je dat bent, weet je niet zeker dat niemand naar alles kijkt van daar tussenin.

Laten we nu kijken naar SSL-codering, het soort dat HTTP veiliger maakt. Hier hebben we een postkantoor dat de correspondentie afhandelt, die controleert of uw ontvanger is wie hij of zij beweert te zijn, en wetten heeft die uw e-mail beschermen tegen bekeken worden. Het is over het geheel genomen veiliger en de centrale autoriteit - Verisign is er een, voor ons HTTPS-voorbeeld - zorgt ervoor dat de persoon naar wie je mail verzendt, uitcheckt. Ze doen dit door geen ansichtkaarten toe te staan (niet-versleutelde inloggegevens); in plaats daarvan verplichten ze echte enveloppen.

Laten we tot slot kijken naar SSH. Hier is de setup een beetje anders. We hebben hier geen centrale authenticator, maar de dingen zijn nog steeds veilig. Dat komt omdat je brieven stuurt naar iemand van wie je het adres al kent - bijvoorbeeld door telefonisch met ze te chatten - en je gebruikt een heel mooie wiskunde om je envelop te ondertekenen. Je geeft het aan je broer, vriendin, vader of dochter om het naar het adres te brengen, en alleen als de fancy math matches van de ontvanger je doen veronderstellen dat het adres is wat het zou moeten zijn. Dan krijg je een brief terug, ook beschermd tegen nieuwsgierige blikken van deze geweldige wiskunde. Ten slotte verzendt u uw inloggegevens in een andere geheimzinnige algoritmisch betoverde envelop naar de bestemming. Als de wiskundige waarde niet overeenkomt, kunnen we aannemen dat de oorspronkelijke ontvanger is verplaatst en moeten we hun adres opnieuw bevestigen.

Met de uitleg zo lang als het is, denken we dat we het daar zullen snijden. Als je wat meer inzicht hebt, kun je natuurlijk in de reacties chatten. Laten we voorlopig echter kijken naar de meest relevante functie van SSH, host-authenticatie.

Host Keys

Hostverificatie is in wezen het deel waar iemand die u vertrouwt de envelop pakt (verzegeld met magische wiskunde) en bevestigt het adres van uw ontvanger. Het is een vrij gedetailleerde beschrijving van het adres, en het is gebaseerd op een ingewikkelde wiskunde die we gewoon overslaan. Er zijn echter een paar belangrijke dingen om hier vanaf te halen:

Omdat er geen centrale autoriteit is, ligt de echte beveiliging in de hostsleutel, de openbare sleutels en de privésleutels. (Deze laatste twee sleutels worden geconfigureerd wanneer u toegang krijgt tot het systeem.)
Gewoonlijk wordt, wanneer u via SSH verbinding maakt met een andere computer, de hostsleutel 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 verificatie 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.

Maar maak je geen zorgen! Vaak als beveiliging een probleem is, zal er een speciale plaats zijn waar de hostsleutel (ECDSA-vingerafdruk hierboven) kan worden bevestigd. In volledig online ondernemingen, zal het vaak op een beveiligde inlogsite staan. U moet misschien uw IT-afdeling bellen (of kiezen om!) Om deze sleutel per telefoon te bevestigen. Ik heb zelfs gehoord van een aantal plaatsen waar de sleutel op uw werkbadge staat of op de speciale lijst "Noodnummers". En als u fysieke toegang hebt tot de doelcomputer, kunt u dit ook zelf controleren!

De hostsleutel van uw systeem controleren

Er zijn 4 soorten soorten coderingsalgoritmen die worden gebruikt om sleutels te maken, maar de standaard voor OpenSSH vanaf eerder dit jaar is ECDSA (met enkele goede redenen). Daar zullen we ons 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 uitvoer zou iets als dit moeten retourneren:

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

Het eerste nummer is de bitlengte van de sleutel, dan is de sleutel zelf en uiteindelijk 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 dat niet het geval is, kan er iets anders gebeuren.

Je kunt alle hosts waarmee je verbonden bent via SSH bekijken door te kijken naar je known_hosts-bestand. Het bevindt zich meestal op:

~ / .Ssh / known_hosts

Je kunt dat openen in elke teksteditor. Als je kijkt, probeer dan op te letten hoe toetsen worden opgeslagen. Ze worden opgeslagen met de naam van de hostcomputer (of het internetadres) en het IP-adres.

Hostsleutels en problemen wijzigen

Er zijn een paar redenen waarom hostsleutels veranderen of ze komen niet overeen met wat is vastgelegd in uw known_hosts-bestand.

Het systeem is opnieuw geïnstalleerd / opnieuw geconfigureerd.
De hostsleutels zijn handmatig gewijzigd vanwege beveiligingsprotocollen.
De OpenSSH-server is bijgewerkt en gebruikt verschillende normen 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 zodanig aangetast dat 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 computer. Als u niet zeker weet wat de reden voor de wijziging is, moet u waarschijnlijk aannemen dat dit de laatste is in de lijst.

Hoe OpenSSH onbekende hosts verwerkt

OpenSSH heeft een instelling voor hoe het omgaat met onbekende hosts, weerspiegeld in de variabele "StrictHostKeyChecking" (zonder aanhalingstekens).

Afhankelijk van uw configuratie kunnen SSH-verbindingen met onbekende hosts (waarvan de sleutels zich nog niet in uw known_hosts-bestand bevinden) op drie manieren worden gebruikt.

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 het opnieuw installeren van uw besturingssysteem, waarna u het opnieuw wilt instellen.
StrictHostKeyChecking is ingesteld om te vragen; OpenSSH zal u nieuwe host-sleutels tonen en om bevestiging vragen voordat u ze toevoegt. Hiermee wordt voorkomen dat verbindingen naar gewijzigde hostsleutels gaan. Dit is de standaard.
StrictHostKeyChecking is ingesteld op Ja; Het tegenovergestelde van "nee", dit zal voorkomen dat u verbinding maakt met een host die nog niet aanwezig is in uw known_hosts-bestand.

U kunt deze variabele gemakkelijk op de opdrachtregel wijzigen met behulp van het volgende paradigma:

ssh -o 'StrictHostKeyCheck [option]' user @ host

Vervang [optie] door "nee", "vragen" of "ja". Houd er rekening mee dat er enkele rechte aanhalingstekens zijn rond deze variabele en de bijbehorende instelling. Vervang ook user @ host door de gebruikersnaam en de hostnaam van de server waarmee u verbinding maakt. Bijvoorbeeld:

ssh -o 'StrictHostKeyChecking ask' [email protected]

Geblokkeerde hosts vanwege gewijzigde sleutels

Als u een server probeert te openen waarvan de sleutel al is gewijzigd, voorkomt de standaard OpenSSH-configuratie dat u deze niet kunt openen. Je zou de StrictHostKeyChecking-waarde voor die host kunnen veranderen, maar dat zou niet helemaal, grondig, paranoïde beveiligd zijn, toch? In plaats daarvan kunnen we de overtredende waarde eenvoudig verwijderen uit ons known_hosts-bestand.

Dat is absoluut een lelijk ding op je scherm. Gelukkig was onze reden hiervoor een opnieuw geïnstalleerd besturingssysteem. Laten we 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! Laten we dat bestand dus openen in Nano:

Dit is onze beledigende sleutel, in regel 1. We hoeven alleen maar op Ctrl + K te drukken om de hele regel weg te knippen.

Dat is veel beter! Dus nu drukken we op Ctrl + O om het bestand op te schrijven (opslaan) en vervolgens Ctrl + X om af te sluiten.

Nu krijgen we in plaats daarvan een leuke prompt, waarop we eenvoudig kunnen antwoorden met "ja".

Nieuwe hostsleutels maken

Voor de duidelijkheid, er is echt geen reden te over om je host-sleutel helemaal te veranderen, maar als je ooit de behoefte vindt, kun je dat gemakkelijk doen.

Ga eerst naar de juiste systeemdirectory:

cd / etc / ssh /

Dit is meestal waar de globale host-sleutels zijn, hoewel sommige distributies deze ergens anders hebben geplaatst. Controleer bij twijfel uw documentatie!

Vervolgens verwijderen we alle oude sleutels.

sudo rm / etc / ssh / ssh_host_ *

U kunt ze ook verplaatsen naar een veilige back-upmap. Alleen een gedachte!

Vervolgens kunnen we de OpenSSH-server vertellen zichzelf te herconfigureren:

sudo dpkg-herconfigureert openssh-server

U ziet een prompt terwijl uw computer nieuwe sleutels maakt. Ta-da!

Nu je weet hoe SSH een beetje beter werkt, zou je in staat moeten zijn om jezelf uit moeilijke punten te krijgen. De waarschuwing / fout 'Remote Host Identification Has Changed' is iets dat veel gebruikers uitschakelt, zelfs degenen die bekend zijn met de opdrachtregel.