Secure Shell

Das Secure Shell Protocol ( SSH-Protokoll ) ist ein kryptografisches Netzwerkprotokoll , das die sichere Ausführung von Netzwerkdiensten über ein ungesichertes Netzwerk ermöglicht . ^{[ 1 ]} Seine bekanntesten Anwendungen sind die Fernanmeldung und die Ausführung von Befehlszeilenprogrammen .

SSH wurde für Unix-ähnliche Betriebssysteme als Ersatz für Telnet und ungesicherte Unix-Shell- Remote - Protokolle wie die Berkeley Remote Shell (rsh) und die verwandten Protokolle rlogin und rexec entwickelt , die alle unsichere Klartext- Authentifizierungsmethoden wie Passwörter verwenden .

Da Mechanismen wie Telnet und Remote Shell für den Zugriff auf und die Bedienung entfernter Computer konzipiert sind, birgt die ungesicherte Übertragung der Authentifizierungsdaten (z. B. Benutzername und Passwort ) über ein öffentliches Netzwerk ein hohes Risiko, dass Dritte das Passwort erlangen und denselben Zugriff auf das entfernte System wie der Telnet-Nutzer erhalten. Secure Shell mindert dieses Risiko durch Verschlüsselungsmechanismen , die den Inhalt der Übertragung vor einem Beobachter verbergen sollen, selbst wenn dieser Zugriff auf den gesamten Datenstrom hat . ^{[ 2 ]}

Der finnische Informatiker Tatu Ylönen entwarf SSH im Jahr 1995 und stellte eine Implementierung in Form der beiden Befehle `ssh` und `slogin` als sichere Alternativen zu `rsh` bzw. `rlogin` bereit . Die Weiterentwicklung des Protokolls erfolgte in mehreren Entwicklergruppen, wodurch verschiedene Implementierungsvarianten entstanden. Die Protokollspezifikation unterscheidet zwei Hauptversionen, SSH-1 und SSH-2. Der am weitesten verbreitete Software-Stack ist OpenSSH , das 1999 von den OpenBSD -Entwicklern als Open-Source-Software veröffentlicht wurde. Implementierungen sind für alle gängigen Betriebssysteme, einschließlich eingebetteter Systeme , verfügbar .

SSH-Anwendungen basieren auf einer Client-Server-Architektur , die eine SSH-Client- Instanz mit einem SSH-Server verbindet . ^{[ 3 ]} SSH arbeitet als geschichtetes Protokollsystem mit drei hierarchischen Hauptkomponenten: Die Transportschicht gewährleistet Serverauthentifizierung, Vertraulichkeit und Integrität; das Benutzerauthentifizierungsprotokoll authentifiziert den Benutzer gegenüber dem Server; und das Verbindungsprotokoll multiplexiert den verschlüsselten Tunnel in mehrere logische Kommunikationskanäle. ^{[ 1 ]}

SSH verwendet Public-Key-Kryptographie , um den Remote-Computer zu authentifizieren und ihm gegebenenfalls die Authentifizierung des Benutzers zu ermöglichen. ^{[ 3 ]}

SSH kann auf verschiedene Arten verwendet werden. In der einfachsten Variante verwenden beide Enden eines Kommunikationskanals automatisch generierte öffentliche und private Schlüsselpaare, um eine Netzwerkverbindung zu verschlüsseln, und anschließend ein Passwort zur Authentifizierung des Benutzers.

Wird das öffentliche/private Schlüsselpaar manuell vom Benutzer generiert, erfolgt die Authentifizierung im Wesentlichen bei der Erstellung des Schlüsselpaares. Anschließend kann eine Sitzung automatisch ohne Passwortabfrage geöffnet werden. In diesem Fall wird der öffentliche Schlüssel auf allen Computern gespeichert, die dem Besitzer des zugehörigen privaten Schlüssels Zugriff gewähren sollen. Der Besitzer hält den privaten Schlüssel geheim. Obwohl die Authentifizierung auf dem privaten Schlüssel basiert, wird dieser während der Authentifizierung niemals über das Netzwerk übertragen. SSH überprüft lediglich, ob die Person, die den öffentlichen Schlüssel anbietet, auch den zugehörigen privaten Schlüssel besitzt.

