SSH-VOLLFORM: SECURE SHELL

SSH: Secure Shell

SSH steht für Secure Shell. Es wird auch als Secure Socket Shell bezeichnet. Für den sicheren Betrieb von Netzwerkdiensten in unsicheren Netzwerken wird ein kryptografisches Netzwerkprotokoll namens Secure Shell (SSH) verwendet. Die Client-Server-Architektur ist die Grundlage von SSH-Anwendungen, die eine SSH-Client-Instanz mit einem SSH-Server verbinden.

Als Nachfolger von Telnet und unsicheren Remote-Unix-Shell-Protokollen wie der Berkeley Remote Shell (rsh) und den zugehörigen Rlogin- und Rexec-Protokollen wurde SSH für Unix-ähnliche Betriebssysteme entwickelt, die unsichere Klartext-Authentifizierungstoken-Kommunikation verwenden.

Definition

Wir können SSH auf verschiedene Arten anwenden. Die einfachste Implementierung verschlüsselt Daten mithilfe automatisch generierter öffentlich-privater Schlüsselpaare an beiden Enden eines Kommunikationskanals und einer Netzwerkverbindung. Anschließend authentifiziert es den Benutzer mithilfe eines Passworts. Wenn ein Benutzer manuell ein öffentlich-privates Schlüsselpaar generiert, ist die Authentifizierung praktisch abgeschlossen, wenn das Schlüsselpaar eingerichtet ist, sodass eine Sitzung sofort ohne Passwortabfrage gestartet werden kann.

Powershell größer oder gleich

In diesem Fall hält der Eigentümer den entsprechenden privaten Schlüssel geheim und der öffentliche Schlüssel wird auf allen Maschinen installiert, die dem Eigentümer Zugriff gewähren müssen. Obwohl der private Schlüssel als Grundlage für die Authentifizierung dient, wird der Schlüssel bei der Authentifizierung niemals über das Netzwerk gesendet. SSH bestätigt, dass der Anbieter des öffentlichen Schlüssels auch über den entsprechenden privaten Schlüssel verfügt.

Die Verknüpfung des unbekannten öffentlichen Schlüssels mit einem bekannten privaten Schlüssel ist in allen SSH-Versionen von entscheidender Bedeutung, bevor diese als legitime öffentliche Schlüssel mit IDs akzeptiert werden. Wenn Sie einen öffentlichen Schlüssel von einem Angreifer akzeptieren, ohne ihn zu validieren, wird ein nicht vertrauenswürdiger Angreifer als legitimer Benutzer akzeptiert.

Schaffung

Tatu Ylönen, ein Informatiker aus Finnland, entwickelte SSH erstmals im Jahr 1995. Die Weiterentwicklung der Protokollsuite erfolgte in vielen Entwicklergruppen, was zu verschiedenen Implementierungsiterationen führte. Es stehen Implementierungen für alle gängigen Betriebssysteme zur Verfügung, auch für eingebettete Systeme. OpenSSH, das die Erfinder von OpenBSD 1999 als Open-Source-Software zur Verfügung stellten, ist der am häufigsten verwendete Software-Stack.

Verwaltung von OpenSSH-Schlüsseln zur Authentifizierung

Die Liste der genehmigten öffentlichen Schlüssel wird auf Unix-ähnlichen Systemen üblicherweise in der Datei ~/.ssh/authorized Keys im Home-Verzeichnis des Benutzers gespeichert, der über Remote-Anmelderechte verfügt. SSH respektiert diese Datei nur, wenn sie von niemand anderem als dem Eigentümer und Root geändert werden kann. Das Passwort ist nicht mehr erforderlich, wenn sowohl der öffentliche Schlüssel des entfernten Endes als auch der passende private Schlüssel des lokalen Endes vorhanden sind. Für noch mehr Schutz können wir jedoch eine Passphrase verwenden, um den privaten Schlüssel zu sperren. Wir können den Geheimcode auch an gängigen Orten suchen und eine Befehlszeilenoption verwenden, um seinen vollständigen Pfad anzugeben (Option -i für ssh).

