Die erste Version von SSH erschien 1995 und wurde von Tatu Ylönen entworfen, der zu dieser Zeit Forscher an der Technischen Universität Helsinki war und später SSH Communications Security, einen Anbieter von Cybersicherheit mit Sitz in Finnland, gründete. Im Laufe der Zeit wurden verschiedene Fehler in SSH-1 gefunden, und diese Version gilt heute als veraltet und nicht mehr sicher in der Anwendung.
SSH-2, die aktuelle Version der Secure Shell-Protokolle, wurde 2006 von der Internet Engineering Task Force (IETF) als Standards Track-Spezifikation angenommen. SSH-2 ist nicht mit SSH-1 kompatibel und verwendet einen Diffie-Hellman-Schlüsselaustausch und eine stärkere Integritätsprüfung, die zur Verbesserung der Sicherheit Nachrichten-Authentifizierungscodes verwendet. SSH-Clients und -Server können eine Reihe von Verschlüsselungsmethoden verwenden, von denen Advanced Encryption Standard (AES) und Blowfish die am weitesten verbreiteten sind.
Bislang sind keine ausnutzbaren Schwachstellen in SSH-2 bekannt, obwohl Informationen, die Edward Snowden 2013 durchsickerte, darauf hindeuteten, dass die Nationale Sicherheitsbehörde (NSA) in der Lage sein könnte, einen Teil des SSH-Verkehrs zu entschlüsseln.
Sicherheitsprobleme bei Secure Shell Unternehmen, die SSH verwenden, sollten nach Möglichkeiten suchen, Host-Schlüssel zu verwalten, die auf Client-Systemen gespeichert sind; diese Schlüssel können sich im Laufe der Zeit ansammeln, insbesondere für IT-Mitarbeiter, die zu Verwaltungszwecken auf entfernte Hosts zugreifen können müssen. Da die in einer SSH-Datei "known_hosts" gespeicherten Daten dazu verwendet werden können, authentifizierten Zugriff auf entfernte Systeme zu erhalten, sollten Organisationen sich der Existenz dieser Dateien bewusst sein und über ein Standardverfahren verfügen, um die Kontrolle über die Dateien zu behalten, auch nachdem ein System außer Betrieb genommen wurde, da die Festplatten diese Daten im Klartext gespeichert haben können.
Entwickler sollten auch vorsichtig sein, wenn sie SSH-Befehle oder -Funktionen in ein Skript oder einen anderen Programmtyp integrieren. Es ist zwar möglich, einen SSH-Befehl mit einer Benutzer-ID und einem Kennwort zu erteilen, um den Benutzer des lokalen Rechners gegenüber einem Konto auf dem entfernten Host zu authentifizieren, doch kann dies die Zugangsdaten einem Angreifer mit Zugriff auf den Quellcode offenbaren.
Shellshock, eine Sicherheitslücke im Befehlsprozessor der Bash, kann über SSH ausgeführt werden, ist jedoch eine Schwachstelle in der Bash, nicht in SSH. Die größte Bedrohung für SSH ist eine schlechte Schlüsselverwaltung. Ohne die ordnungsgemäße zentralisierte Erstellung, Rotation und Entfernung von SSH-Schlüsseln können Organisationen die Kontrolle darüber verlieren, wer wann Zugriff auf welche Ressourcen hat, insbesondere wenn SSH in automatisierten Application-to-Application-Prozessen verwendet wird.
Stand: 27.07.2020