In allen SSH-Versionen ist es wichtig, unbekannte öffentliche Schlüssel zu überprüfen , d. h. sie mit Identitäten zu verknüpfen , bevor man sie als gültig akzeptiert. Die Akzeptanz eines öffentlichen Schlüssels eines Angreifers ohne vorherige Überprüfung autorisiert diesen als gültigen Benutzer.

Auf Unix-ähnlichen Systemen wird die Liste der autorisierten öffentlichen Schlüssel üblicherweise im Home-Verzeichnis des Benutzers, der sich remote anmelden darf, in der Datei `.ssh` gespeichert ~/.ssh/authorized_keys. ^{[ 4 ]} Diese Datei wird von SSH nur dann berücksichtigt, wenn sie nur vom Eigentümer und dem Benutzer root beschreibbar ist. Befindet sich der öffentliche Schlüssel auf dem Remote-Server und der zugehörige private Schlüssel auf dem lokalen Server, ist die Eingabe des Passworts nicht mehr erforderlich. Zur zusätzlichen Sicherheit kann der private Schlüssel jedoch mit einer Passphrase geschützt werden.

Der private Schlüssel kann auch an üblichen Stellen gesucht werden, und sein vollständiger Pfad kann als Befehlszeilenoption angegeben werden (die Option -ifür ssh). Das Dienstprogramm ssh-keygen erzeugt den öffentlichen und den privaten Schlüssel, immer paarweise.

SSH wird typischerweise verwendet, um sich in die Shell oder Befehlszeilenschnittstelle (CLI) eines entfernten Computers einzuloggen und Befehle auf einem entfernten Server auszuführen. Es unterstützt außerdem Mechanismen für Tunneling , Weiterleitung von TCP-Ports und X11 -Verbindungen und kann zum Übertragen von Dateien mithilfe des zugehörigen SSH File Transfer Protocol (SFTP) oder Secure Copy Protocol (SCP) verwendet werden . ^{[ 3 ]}

SSH verwendet das Client-Server-Modell . Ein SSH- Clientprogramm wird typischerweise verwendet, um Verbindungen zu einem SSH- Daemon wie sshd herzustellen und Remote-Verbindungen anzunehmen. Beide sind auf den meisten modernen Betriebssystemen standardmäßig vorhanden , darunter macOS , die meisten Linux- Distributionen , OpenBSD , FreeBSD , NetBSD , Solaris und OpenVMS . Windows- Versionen vor Windows 10 Version 1709 enthielten SSH nicht standardmäßig, es gab und gibt jedoch proprietäre , Freeware- und Open-Source- Versionen mit unterschiedlichem Funktionsumfang (siehe Vergleich von SSH-Clients ). 2018 begann Microsoft mit der Portierung des OpenSSH- Quellcodes auf Windows ^{[ 5 ]} , und in Windows 10 Version 1709 ist nun eine offizielle Win32-Portierung von OpenSSH verfügbar.

Dateimanager für UNIX-ähnliche Systeme (z. B. Konqueror ) können das FISH- Protokoll nutzen, um eine grafische Benutzeroberfläche mit Drag-and-Drop-Funktion und geteilten Fenstern bereitzustellen. Das Open-Source-Windows-Programm WinSCP ^{[ 6 ]} bietet ähnliche Dateiverwaltungsfunktionen (Synchronisierung, Kopieren, Remote-Löschen) mithilfe von PuTTY als Backend. Sowohl WinSCP ^{[ 7 ]} als auch PuTTY ^{[ 8 ]} sind als Pakete verfügbar, die direkt von einem USB-Stick ausgeführt werden können und keine Installation auf dem Client-Rechner erfordern. Crostini unter ChromeOS enthält standardmäßig OpenSSH. Die Einrichtung eines SSH-Servers unter Windows erfordert üblicherweise die Aktivierung einer Funktion in den Einstellungen.