SSH bietet außerdem eine automatisierte, schlüsselgenerierte, passwortbasierte Authentifizierung. Der Angreifer gibt sich in diesem Szenario möglicherweise als vertrauenswürdiger Server aus, fordert das Passwort an und erlangt es (Man-in-the-Middle-Angriff). Auf der Serverseite können wir die Passwortauthentifizierung deaktivieren.

Verwenden

SSH verwendet das Client-Server-Paradigma. Normalerweise wird SSH für die Protokollierung verwendet. Es kann auch TCP-Ports tunneln, X11-Verbindungen weiterleiten und Befehle auf einem Remote-System ausführen. Normalerweise werden Verbindungen zu einem SSH-Daemon, der Remoteverbindungen ermöglicht, über eine SSH-Clientanwendung hergestellt. Beide sind häufig auf den meisten modernen Betriebssystemen zu finden, wie zum Beispiel macOS, Linux-Distributionen, OpenBSD, FreeBSD, NetBSD, Solaris und OpenVMS. Einige Versionen sind proprietär, Freeware und Open Source mit unterschiedlichem Grad an Komplexität und Umfang (z. B. PuTTY und die in Cygwin und OpenSSH enthaltene Version von OpenSSH). Insbesondere ist SSH in Windows-Versionen erst ab Windows 10 Version 1709 standardmäßig enthalten.

Ähnliche Funktionen zur Dateiverwaltung (Synchronisierung, Kopieren und Remote-Löschen) bietet die kostenlose Open-Source-Windows-Anwendung WinSCP, die PuTTY als Backend verwendet. WinSCP und PuTTY müssen nicht auf dem Client-Computer installiert werden und sind für den direkten Betrieb über ein USB-Laufwerk verfügbar. Um einen SSH-Server in Windows einzurichten, ist häufig die Aktivierung einer Funktion in der Einstellungs-App erforderlich.

Um Verbindungsprobleme zu bewältigen und die Sicherheitsrisiken zu verhindern, die mit der direkten Offenlegung einer cloudbasierten virtuellen Maschine im Internet verbunden sind, ist SSH beim Cloud Computing von entscheidender Bedeutung. Eine sichere Verbindung über das Internet kann durch einen SSH-Tunnel eines virtuellen Computers über eine Firewall ermöglicht werden. Für dieses Protokoll hat die IANA den TCP-Port 22, den UDP-Port 22 und den SCTP-Port 22 festgelegt.

Bereits 2001 stufte die IANA den Standard-TCP-Port 22 für SSH-Server als einen der bekannten Ports ein. Das verbindungsorientierte Transportschichtprotokoll SCTP kann zum Ausführen von SSH anstelle von TCP verwendet werden.

Historischer Fortschritt

Iteration 1

Ein Passwort-Sniffing-Angriff auf das Netzwerk seiner Institution inspirierte Tatu Ylönen, einen Forscher an der Technischen Universität Helsinki in Finnland, im Jahr 1995 zur ersten Iteration des Protokolls (heute bekannt als SSH-1).

SSH wurde entwickelt, um die Rolle früherer Protokolle zu übernehmen, darunter rlogin, TELNET, FTP und rsh, denen es an robusten Authentifizierungs- und Geheimhaltungsgarantien mangelte. Ylönen stellte seine Anwendung als Freeware zur Verfügung. Im Juli 1995 erfreute sich das Gerät rasch großer Beliebtheit. Ende 1995 gab es 20.000 SSH-Benutzer in 50 verschiedenen Ländern.

Um SSH zu fördern und voranzutreiben, gründete Ylönen im Dezember 1995 SSH Communications Security. In der ersten Version des SSH-Programms wurden verschiedene freie Softwarekomponenten, darunter GNU libgmp, verwendet, doch spätere Iterationen von SSH Communications Security entwickelten sich zu zunehmend proprietärer Software. Schätzungen zufolge gab es im Jahr 2000 2 Millionen Nutzer.

