Lernen Sie das Ins und Out von OpenSSH auf Ihrem Linux-PC kennen

Wir haben die Vorteile von SSH mehrfach gefordert, sowohl für die Sicherheit als auch für den Fernzugriff. Werfen wir einen Blick auf den Server selbst, einige wichtige Aspekte der „Wartung“ und einige Macken, die Turbulenzen bei einer ansonsten reibungslosen Fahrt verursachen können.

Obwohl wir dieses Handbuch für Linux geschrieben haben, kann dies auch für OpenSSH unter Mac OS X und Windows 7 über Cygwin gelten.

Warum ist es sicher?

Wir haben oft erwähnt, dass SSH eine großartige Möglichkeit ist, Daten sicher von einem Punkt zum anderen zu verbinden und zu tunneln. Lassen Sie uns einen kurzen Blick darauf werfen, wie die Dinge funktionieren, damit Sie eine bessere Vorstellung davon bekommen, warum Dinge manchmal komisch werden können.

Wenn wir uns dazu entscheiden, eine Verbindung zu einem anderen Computer herzustellen, verwenden wir häufig Protokolle, mit denen einfach zu arbeiten ist. Mir fallen sowohl Telnet als auch FTP ein. Wir senden Informationen an einen Remote-Server und erhalten dann eine Bestätigung über unsere Verbindung. Um eine gewisse Sicherheit zu gewährleisten, verwenden diese Protokolle häufig Kombinationen aus Benutzername und Kennwort. Das heißt, sie sind absolut sicher, richtig? Falsch!

Wenn wir uns den Verbindungsprozess als E-Mail vorstellen, dann ist die Verwendung von FTP, Telnet und dergleichen nicht die Verwendung von Standard-Briefumschlägen. Es ist mehr wie Postkarten. Wenn jemand zufällig in die Mitte tritt, kann er alle Informationen sehen, einschließlich der Adressen der beiden Korrespondenten und des Benutzernamens und des gesendeten Passworts. Sie können dann die Nachricht ändern, wobei die Informationen gleich bleiben, und sich als der eine oder andere Korrespondent ausgeben. Dies ist als "Man-in-the-Middle" -Angriff bekannt, der nicht nur Ihren Account gefährdet, sondern auch jede gesendete Nachricht und empfangene Datei in Frage stellt. Sie können nicht sicher sein, ob Sie mit dem Absender sprechen oder nicht, und selbst wenn Sie es sind, können Sie nicht sicher sein, dass niemand auf alles dazwischen schaut.

Schauen wir uns nun die SSL-Verschlüsselung an, die HTTP sicherer macht. Hier haben wir eine Poststelle, die die Korrespondenz abwickelt. Sie prüft, ob Ihr Empfänger derjenige ist, für den er oder sie sich ausgibt, und verfügt über Gesetze, die verhindern, dass Ihre Post eingesehen wird. Es ist insgesamt sicherer, und die zentrale Behörde - Verisign ist eine für unser HTTPS-Beispiel - stellt sicher, dass die Person, der Sie E-Mails senden, sich auscheckt. Sie tun dies, indem sie keine Postkarten zulassen (unverschlüsselte Anmeldeinformationen); Stattdessen geben sie echte Umschläge vor.

Abschließend wollen wir uns SSH ansehen. Hier ist das Setup etwas anders. Wir haben hier keinen zentralen Authentifikator, aber die Dinge sind immer noch sicher. Das liegt daran, dass Sie Briefe an jemanden senden, dessen Adresse Sie bereits kennen - zum Beispiel, indem Sie mit ihnen am Telefon plaudern - und Sie eine ziemlich ausgefallene Mathematik verwenden, um Ihren Umschlag zu unterschreiben. Sie übergeben es Ihrem Bruder, Ihrer Freundin, Ihrem Vater oder Ihrer Tochter, um es an die Adresse zu bringen. Nur wenn die ausgefallenen mathematischen Übereinstimmungen des Empfängers der Fall sind, gehen Sie davon aus, dass die Adresse die ist, die sie sein sollte. Dann erhalten Sie einen Brief zurück, der durch diese großartige Mathematik auch vor neugierigen Blicken geschützt ist. Schließlich senden Sie Ihre Anmeldeinformationen in einem anderen geheimen, algorithmisch verzauberten Umschlag an das Ziel. Wenn die Berechnungen nicht übereinstimmen, können wir davon ausgehen, dass der ursprüngliche Empfänger verschoben wurde, und wir müssen ihre Adresse erneut bestätigen.

Mit der Erklärung, solange es ist, glauben wir, wir werden es dort schneiden. Wenn Sie mehr Einblick haben, plaudern Sie natürlich in den Kommentaren. Für den Moment betrachten wir jedoch die relevanteste Funktion der SSH-Hostauthentifizierung.

Host-Schlüssel