SSH ist im Cloud Computing wichtig , um Verbindungsprobleme zu lösen und die Sicherheitsrisiken zu vermeiden, die mit der direkten Bereitstellung einer Cloud-basierten virtuellen Maschine im Internet verbunden sind. Ein SSH-Tunnel kann einen sicheren Pfad über das Internet, durch eine Firewall hindurch, zu einer virtuellen Maschine bereitstellen. ^{[ 9 ]}

Die IANA hat für dieses Protokoll die Ports TCP 22, UDP 22 und SCTP 22 zugewiesen . ^{[ 10 ]} Bereits 2001 listete die IANA den Standard-TCP-Port 22 für SSH-Server als einen der bekannten Ports auf. ^{[ 11 ]} SSH kann alternativ auch mit SCTP anstelle von TCP als verbindungsorientiertem Transportprotokoll betrieben werden . ^{[ 12 ]}

1995 entwarf Tatu Ylönen , Forscher an der Technischen Universität Helsinki in Finnland, die erste Version des Protokolls (heute SSH-1 genannt), nachdem es in seinem Universitätsnetzwerk zu einem Passwort -Sniffing- Angriff gekommen war . ^{[ 13 ]} Ziel von SSH war es, die früheren Protokolle rlogin , TELNET , FTP ^{[ 14 ]} und rsh zu ersetzen , die weder eine starke Authentifizierung noch Vertraulichkeit gewährleisteten. Er wählte Port 22, da dieser zwischen Port 23 und Port 21 liegt. ^{[ 15 ]}telnetftp

Ylönen veröffentlichte seine Implementierung im Juli 1995 als Freeware , und das Tool erfreute sich schnell großer Beliebtheit. Gegen Ende 1995 war die SSH-Nutzerbasis auf 20.000 Nutzer in fünfzig Ländern angewachsen. ^{[ 16 ]}

Im Dezember 1995 gründete Ylönen SSH Communications Security, um SSH zu vermarkten und weiterzuentwickeln. Die ursprüngliche Version der SSH-Software nutzte verschiedene freie Softwarekomponenten , wie beispielsweise GNU libgmp , aber spätere Versionen von SSH Communications Security entwickelten sich zunehmend zu proprietärer Software .

Man schätzte, dass die Zahl der Nutzer bis zum Jahr 2000 auf 2 Millionen angewachsen war. ^{[ 17 ]}

Im Jahr 2006 wurde nach Diskussionen in der Arbeitsgruppe „secsh“ ^{[ 18 ]} eine überarbeitete Version des SSH-Protokolls, SSH-2, als Standard eingeführt. ^{[ 19 ]} Diese Version bietet verbesserte Sicherheit und neue Funktionen, ist jedoch nicht mit SSH-1 kompatibel. Beispielsweise führt sie neue Schlüsselaustauschmechanismen wie den Diffie-Hellman-Schlüsselaustausch ein und verbessert die Datenintegritätsprüfung durch Message Authentication Codes (MACs) wie MD5 oder SHA-1 , die zwischen Client und Server ausgehandelt werden können. SSH-2 bietet außerdem stärkere Verschlüsselungsmethoden wie AES , die schwächere und anfällige Verschlüsselungsverfahren des Vorgängerstandards wie 3DES ersetzten . ^{[ 20 ] [ 21 ] [ 19 ]} Zu den neuen Funktionen von SSH-2 gehört die Möglichkeit, beliebig viele Shell- Sitzungen über eine einzige SSH-Verbindung auszuführen. ^{[ 22 ]} Aufgrund der Überlegenheit und Popularität von SSH-2 gegenüber SSH-1 unterstützten einige Implementierungen wie libssh (v0.8.0+), ^{[ 23 ]} Lsh ^{[ 24 ]} und Dropbear ^{[ 25 ]} schließlich nur noch das SSH-2-Protokoll.

Im Januar 2006, also lange nach der Etablierung von Version 2.1, legte RFC 4253 fest, dass ein SSH-Server, der sowohl Version 2.0 als auch frühere Versionen unterstützt, seine Protokollversion mit 1.99 angeben sollte. ^{[ 26 ]} Diese Versionsnummer spiegelt keine historische Softwarerevision wider, sondern dient der Kennzeichnung der Abwärtskompatibilität .  