Iteration 2

Die Internet Engineering Task Force (IETF) hat in ihrer offiziellen Dokumentation die Arbeitsgruppe, die für die Erstellung des SSH-Protokolls Version 2 verantwortlich ist, als „Secsh“ bezeichnet.

SSH-2, eine verbesserte Protokolliteration, wurde 2006 zum Standard. SSH-1 ist mit dieser Version nicht kompatibel. SSH-2 bietet Funktions- und Sicherheitsupgrades gegenüber SSH-1. Beispielsweise sorgen der Diffie-Hellman-Schlüsselaustausch und eine robuste Integritätsüberprüfung über Nachrichtenauthentifizierungscodes für höhere Sicherheit. Die Möglichkeit, eine unbegrenzte Anzahl von Shell-Sitzungen über eine einzige SSH-Verbindung zu betreiben, ist eine der neuen Fähigkeiten von SSH-2. Da SSH-2 fortschrittlicher und weiter verbreitet ist als SSH-1, unterstützen bestimmte Implementierungen, wie z. B. libssh (v0.8.0+), Lsh und Dropbear, nur SSH-2.

Iteration 1,99

RFC 4253 verlangte, dass ein SSH-Server, der 2.0 und frühere Versionen unterstützt, im Januar 2006, also lange nach der Entwicklung von Version 2.1, seine Protokollversion als 1.99 angeben sollte. Diese Versionsnummer dient zur Angabe der Abwärtskompatibilität und nicht zur Darstellung einer früheren Softwarerevision.

OSSH und OpenSSH

Seit die letzte Version des ursprünglichen SSH-Programms, Version 1.2.12, 1999 unter einer Open-Source-Lizenz vertrieben wurde, arbeiten Entwickler an einer kostenlosen Softwareversion. Dies diente als Grundlage für Björn Grönvalls OSSH-Programm. Bald darauf klonte das OpenBSD-Team Grönvalls Arbeit, um OpenSSH zu produzieren, das in OpenBSD Release 2.6 enthalten war. Sie haben aus dieser Version einen „Portabilitätszweig“ erstellt, um OpenSSH auf verschiedene Betriebssysteme zu übertragen.

Die im Jahr 2005 am weitesten verbreitete SSH-Implementierung war OpenSSH, die Standardversion in vielen Betriebssystemdistributionen. Nachdem die SSH-1-Unterstützung aus der Codebasis in der OpenSSH-Version 7.6 entfernt wurde, wird OpenSSH weiterhin aktualisiert und unterstützt das SSH-2-Protokoll. Mittlerweile ist OSSH nicht mehr relevant.

Zeichen in eine Zeichenfolge umwandeln

Verwendet

Der Benutzer „josh“ hat eine SSH-Verbindung vom lokalen Computer „foo fighter“ zum entfernten Computer „tengwar“ hergestellt, um xeyes als Beispiel für das Tunneln eines X11-Programms über SSH auszuführen. Menschen nutzen den Windows-SSH-Client PuTTY, um auf OpenWrt zuzugreifen.

SSH ist ein Protokoll, das mit vielen Systemen funktioniert, einschließlich Microsoft Windows und den meisten Unix-Varianten (Linux, BSDs, einschließlich Apples macOS und Solaris). Die folgenden Apps benötigen möglicherweise Funktionen, die exklusiv für bestimmte SSH-Clients oder -Server gelten oder mit diesen kompatibel sind. Beispielsweise ist es derzeit nur möglich, die OpenSSH-Server- und Client-Implementierung des SSH-Protokolls zum Aufbau eines VPN zu verwenden.

Java-Concat-String