Die Host-Authentifizierung ist im Wesentlichen der Teil, bei dem jemand, dem Sie vertrauen, den Umschlag (mit Magie versiegelt) nimmt und die Adresse Ihres Empfängers bestätigt. Es ist eine ziemlich detaillierte Beschreibung der Adresse und basiert auf komplizierten Berechnungen, die wir einfach überspringen. Es gibt jedoch ein paar wichtige Dinge, die Sie mitnehmen sollten:

Da es keine zentrale Autorität gibt, liegt die eigentliche Sicherheit in dem Host-Schlüssel, den öffentlichen Schlüsseln und den privaten Schlüsseln. (Diese beiden letzten Tasten werden konfiguriert, wenn Sie Zugriff auf das System erhalten.)
Wenn Sie sich über SSH mit einem anderen Computer verbinden, wird der Host-Schlüssel normalerweise gespeichert. Dies macht zukünftige Aktionen schneller (oder weniger ausführlich).
Wenn sich der Host-Schlüssel ändert, werden Sie höchstwahrscheinlich gewarnt und sollten vorsichtig sein!

Da der Hostschlüssel vor der Authentifizierung zum Festlegen der Identität des SSH-Servers verwendet wird, sollten Sie den Schlüssel vor der Verbindung überprüfen. Sie sehen einen Bestätigungsdialog wie unten.

Sie sollten sich jedoch keine Sorgen machen! Wenn Sicherheit ein Problem ist, gibt es oft einen besonderen Ort, an dem der Host-Schlüssel (ECDSA-Fingerabdruck oben) bestätigt werden kann. Bei vollständig online betriebenen Projekten wird es häufig auf einer sicheren Anmeldeseite sein. Möglicherweise müssen Sie (oder wählen Sie!) Ihre IT-Abteilung anrufen, um diese Taste per Telefon zu bestätigen. Ich habe sogar von Orten gehört, an denen sich der Schlüssel auf Ihrem Arbeitsausweis oder auf der speziellen Liste der "Notrufnummern" befindet. Wenn Sie physischen Zugriff auf den Zielcomputer haben, können Sie dies auch selbst überprüfen!

Überprüfen des Host-Schlüssels Ihres Systems

Es gibt vier Arten von Verschlüsselungsalgorithmen, die zum Erstellen von Schlüsseln verwendet werden. Die Standardeinstellung für OpenSSH ist dieses Jahr jedoch ECDSA (mit einigen guten Gründen). Wir werden uns heute darauf konzentrieren. Hier ist der Befehl, den Sie auf dem SSH-Server ausführen können, auf den Sie Zugriff haben:

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

Ihre Ausgabe sollte ungefähr so aussehen:

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

Die erste Zahl ist die Bitlänge des Schlüssels, dann der Schlüssel selbst und schließlich haben Sie die Datei, in der sie gespeichert ist. Vergleichen Sie diesen mittleren Teil mit dem, was Sie sehen, wenn Sie aufgefordert werden, sich remote anzumelden. Es sollte passen und du bist fertig. Wenn nicht, könnte etwas anderes passieren.

Sie können alle Hosts anzeigen, mit denen Sie über SSH verbunden sind, indem Sie die Datei known_hosts anzeigen. Es befindet sich normalerweise in:

~ / .ssh / known_hosts

Sie können das in jedem Texteditor öffnen. Wenn Sie nachsehen, achten Sie darauf, wie Schlüssel gespeichert werden. Sie werden mit dem Namen (oder der Webadresse) des Host-Computers und seiner IP-Adresse gespeichert.

Ändern von Host-Schlüsseln und Problemen

Es gibt einige Gründe, warum sich Host-Schlüssel ändern oder nicht mit dem übereinstimmen, was in Ihrer known_hosts-Datei protokolliert wird.

Das System wurde neu installiert / neu konfiguriert.
Die Host-Schlüssel wurden aufgrund von Sicherheitsprotokollen manuell geändert.
Der OpenSSH-Server wurde aktualisiert und verwendet aus Sicherheitsgründen unterschiedliche Standards.
Die IP- oder DNS-Lease wurde geändert. Dies bedeutet häufig, dass Sie versuchen, auf einen anderen Computer zuzugreifen.
Das System wurde auf irgendeine Weise so manipuliert, dass sich der Host-Schlüssel geändert hat.

Am wahrscheinlichsten ist das Problem eines der ersten drei, und Sie können die Änderung ignorieren. Wenn sich die IP / DNS-Lease geändert hat, liegt möglicherweise ein Problem mit dem Server vor, und Sie werden möglicherweise an einen anderen Computer weitergeleitet. Wenn Sie nicht sicher sind, was der Grund für die Änderung ist, sollten Sie vermutlich davon ausgehen, dass es der letzte auf der Liste ist.

Wie OpenSSH unbekannte Hosts behandelt