1999 nahmen Entwickler, die eine freie Softwareversion wünschten, die Softwareentwicklung mit der Version 1.2.12 des ursprünglichen SSH-Programms wieder auf, der letzten unter einer Open-Source-Lizenz veröffentlichten Version . ^{[ 27 ]} Diese diente als Codebasis für Björn Grönvalls OSSH-Software. ^{[ 28 ]} Kurz darauf forkten die OpenBSD- Entwickler Grönvalls Code und entwickelten OpenSSH , das mit OpenBSD Release 2.6 ausgeliefert wurde. Aus dieser Version wurde ein „Portabilitätszweig“ gebildet, um OpenSSH auf andere Betriebssysteme zu portieren. ^{[ 29 ]}

Im Jahr 2005 war OpenSSH die mit Abstand beliebteste SSH-Implementierung und in vielen Betriebssystemdistributionen als Standardversion vorinstalliert. OSSH hingegen gilt als veraltet. ^{[ 30 ]} OpenSSH wird weiterhin gepflegt und unterstützt das SSH-2-Protokoll, nachdem die Unterstützung für SSH-1 in Version 7.6 aus dem Quellcode entfernt wurde.

Im Jahr 2023 wurde von Doktorand François Michel und Professor Olivier Bonaventure unter dem Namen SSH3 ^{[ 31 ] [ 32 ] [ 33 ] eine Alternative zum traditionellen SSH vorgeschlagen, deren Quellcode als Open Source veröffentlicht wurde. [ 34 ]} Diese neue Version implementiert das ursprüngliche SSH-Verbindungsprotokoll, basiert jedoch auf HTTP/3 , welches auf QUIC aufbaut . Sie bietet zahlreiche Funktionen, darunter:

• Schnellerer Verbindungsaufbau, wodurch die Anzahl der Roundtrip-Verzögerungen von 5-7 auf 3 reduziert wird.
• Hohe Sicherheit: Während SSHv2 auf eigenen Protokollen basiert, nutzt SSH3 TLS 1.3 , QUIC und HTTP .
• UDP-Portweiterleitung
• X.509-Zertifikate
• OpenID Connect

Der Name SSH3 wird jedoch diskutiert, und das Projekt strebt eine Umbenennung in einen passenderen Namen an. ^{[ 35 ]} Die Diskussion rührt daher, dass diese neue Implementierung das SSH-Protokoll grundlegend überarbeitet, weshalb die Bezeichnung SSH3 unpassend erscheint.

SSH ist ein Protokoll, das für zahlreiche Anwendungen auf vielen Plattformen eingesetzt werden kann, darunter die meisten Unix-Varianten (Linux, die BSD-Systeme einschließlich Apples macOS und Solaris ) sowie Microsoft Windows . Einige der unten aufgeführten Anwendungen benötigen möglicherweise Funktionen, die nur mit bestimmten SSH-Clients oder -Servern verfügbar oder kompatibel sind. Beispielsweise ist die Implementierung eines VPNs über das SSH-Protokoll zwar möglich, derzeit jedoch nur mit der OpenSSH -Server- und Client-Implementierung.

• Zum Anmelden an einer Shell auf einem entfernten Host (als Ersatz für Telnet und rlogin )
• Zum Ausführen eines einzelnen Befehls auf einem entfernten Host (als Ersatz für rsh )
• Zum Einrichten einer automatischen (passwortlosen) Anmeldung an einem Remote-Server (z. B. mit OpenSSH ^{[ 36 ]} )
• In Kombination mit rsync zum effizienten und sicheren Sichern, Kopieren und Spiegeln von Dateien.
• Zum Weiterleiten eines Ports
• Für Tunneling (nicht zu verwechseln mit einem VPN , das Pakete zwischen verschiedenen Netzwerken weiterleitet oder zwei Broadcast-Domänen zu einer verbindet ).
• Zur Verwendung als vollwertiges verschlüsseltes VPN. Beachten Sie, dass diese Funktion nur von OpenSSH- Servern und -Clients unterstützt wird.
• Zum Weiterleiten von X von einem entfernten Host (möglich über mehrere Zwischenhosts)
• Zum Surfen im Internet über eine verschlüsselte Proxy-Verbindung mit SSH-Clients, die das SOCKS-Protokoll unterstützen .
• Zum sicheren Einbinden eines Verzeichnisses auf einem entfernten Server als Dateisystem auf einem lokalen Computer mittels SSHFS .
• Zur automatisierten Fernüberwachung und -verwaltung von Servern mittels eines oder mehrerer der oben genannten Mechanismen.
• Für die Entwicklung auf einem mobilen oder eingebetteten Gerät, das SSH unterstützt.
• Zur Sicherung von Dateiübertragungsprotokollen.