So greifen Sie auf eine Shell auf einem entfernten Host zu (ersetzt Telnet und rlogin)
Zum Ausführen eines einzelnen Befehls auf einem entfernten Host (ersetzt rsh)
Zum Konfigurieren der automatischen (passwortlosen) Anmeldung eines entfernten Servers (z. B. mit OpenSSH)
Da es sich um ein voll funktionsfähiges verschlüsseltes VPN handelt, sollten Sie bedenken, dass nur der OpenSSH-Client und -Server diese Funktion unterstützen.
Zur Übertragung von X von einem entfernten Host (über mehrere Zwischenhosts möglich)
Zur Verwendung von SSH-Clients, die das SOCKS-Protokoll unterstützen, um über eine verschlüsselte Proxy-Verbindung im Internet zu surfen.
Zum sicheren Mounten des Verzeichnisses eines Remote-Servers als Dateisystem auf einem lokalen Computer mithilfe von SSHFS.
Durch eine oder mehrere der oben genannten Technologien zur automatischen Fernüberwachung und -verwaltung von Servern.
Für die Entwicklung von SSH-kompatiblen mobilen oder eingebetteten Geräten.
Zum Schutz von Dateiübertragungsmechanismen.

Übertragungsmethoden für Dateien

Mehrere Dateiübertragungssysteme verwenden Secure Shell-Protokolle wie z

Über SSH wird Secure Copy (SCP) aus dem RCP-Protokoll entwickelt.
rsync, das angeblich effektiver als SCP ist, wird oft über eine SSH-Verbindung betrieben.
Eine sichere Alternative zu FTP ist das SSH File Transfer Protocol (SFTP) (nicht zu verwechseln mit FTP über SSH oder FTPS).
FISH oder Dateien, die über das Shell-Protokoll übertragen werden, wurde 1998 eingeführt und aus SSH-über-Unix-Shell-Anweisungen entwickelt.
Aspera, auch bekannt als Fast and Secure Protocol (FASP), verwendet SSH für Befehle und UDP-Ports für den Datentransport.

Die Architektur

Drei unterschiedliche Komponenten bilden die Schichtarchitektur des SSH-Protokolls:

Das Transmission Control Protocol (TCP) von TCP/IP wird üblicherweise von der Transportschicht (RFC 4253) verwendet, wobei Port Nummer 22 als Server-Abhörport reserviert ist. Diese Schicht implementiert Verschlüsselung, Komprimierung, Integritätsprüfung, anfänglichen Schlüsselaustausch und Serverauthentifizierung. Obwohl jede Implementierung möglicherweise mehr ermöglicht, stellt sie der höheren Schicht eine Schnittstelle zum Senden und Empfangen von Klartextpaketen mit jeweils bis zu 32.768 Bytes zur Verfügung. Normalerweise veranlasst die Transportschicht den erneuten Schlüsselaustausch, nachdem 1 GB Daten transportiert wurden oder nachdem eine Stunde vergangen ist, je nachdem, was zuerst eintritt.
Die Client-Authentifizierung erfolgt über die Benutzerauthentifizierungsschicht (RFC 4252), die auch mehrere Authentifizierungstechniken bietet. Clientgesteuerte Authentifizierung bedeutet, dass der SSH-Client und nicht der Server den Benutzer nach einem Passwort fragen darf. Nur die Authentifizierungsanfragen des Clients erhalten eine Antwort vom Server. Die folgenden Techniken zur Benutzerauthentifizierung werden häufig verwendet:
Unterstützt normalerweise mindestens DSA-, ECDSA- oder RSA-Schlüsselpaare Öffentlicher Schlüssel ist eine Technik zur Authentifizierung auf Basis öffentlicher Schlüssel. Andere Implementierungen akzeptieren zusätzlich X.509-Zertifikate.
Die Single-Sign-On-Funktionalität für SSH-Sitzungen wird über bereitgestellt GSSAPI Authentifizierungstechniken, die ein erweiterbares System zur Handhabung der SSH-Authentifizierung mithilfe externer Mechanismen wie Kerberos 5 oder NTLM bieten. Obwohl OpenSSH über eine funktionsfähige GSSAPI-Implementierung verfügt, integrieren kommerzielle SSH-Implementierungen diese Techniken häufig für den Einsatz in Unternehmen.
Die Idee der Kanäle, die die angebotenen SSH-Dienste definieren, wird durch die Verbindungsschicht (RFC 4254) definiert. Wir können mehrere SSH-Verbindungen von einer einzigen aus multiplexen. Beide übertragen Daten in beide Richtungen. Kanalanforderungen übertragen Out-of-Band-Daten, die für einen bestimmten Kanal spezifisch sind, z. B. den Exit-Code eines serverseitigen Prozesses oder die Größenänderung eines Terminalfensters. Darüber hinaus steuert jeder Kanal seinen Fluss mithilfe der Empfangsfenstergröße. Der SSH-Client stellt eine globale Anfrage zur Weiterleitung eines serverseitigen Ports. Zu den häufigsten Kanaltypen gehören:
- Shell für SFTP-, Exec- und Terminal-Shells (einschließlich SCP-Übertragungen)
- Direct-TCPIP für weitergeleitete Verbindungen vom Client zum Server.
- Vom Server zum Client weitergeleitete Verbindungen mithilfe von „forwarded-tcpip“.
- Um die Legitimität des Hosts zu bestätigen, bietet der SSHFP-DNS-Eintrag (RFC 4255) die Fingerabdrücke des öffentlichen Hostschlüssels.