OpenSSH hat eine Einstellung für den Umgang mit unbekannten Hosts. Diese wird in der Variablen "StrictHostKeyChecking" (ohne Anführungszeichen) wiedergegeben..

Abhängig von Ihrer Konfiguration können SSH-Verbindungen mit unbekannten Hosts (deren Schlüssel nicht bereits in der Datei known_hosts vorhanden sind) auf drei verschiedene Arten ausgeführt werden.

StrictHostKeyChecking ist auf no gesetzt. OpenSSH stellt automatisch eine Verbindung zu einem beliebigen SSH-Server her, unabhängig vom Status des Hostschlüssels. Dies ist unsicher und wird nicht empfohlen, es sei denn, Sie fügen nach einer Neuinstallation Ihres Betriebssystems eine Reihe von Hosts hinzu. Danach werden Sie es wieder ändern.
StrictHostKeyChecking ist so eingestellt, dass er fragt; OpenSSH zeigt Ihnen die neuen Host-Schlüssel und fordert Sie zur Bestätigung auf, bevor Sie sie hinzufügen. Dadurch wird verhindert, dass Verbindungen zu geänderten Host-Schlüsseln gelangen. Dies ist die Standardeinstellung.
StrictHostKeyChecking ist auf yes gesetzt. Das Gegenteil von "nein" verhindert, dass Sie eine Verbindung zu einem Host herstellen, der nicht bereits in Ihrer known_hosts-Datei vorhanden ist.

Sie können diese Variable einfach in der Befehlszeile ändern, indem Sie das folgende Paradigma verwenden:

ssh -o 'StrictHostKeyChecking [Option]' Benutzer @ Host

Ersetzen Sie [Option] durch "no", "ask" oder "yes". Beachten Sie, dass die Variable und ihre Einstellung in einfache Anführungszeichen gesetzt werden. Ersetzen Sie außerdem user @ host durch den Benutzernamen und den Hostnamen des Servers, zu dem Sie eine Verbindung herstellen. Zum Beispiel:

ssh -o 'StrictHostKeyChecking frage' [email protected]

Blockierte Hosts aufgrund geänderter Schlüssel

Wenn Sie über einen Server verfügen, auf den Sie zugreifen möchten, dessen Schlüssel bereits geändert wurde, können Sie mit der Standard-OpenSSH-Konfiguration nicht auf den Server zugreifen. Sie können den StrictHostKeyChecking-Wert für diesen Host ändern, aber das wäre nicht vollständig, paranoid sicher, oder? Stattdessen können wir den fehlerhaften Wert einfach aus unserer known_hosts-Datei entfernen.

Das ist definitiv eine hässliche Sache auf Ihrem Bildschirm. Glücklicherweise war unser Grund ein neu installiertes Betriebssystem. Lassen Sie uns die Zeile vergrößern, die wir brauchen.

Da gehen wir. Sehen Sie, wie die zu bearbeitende Datei zitiert wird? Es gibt uns sogar die Zeilennummer! Also öffnen wir diese Datei in Nano:

Hier ist unsere beleidigende Taste in Zeile 1. Alles, was wir tun müssen, ist Strg + K zu drücken, um die gesamte Zeile auszuschneiden.

Das ist viel besser! Jetzt drücken wir Strg + O, um die Datei zu schreiben (speichern), und dann Strg + X, um den Vorgang zu beenden.

Jetzt bekommen wir stattdessen eine nette Aufforderung, auf die wir einfach mit "Ja" antworten können.

Neue Host-Schlüssel erstellen

Für das Protokoll gibt es eigentlich keinen Grund, warum Sie Ihren Host-Schlüssel ändern müssen, aber wenn Sie die Notwendigkeit finden, können Sie dies problemlos tun.

Wechseln Sie zunächst in das entsprechende Systemverzeichnis:

CD / etc / ssh /

Hier befinden sich normalerweise die globalen Host-Schlüssel, obwohl einige Distributionen sie an anderer Stelle haben. Überprüfen Sie im Zweifelsfall Ihre Dokumentation!

Als nächstes löschen wir alle alten Schlüssel.

sudo rm / etc / ssh / ssh_host_ *

Alternativ können Sie sie in ein sicheres Sicherungsverzeichnis verschieben. Nur ein Gedanke!

Dann können wir den OpenSSH-Server anweisen, sich selbst neu zu konfigurieren:

sudo dpkg-reconfigure openssh-server

Sie erhalten eine Aufforderung, während Ihr Computer die neuen Schlüssel erstellt. Ta-da!

Nun, da Sie wissen, wie SSH ein bisschen besser funktioniert, sollten Sie in der Lage sein, harte Stellen zu überwinden. Die Warnung / Fehler "Remote Host Identification Has Changed" (Remote-Hostidentifizierung hat sich geändert) ist eine Sache, die viele Benutzer abschreckt, selbst diejenigen, die mit der Befehlszeile vertraut sind.