Die Secure Shell-Protokolle werden in verschiedenen Dateiübertragungsmechanismen verwendet.

• Secure Copy (SCP) entwickelte sich aus dem RCP- Protokoll über SSH.
• rsync ist als effizientere Alternative zu SCP konzipiert und läuft üblicherweise über eine SSH-Verbindung.
• SSH File Transfer Protocol (SFTP), eine sichere Alternative zu FTP (nicht zu verwechseln mit FTP über SSH oder FTPS ).
• Files Transferd over Shell Protocol (FISH), veröffentlicht 1998, entwickelte sich aus Unix-Shell- Befehlen über SSH.
• Das Fast and Secure Protocol (FASP), auch bekannt als Aspera , verwendet SSH zur Steuerung und UDP-Ports für die Datenübertragung.

Das SSH-Protokoll besitzt eine geschichtete Architektur mit drei separaten Komponenten:

• Die Transportschicht ( RFC 4253 ) verwendet typischerweise das Transmission Control Protocol (TCP) von TCP/IP und reserviert Port 22 als Server-Listening-Port. Diese Schicht übernimmt den initialen Schlüsselaustausch sowie die Serverauthentifizierung und richtet Verschlüsselung, Komprimierung und Integritätsprüfung ein. Sie stellt der darüberliegenden Schicht eine Schnittstelle zum Senden und Empfangen von Klartextpaketen mit einer Größe von bis zu 32.768 Byte zur Verfügung; je nach Implementierung können jedoch auch größere Pakete übertragen werden. Die Transportschicht sorgt außerdem für den erneuten Schlüsselaustausch, üblicherweise nach der Übertragung von 1 GB Daten oder nach Ablauf einer Stunde, je nachdem, was zuerst eintritt. 
• Die Benutzerauthentifizierungsschicht ( RFC 4252 ) übernimmt die Clientauthentifizierung und stellt eine Reihe von Authentifizierungsalgorithmen bereit. Die Authentifizierung erfolgt clientseitig : Wenn ein Benutzer zur Eingabe eines Passworts aufgefordert wird, geschieht dies in der Regel durch den SSH-Client und nicht durch den Server. Der Server beantwortet lediglich die Authentifizierungsanfragen des Clients. Zu den weit verbreiteten Benutzerauthentifizierungsmethoden gehören die folgenden:  
  • Passwort : Eine Methode zur einfachen Passwortauthentifizierung, die auch die Möglichkeit bietet, ein Passwort zu ändern. Nicht alle Programme implementieren diese Methode.
  • publickey : eine Methode zur Authentifizierung mit öffentlichen Schlüsseln , die in der Regel mindestens DSA- , ECDSA- oder RSA- Schlüsselpaare unterstützt, wobei andere Implementierungen auch X.509- Zertifikate unterstützen.
  • Tastaturinteraktiv ( RFC 4256 ): Eine vielseitige Methode, bei der der Server eine oder mehrere Eingabeaufforderungen sendet, die der Client anzeigt und die vom Benutzer eingegebenen Antworten zurücksendet. Wird zur Einmalpasswortauthentifizierung wie S/Key oder SecurID verwendet . Bei einigen OpenSSH - Konfigurationen, wenn PAM als Host-Authentifizierungsanbieter dient, wird diese Methode verwendet, um eine effektive Passwortauthentifizierung zu gewährleisten. Dies kann jedoch dazu führen, dass sich Clients, die nur die einfache Passwortauthentifizierung unterstützen, nicht anmelden können . 
  • GSSAPI -Authentifizierungsmethoden bieten ein erweiterbares Schema zur SSH-Authentifizierung mithilfe externer Mechanismen wie Kerberos 5 oder NTLM und ermöglichen so Single Sign-On für SSH-Sitzungen. Diese Methoden werden üblicherweise von kommerziellen SSH-Implementierungen für den Einsatz in Unternehmen verwendet, obwohl auch OpenSSH eine funktionierende GSSAPI-Implementierung besitzt.