Aufgrund seines offenen Designs können wir SSH neben der Sicherung von Granaten auch für eine Vielzahl anderer Aufgaben nutzen, was ihm eine große Vielseitigkeit verleiht.

Schwachstellen

SSH-1

Aufgrund des unzureichenden Schutzes der Datenintegrität durch CRC-32 in dieser Protokollversion wurde 1998 eine Schwachstelle in SSH 1.5 entdeckt, die das unbefugte Einfügen von Material in einen verschlüsselten SSH-Stream ermöglichte. In den meisten Implementierungen wurde ein Patch namens SSH Compensation Attack Detector hinzugefügt. Mehrere dieser überarbeiteten Implementierungen enthielten einen neuen Integer-Overflow-Fehler, der es Angreifern ermöglichte, beliebigen Code mit Root- oder den SSH-Daemon-Funktionen auszuführen.

Im Januar 2001 wurde eine Schwachstelle gefunden, die es Angreifern ermöglicht, den letzten Block einer IDEA-verschlüsselten Sitzung zu ändern. Im selben Monat wurde eine weitere Schwachstelle entdeckt, die es einem betrügerischen Server ermöglichte, ein Client-Login an einen anderen Server weiterzuleiten.

Aufgrund seiner inhärenten Schwachstellen gilt SSH-1 allgemein als veraltet und sollte durch die explizite Entfernung des SSH-1-Fallbacks vermieden werden. Die meisten aktuellen Server und Clients unterstützen SSH-2.

Klartextwiederherstellung für CBC

Im November 2008 wurde in allen SSH-Versionen eine theoretische Schwachstelle entdeckt, die den Abruf von bis zu 32 Bit Klartext aus einem Chiffretextblock ermöglichte, der mit der damaligen Standardverschlüsselungsmethode CBC verschlüsselt wurde. Die einfachste Lösung ist die Umstellung auf CTR, Counter Modus anstelle des CBC-Modus, der SSH immun gegen den Angriff macht.

NSA unter Verdacht der Entschlüsselung

Die Veröffentlichung sensibler Dokumente durch Edward Snowden an den Spiegel am 28. Dezember 2014 deutet darauf hin, dass die National Security Agency möglicherweise in der Lage sein wird, bestimmte SSH-Kommunikationen zu entschlüsseln.

TechCodeview

Was ist die Vollform von SSH?