Table of Contents
Die Notwendigkeit eines verschlüsselten Shell-Clients
Im Kontext von Client/Server-Computing erfolgt die Datenübertragung zwischen dem Host und einem Terminal
durch die Nutzung eines allgemeinen Terminals oder eines
Terminal-Emulators. In diesem Szenario
ist es unerlässlich, dass das Terminal oder der Personal Computer, auf dem ein
Terminal-Emulator ausgeführt wird, angemessen mit dem
Server oder Großrechner verbunden ist.
Es gibt verschiedene Methoden, um die Verbindung zwischen dem Terminal und dem Server herzustellen;
historisch gesehen war der vorherrschende Ansatz für die vernetzte Terminal-zu-Server-Verbindung die
Verwendung von Telnet.
Nichtsdestotrotz stuft die zeitgenössische Sicherheitslandschaft die unverschlüsselte Übertragung über
Telnet als erhebliches Sicherheitsrisiko ein.
Aufgrund der ständig wachsenden Nachfrage nach Sicherheit wurde das Secure Shell (SSH)-Protokoll entwickelt.
SSH verwendet fortschrittliche Verschlüsselungstechnologie, um jede einzelne Kommunikation zwischen dem Client und dem
Server zu verschlüsseln. Sollte ein unbefugter Dritter in der Lage sein, den Datenverkehr irgendwo
entlang des Kommunikationswegs abzufangen, sieht er nichts als völlig nutzlose Daten.
Technische Grundlagen von SSH
Die Grundlagen des Secure Shell (SSH)-Protokolls sind in RFC 4253 festgelegt.
Das Dokument beschreibt SSH als ein sicheres Transportprotokoll, das von einem Server auf
TCP-Port 22 bereitgestellt wird und starke Verschlüsselung,
kryptografische Hostauthentifizierung und Integritätsschutz bietet.
Oder, wie es in der Einleitung von RFC 4253 heißt:
Secure Shell (SSH) ist ein Protokoll [das eine Software verwenden kann für]
sichere Remote-Anmeldung und andere sichere Netzwerkdienste über
ein unsicheres Netzwerk.
Dieses Dokument beschreibt das SSH-Transportprotokoll, das
typischerweise auf TCP/IP aufsetzt. [...].
Schlüsselaustauschmethode, Public-Key-Algorithmus, symmetrischer Verschlüsselungsalgorithmus,
Nachrichtenauthentifizierungsalgorithmus und Hash-Algorithmus werden verhandelt.
Dieses Dokument beschreibt auch die Diffie-Hellman-Schlüsselaustauschmethode
und den minimalen Satz von Algorithmen, die benötigt werden, um das
SSH-Transportprotokoll umzusetzen.
Diese RFC definiert Möglichkeiten zur Erstellung eines Verschlüsselungsschlüssels (der später dazu dient, den
Datenverkehr zwischen Client und Server zu verschlüsseln) in möglicherweise
vorhandener Zuhörerpräsenz. Er definiert auch Host- und Benutzerauthentifizierungsmethoden
(d.h. Methoden, mit denen Benutzer und Server nachweisen können, dass sie sind, wer sie vorgeben zu sein),
und mögliche Datenkompressionen zur effektiveren Übertragung von Daten.
Ein besonders anspruchsvoller Teil bei der Verschlüsselung einer solchen Kommunikation ist die Notwendigkeit,
einen gemeinsamen geheimen Schlüssel (einen Verschlüsselungsschlüssel) über einen Kanal zu verhandeln, der bereits
überwacht werden kann. SSH beantwortet diese Herausforderung durch die initiale Schlüsselaustauschphase
der Verbindung unter Verwendung der älteren Diffie-Hellman-Kex-Methode. Neuere Versionen
unterstützen jetzt auch ED25519 elliptische Kurve Kex. Es handelt sich um eine spezielle Implementierung
des Edwards-Kurve Digital Signature Algorithm (EdDSA), der selbst eine Variante
des Schnorr-Signatursystems mit verdrehten Edwards-Kurven ist (mathematische Details
finden Sie
im kommenden IETF-Standard für ED25519).
Symmetrische Verschlüsselung
Die symmetrische Verschlüsselung ist eine Art von Verschlüsselung, bei der ein Schlüssel zum Verschlüssel
von Nachrichten an die andere Partei verwendet werden kann und auch zum Entschlüsseln der von der anderen
Partei empfangenen Nachrichten verwendet werden kann. Was die Verschlüsselung symmetrisch macht,
ist die Tatsache, dass derselbe Schlüssel für die Verschlüsselung und Entschlüsselung verwendet wird.
Die symmetrische Verschlüsselung erfordert in der Regel wenig Rechenleistung und wird daher verwendet,
um größere Datenblöcke zu verschlüsseln. Bei SSH wird es verwendet, um den gesamten Datenstrom zu verschlüsseln.
Asymmetrische (Public/Private Key) Verschlüsselung
Die asymmetrische Verschlüsselung unterscheidet sich von der symmetrischen Verschlüsselung durch die Verwendung von
zwei verschiedenen Schlüsseln.
Ein (beliebiger) dieser beiden Schlüssel wird zum Verschlüsseln der Daten verwendet, der andere dafür verwendet,
um sie zu entschlüsseln. Der Vorteil dieser Technik besteht darin, dass eine Partei einer anderen
Partei einen Schlüssel geben kann, um Nachrichten an Sie zu verschlüsseln, aber jeder, der diesen Schlüssel kennt,
wird die Nachricht trotzdem nicht entschlüsseln können. Ein solcher Schlüssel wird als der öffentliche Schlüssel bezeichnet.
Der andere Schlüssel, der nicht geteilt wird und der dann verwendet wird, um den Datenblock zu entschlüsseln, wird als der
private Schlüssel bezeichnet.
Dies funktioniert auch in die andere Richtung. Daten, die mit dem privaten Schlüssel verschlüsselt wurden, können nur
mit dem öffentlichen Schlüssel entschlüsselt werden. Mit SSH kann diese Tatsache genutzt werden, um die Identität zu beweisen. Wenn eine
Nachricht mit dem öffentlichen Schlüssel entschlüsselt werden kann, beweist dies, dass die Person, die die Nachricht verschlüsselt hat,
im Besitz des privaten Schlüssels ist.
Öffentlich/private Schlüsselpaare werden mit dem
ssh-keygen-Werkzeug oder
ZOCs integriertem Schlüsselgenerator generiert.
Schlüsselaustausch
Ein besonders herausfordernder Teil der Verschlüsselung solcher Kommunikation besteht darin, einen gemeinsamen
Geheimschlüssel (einen Verschlüsselungsschlüssel) zwischen dem SSH-Client und -Server zu verhandeln,
während die Verhandlung zunächst auf einem Kanal durchgeführt werden muss, der bereits von einer
dritten Partei überwacht werden könnte.
Denken Sie an das Problem folgendermaßen: Sie müssen sich mit jemand anderem auf ein
Passwort einigen, können jedoch nur über eine Telefonleitung darüber sprechen, von der Sie wissen, dass sie
vom Feind abgehört wird.
SSH beantwortet diese Herausforderung durch die anfängliche Schlüsselaustauschphase
der Verbindung unter Verwendung der älteren Diffie-Hellman-Kex-Methode. Neuere Versionen
unterstützen nun auch den ED25519 elliptischen Kurven-Kex. Dies ist eine spezifische Implementierung
des Edwards-Kurven-Digital-Signature-Algorithmus (EdDSA), der selbst eine Variante
des Schnorr-Signatursystems mit verdrehten Edwards-Kurven ist (mathematische Details
können in
dem bevorstehenden IETF-Standard für ED25519 gefunden werden).
Statische Portweiterleitung
Statische Portweiterleitung
(oder Tunneling) bezieht sich auf Situationen, in denen Ziel-Host und Port im Voraus bekannt sind.
Programme und Protokolle, die keine Datenverschlüsselung verwenden (z. B. FTP oder RSH), können
sich mit dem Port des Tunnels auf dem lokalen Computer verbinden, und der SSH-Client überträgt
ihre Daten über die verschlüsselte SSH-Verbindung zu/von einem Endziel, das bereits bekannt ist,
wenn die SSH-Verbindung hergestellt wird.
Beispielsweise kann ein Benutzer eine Portweiterleitung in der Client-Software einrichten, die auf den
Client-Port 5514 hört und den Datenverkehr an die Adresse eines älteren Geräts mit einer festen IP-Adresse weiterleitet,
das im Remote-Netzwerk nur das unverschlüsselte RSH-Protokoll unterstützt.
Dynamische Portweiterleitung
Wie oben beschrieben, erfordert die statische Portweiterleitung, dass der Client vor der Verbindung
den Quellport und das Ziel festlegt.
Dieses Problem wird durch die dynamische Portweiterleitung von Secure Shell angegangen. Bei dynamischer Portweiterleitung
richtet der Client einen Empfangsport ein (wie bei normaler Portweiterleitung), an dem eine Software, die eine Verbindung herstellt,
dem Client mitteilen kann, zu welchem Host und Port sie eine Verbindung herstellen möchte. Dies geschieht
auf die gleiche Weise, wie Clientsoftware Verbindungsanfragen von einem SOCK5-Proxy anfordern kann.
Der SSH-Client leitet dann die Verbindungsanfrage an den Secure Shell-Server weiter, der die Verbindung zum Zielhost herstellt.
Auf diese Weise könnte der SSH-Client einer unverschlüsselten RSH-Software den Zugriff auf beliebige RSH-Server im Remote-Netzwerk ermöglichen
über den verschlüsselten Datenkanal.
Weitere SSH-Client-Funktionen und Anforderungen
Mit anderen Worten gibt es viele Vorteile bei der Verwendung von SSH für Verbindungen. Neben der
Verschlüsselung des Datenverkehrs und dem sicheren Schlüsselaustausch bietet das Secure Shell-Protokoll
auch die Bestätigung, dass Sie mit dem richtigen Computer verbunden sind.
Das mag überraschend erscheinen, ergibt aber durchaus Sinn. Bedenken Sie,
dass wenn jemand in der Lage wäre, einen Teil des Kommunikationspfads zu kontrollieren,
den Verkehr tatsächlich zu einem anderen Computer umleiten könnte.
Dieser könnte dann die Rolle des Computers spielen, den Sie eigentlich
verbinden wollten (das wird als Man-in-the-Middle-Angriff bezeichnet) und könnte entweder
gefälschte Daten anzeigen oder Informationen vom Client-Computer abrufen. Ein Merkmal
namens known_hosts kann dies verhindern.
Das SSH-Terminal sollte auch verschiedene Authentifizierungsmethoden unterstützen. Dazu gehören
Benutzername/Passwort, Public/Private Key und verschiedene benutzerdefinierte Formate. Die
letzteren könnten ein System umfassen, bei dem der Server Informationen erhalten könnte, die nur
den autorisierten Benutzern bekannt sind, z.B. durch Verwendung einer SecurID-Karte oder durch
Senden eines Zugangscodes auf das Mobiltelefon des Benutzers.
Um sich mit verschiedenen Servern verbinden zu können, muss der SSH-Client die neuesten
Schlüsselaustausch- und Verschlüsselungsprotokolle unterstützen, denn was vor fünf Jahren als unknackbar galt,
wird heute als wenig sicher betrachtet. Die meisten Server wechseln ständig zu fortschrittlicheren Verschlüsselungsmethoden,
und SSH-Clients müssen diese ebenfalls unterstützen.
Andere typische Must-Have-Funktionen sind:
- ECDSA, ED25519, RSA und DSA Public Key-Authentifizierung
- Portweiterleitung (Tunnelung von Verbindungen vom Client zum Server über den SSH-Kanal)
- Dynamische Portweiterleitung (ähnlich wie SOCKS)
- Verbindung über Proxy
- SFTP- und SCP-Dateiübertragung
- X11-Weiterleitung (ermöglicht das Ausführen von X-Windows-Programmen auf dem Remote-Server)
- PKCS#11-Authentifizierung (ermöglicht die Authentifizierung über Hardware, z.B. Smartcards)
- UTF8-Unterstützung in der Terminal-Emulation
SSH-Verbindung über Proxy
In einigen Umgebungen dürfen Endbenutzercomputer nicht direkt auf das Internet zugreifen.
In solchen Fällen erfolgt die Verbindung und der Datenaustausch über einen
SSH-Proxy, der die eigentliche
Verbindung zum externen Netzwerk (Internet) herstellt.
X11-Weiterleitung
X11 ist ein Kommunikationsprotokoll, das einem Remote-Computer ermöglicht, Programme mit grafischer
Benutzeroberfläche auf einem Remote-Computer auszuführen. SSH unterstützt eine Möglichkeit, diese Art der Kommunikation
zwischen dem SSH-Client zu tunneln und ermöglicht es dem Benutzer, X11-Software auf dem Server auszuführen und die Ausgabe
auf seinem Computer zu sehen.
ZOC Terminal: Ein moderner SSH-Client für Windows und macOS
Das Secure Shell-Protokoll deckt die eigentliche Übertragung von Daten zwischen
Client und Server ab. Aber der Secure Shell-Client
ist in der Regel ein Terminal-Emulator,
also eine Software, die einem Remote-Computer ermöglicht, Tastatureingaben
zu erhalten und formatierten Text (Farbe, Cursorpositionierung usw.)
an den Computer des Benutzers zu senden.
Daher muss der Client neben der sicheren Verbindung und der verschlüsselten Übertragung von Rohdaten
auch die Funktionen eines Terminal-Emulators ausführen können (unterschiedliche Terminal-Emulationen unterstützen),
aber auch zusätzliche Funktionen wie Drucken, Protokollierung, Skriptautomatisierung und vieles mehr.
Zusammen mit SSH-Funktionen wie neuester Verschlüsselung und Public-Key-Authentifizierung, Portweiterleitung, Tunneling, Smartcard-Authentifizierung usw.
macht dies ZOC zum idealen SSH-Client.