• Die Verbindungsschicht ( RFC 4254 ) definiert die Konzepte von Kanälen, Kanalanfragen und globalen Anfragen, welche die bereitgestellten SSH-Dienste festlegen. Eine einzelne SSH-Verbindung kann gleichzeitig in mehrere logische Kanäle gemultiplext werden, die jeweils Daten bidirektional übertragen. Kanalanfragen dienen der Weiterleitung von kanalspezifischen Daten außerhalb des regulären Datenstroms, wie beispielsweise der geänderten Größe eines Terminalfensters oder dem Exit-Code eines serverseitigen Prozesses. Zusätzlich führt jeder Kanal seine eigene Flusssteuerung mithilfe der Empfangsfenstergröße durch. Der SSH-Client fordert über eine globale Anfrage einen serverseitigen Port zur Weiterleitung an. Zu den Standard-Kanaltypen gehören:  
  • Shell für Terminal-Shells, SFTP- und exec-Anfragen (einschließlich SCP-Übertragungen)
  • direct-tcpip für Client-Server-Weiterleitungen
  • forwarded-tcpip für Server-zu-Client-Weiterleitungen
• Der SSHFP -DNS-Eintrag (RFC 4255) stellt die öffentlichen Host-Key-Fingerabdrücke bereit, um die Überprüfung der Authentizität des Hosts zu erleichtern.

Diese offene Architektur bietet beträchtliche Flexibilität und ermöglicht die Nutzung von SSH für vielfältige Zwecke jenseits einer sicheren Shell. Die Funktionalität der Transportschicht allein ist mit Transport Layer Security (TLS) vergleichbar; die Benutzerauthentifizierungsschicht ist mit benutzerdefinierten Authentifizierungsmethoden hochgradig erweiterbar; und die Verbindungsschicht ermöglicht das Multiplexen mehrerer sekundärer Sitzungen in eine einzige SSH-Verbindung – eine Funktion, die mit BEEP vergleichbar und in TLS nicht verfügbar ist.

• EdDSA , ^{[ 37 ]} ECDSA , RSA und DSA für Public-Key-Kryptographie . ^{[ 38 ]}
• ECDH und Diffie-Hellman für den Schlüsselaustausch . ^{[ 38 ]}
• HMAC , AEAD und UMAC für MAC . ^{[ 39 ]}
• AES (und die veralteten Verfahren RC4 , 3DES , DES ^{[ 40 ]} ) für symmetrische Verschlüsselung .
• AES-GCM ^{[ 41 ]} und ChaCha20-Poly1305 für die AEAD- Verschlüsselung.
• SHA (und das veraltete MD5 ) für den Schlüsselfingerabdruck .

1998 wurde eine Schwachstelle in SSH 1.5 beschrieben, die das unbefugte Einfügen von Inhalten in einen verschlüsselten SSH-Stream ermöglichte. Grund dafür war der unzureichende Schutz der Datenintegrität durch die in dieser Protokollversion verwendete CRC-32- Prüfsumme. ^{[ 42 ] [ 43 ]} Ein Fix, bekannt als SSH Compensation Attack Detector ^{[ 44 ],} wurde in die meisten Implementierungen integriert. Viele dieser aktualisierten Implementierungen wiesen jedoch eine neue Schwachstelle durch einen Integer-Überlauf auf ^{[ 45 ]} , die es Angreifern ermöglichte, beliebigen Code mit den Berechtigungen des SSH-Daemons, typischerweise dem Root-Benutzer, auszuführen.

Im Januar 2001 wurde eine Sicherheitslücke entdeckt, die es Angreifern ermöglicht, den letzten Block einer IDEA- verschlüsselten Sitzung zu verändern. ^{[ 46 ]} Im selben Monat wurde eine weitere Sicherheitslücke entdeckt, die es einem bösartigen Server ermöglichte, die Client-Authentifizierung an einen anderen Server weiterzuleiten. ^{[ 47 ]}

Da SSH-1 systembedingte Schwächen aufweist, die es angreifbar machen, gilt es heute allgemein als veraltet und sollte durch explizites Deaktivieren des Fallbacks auf SSH-1 vermieden werden. Die meisten modernen Server und Clients unterstützen SSH-2. ^{[ 47 ]}

Im November 2008 wurde eine theoretische Sicherheitslücke in allen SSH-Versionen entdeckt, die es ermöglichte, bis zu 32 Bit Klartext aus einem mit dem damals standardmäßigen Verschlüsselungsmodus CBC verschlüsselten Chiffretextblock wiederherzustellen . ^{[ 48 ]} Die einfachste Lösung besteht darin, anstelle des CBC-Modus den CTR -Modus (Counter Mode) zu verwenden, da SSH dadurch gegen diesen Angriff resistent wird. ^{[ 48 ]}

Am 28. Dezember 2014 veröffentlichte der Spiegel geheime Informationen ^{[ 49 ],} die vom Whistleblower Edward Snowden durchgesickert waren und darauf hindeuteten, dass die National Security Agency (NSA) möglicherweise in der Lage sein könnte, Teile des SSH-Verkehrs zu entschlüsseln. Die technischen Details eines solchen Prozesses wurden nicht offengelegt. Eine Analyse der CIA- Hacking-Tools BothanSpy und Gyrfalcon aus dem Jahr 2017 legte nahe, dass das SSH-Protokoll nicht kompromittiert wurde. ^{[ 50 ]}

Im Jahr 2023 wurde eine neuartige Man-in-the-Middle-Attacke gegen die meisten gängigen SSH-Implementierungen entdeckt. Ihre Entdecker nannten sie Terrapin-Angriff . ^{[ 51 ] [ 52 ]} Das Risiko wird jedoch dadurch gemindert, dass eine authentische SSH-Sitzung abgefangen werden muss und der Angriff in seinem Umfang begrenzt ist, sodass er glücklicherweise meist zu Verbindungsabbrüchen führt. ^{[ 53 ] [ 54 ]} Die SSH-Entwickler gaben an, dass die Hauptauswirkung der Attacke in der Beeinträchtigung der Funktionen zur Verschleierung der Tastenanschlagzeiten von SSH besteht. ^{[ 54 ]} Die Schwachstelle wurde in OpenSSH 9.6 behoben, jedoch müssen sowohl Client als auch Server aktualisiert werden, damit die Behebung vollständig wirksam ist.

Die folgenden RFC- Veröffentlichungen der IETF- Arbeitsgruppe "secsh" dokumentieren SSH-2 als vorgeschlagenen Internetstandard .

• RFC  4250 – Das Secure Shell (SSH)-Protokoll – Zugewiesene Nummern
• RFC  4251 – Die Secure Shell (SSH) Protokollarchitektur
• RFC  4252 – Das Secure Shell (SSH) Authentifizierungsprotokoll
• RFC  4253 – Das Secure Shell (SSH) Transport Layer Protocol
• RFC  4254 – Das Secure Shell (SSH) Verbindungsprotokoll
• RFC  4255 – Verwendung von DNS zur sicheren Veröffentlichung von SSH-Schlüsselfingerabdrücken
• RFC  4256 – Generische Nachrichtenaustauschauthentifizierung für das Secure Shell Protocol (SSH)
• RFC  4335 – Die Secure Shell (SSH) Session Channel Break Extension
• RFC  4344 – Die Secure Shell (SSH) Transport Layer Encryption Modes
• RFC  4345 – Verbesserte Arcfour-Modi für das Secure Shell (SSH) Transport Layer Protocol

Die Protokollspezifikationen wurden später durch die folgenden Veröffentlichungen aktualisiert:

• RFC  4419 – Diffie-Hellman-Gruppenaustausch für das Secure Shell (SSH) Transport Layer Protocol (März 2006)
• RFC  4432 – RSA-Schlüsselaustausch für das Secure Shell (SSH) Transport Layer Protocol (März 2006)
• RFC  4462 – Generic Security Service Application Programming Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol (Mai 2006)
• RFC  4716 – Das Secure Shell (SSH) Public Key File Format (November 2006)
• RFC  4819 – Secure Shell Public Key Subsystem (März 2007)
• RFC  5647 – AES Galois Counter Mode für das Secure Shell Transport Layer Protocol (August 2009)
• RFC  5656 – Integration des Elliptic Curve Algorithm in die Secure Shell Transportschicht (Dezember 2009)
• RFC  6187 – X.509v3-Zertifikate für die Secure Shell-Authentifizierung (März 2011)
• RFC  6239 – Suite B Kryptografische Suiten für Secure Shell (SSH) (Mai 2011)
• RFC  6594 – Verwendung des SHA-256-Algorithmus mit RSA, Digital Signature Algorithm (DSA) und Elliptic Curve DSA (ECDSA) in SSHFP-Ressourcendatensätzen (April 2012)
• RFC  6668 – SHA-2-Datenintegritätsprüfung für das Secure Shell (SSH)-Transportschichtprotokoll (Juli 2012)
• RFC  7479 – Ed25519 SSHFP-Ressourcendatensätze (März 2015)
• RFC  5592 – Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) (Juni 2009)
• RFC  6242 – Verwendung des NETCONF-Protokolls über Secure Shell (SSH) (Juni 2011)
• RFC  8332 – Verwendung von RSA-Schlüsseln mit SHA-256 und SHA-512 im Secure Shell (SSH)-Protokoll (März 2018)
• RFC  8709 – Ed25519 und Ed448 Public-Key-Algorithmen für das Secure Shell (SSH)-Protokoll (Februar 2020)
• draft-gerhards-syslog-transport-ssh – SSH-Transportzuordnung für SYSLOG (Juli 2006)
• draft-ietf-secsh-filexfer – SSH-Dateiübertragungsprotokoll (Juli 2006)
• draft-ietf-sshm-ssh-agent - SSH-Agent-Protokoll (März 2025)

Darüber hinaus umfasst das OpenSSH -Projekt mehrere herstellerspezifische Protokollspezifikationen/Erweiterungen:

• OpenSSH-Protokoll – Übersicht
• OpenSSH-Zertifikat-/Schlüsselübersicht
• OpenSSH FIDO/u2f-Unterstützung

• Brute-Force-Angriff
• Vergleich von SSH-Clients
• Vergleich von SSH-Servern
• Korkenzieher
• Ident
• OpenSSH
• Secure Shell Tunneling
• Webbasierte SSH-Verbindung

• Barrett, Daniel J .; Silverman, Richard E.; Byrnes, Robert G. (2005). SSH: Die sichere Shell (Das umfassende Handbuch) (2. Aufl.). O'Reilly. ISBN 0-596-00895-3Die
• Lucas, Michael W. (2018). SSH Mastery (2. Aufl.). Tilted Windmill Press. ISBN 9781642350029Die
• Stahnke, Michael (2005). Pro OpenSSH . Apress. ISBN 1-59059-476-2Die
• Tatu Ylönen (12. Juli 1995). „Ankündigung: Ssh (Secure Shell) Remote-Login-Programm“ . comp.security.unix.Ursprüngliche Ankündigung von SSH
• Dwivedi, Himanshu (2003). SSH implementieren . Wiley. ISBN 978-0-471-45880-7Die

• SSH-Protokolle
• M. Joseph; J. Susoy (November 2013). P6R's Secure Shell Public Key Subsystem . IETF . doi : 10.17487/RFC7076 . RFC 7076 .
• Originales SSH-Quellcode-Tarball