Sichere Shell - Wikipedia

Secure Shell ( SSH ) ist ein kryptografisches Netzwerkprotokoll zum sicheren Betreiben von Netzwerkdiensten über ein ungesichertes Netzwerk. ^[1] Typische Anwendungen umfassen die Remote-Befehlszeilenanmeldung und die Remote-Befehlsausführung, jedoch beliebige Der Netzwerkdienst kann mit SSH gesichert werden.

SSH bietet einen sicheren Kanal über ein ungesichertes Netzwerk in einer Client-Server-Architektur und verbindet eine SSH-Clientanwendung mit einem SSH-Server. ^[2] Die Protokollspezifikation unterscheidet zwischen zwei Hauptversionen, die als SSH-1 und SSH bezeichnet werden. 2 Der Standard-TCP-Port für SSH ist 22. SSH wird im Allgemeinen für den Zugriff auf Unix-ähnliche Betriebssysteme verwendet, kann jedoch auch unter Windows verwendet werden. Windows 10 verwendet OpenSSH als Standard-SSH-Client. ^[3]

SSH wurde als Ersatz für Telnet und für nicht gesicherte Remote-Shell-Protokolle wie die Protokolle Berkeley rlogin, rsh und rexec entwickelt. Diese Protokolle senden Informationen, insbesondere Passwörter, im Klartext und machen sie mittels Paketanalyse abhör- und offenbar. ^[4] Die von SSH verwendete Verschlüsselung soll die Vertraulichkeit und Integrität von Daten über ein ungesichertes Netzwerk wie das Internet gewährleisten Dateien, die von Edward Snowden durchgesickert wurden, weisen darauf hin, dass die Nationale Sicherheitsbehörde SSH manchmal entschlüsseln kann, wodurch sie den Inhalt von SSH-Sitzungen lesen kann. ^[5]

Definition [ edit

SSH verwendet public-key Kryptographie, um den entfernten Computer zu authentifizieren und bei Bedarf die Authentifizierung des Benutzers zu ermöglichen. ^[2] Es gibt mehrere Möglichkeiten, SSH zu verwenden. Verwenden Sie automatisch generierte Public-Private-Key-Paare, um einfach eine Netzwerkverbindung zu verschlüsseln, und verwenden Sie dann die Kennwortauthentifizierung zum Anmelden.

Eine andere ist die Verwendung eines manuell generierten Paars aus öffentlichem und privatem Schlüssel zur Authentifizierung, sodass sich Benutzer oder Programme anmelden können, ohne ein Kennwort angeben zu müssen. In diesem Szenario kann jeder ein übereinstimmendes Paar verschiedener Schlüssel (öffentlich und privat) erstellen. Der öffentliche Schlüssel wird auf allen Computern platziert, auf die der Besitzer des übereinstimmenden privaten Schlüssels zugreifen muss (der Eigentümer hält den privaten Schlüssel geheim). Während die Authentifizierung auf dem privaten Schlüssel basiert, wird der Schlüssel selbst während der Authentifizierung niemals über das Netzwerk übertragen. SSH prüft nur, ob dieselbe Person, die den öffentlichen Schlüssel anbietet, auch den passenden privaten Schlüssel besitzt. In allen Versionen von SSH ist es wichtig, unbekannte öffentliche Schlüssel zu überprüfen, d. H. Die öffentlichen Schlüssel mit Identitäten zu verknüpfen, bevor sie als gültig akzeptiert werden. Wenn Sie den öffentlichen Schlüssel eines Angreifers ohne Bestätigung akzeptieren, wird ein nicht autorisierter Angreifer als gültiger Benutzer autorisiert.

Schlüsselverwaltung [ edit ]

Auf Unix-ähnlichen Systemen wird die Liste der autorisierten öffentlichen Schlüssel normalerweise im Basisverzeichnis des Benutzers gespeichert, der sich remote anmelden darf. in der Datei ~ / .ssh / authorised_keys. ^[6] Diese Datei wird von SSH nur dann beachtet, wenn sie außer dem Eigentümer und dem Stamm nicht beschreibbar ist. Wenn am öffentlichen Ende der öffentliche Schlüssel und am lokalen Ende der übereinstimmende private Schlüssel vorhanden ist, ist das Eingeben des Kennworts nicht mehr erforderlich (einige Software wie der MPI-Stack (Message Passing Interface) erfordert möglicherweise den Zugriff ohne Kennwort, um ausgeführt zu werden richtig). Für zusätzliche Sicherheit kann der private Schlüssel selbst jedoch mit einer Passphrase gesperrt werden.

Der private Schlüssel kann auch an normalen Orten gesucht werden. Der vollständige Pfad kann als Befehlszeileneinstellung angegeben werden (Option -i für ssh). Das Dienstprogramm ssh-keygen erstellt die öffentlichen und privaten Schlüssel immer paarweise.

SSH unterstützt auch die kennwortbasierte Authentifizierung, die durch automatisch generierte Schlüssel verschlüsselt wird. In diesem Fall könnte der Angreifer die legitime Serverseite imitieren, nach dem Kennwort fragen und es erhalten (Man-in-the-Middle-Angriff). Dies ist jedoch nur möglich, wenn die beiden Seiten noch nie authentifiziert wurden, da SSH den Schlüssel speichert, den die Serverseite zuvor verwendet hat. Der SSH-Client gibt eine Warnung aus, bevor er den Schlüssel eines neuen, bisher unbekannten Servers akzeptiert. Die Passwortauthentifizierung kann deaktiviert werden.

SSH wird normalerweise verwendet, um sich an einem Remote-Computer anzumelden und Befehle auszuführen, er unterstützt jedoch auch das Tunneln, Weiterleiten von TCP-Ports und X11-Verbindungen. Es kann Dateien mit den zugehörigen SSH-Dateiübertragungsprotokollen (SFTP) oder SCP-Protokollen (Secure Copy) übertragen. ^[2] SSH verwendet das Client-Server-Modell.

Der Standard-TCP-Port 22 wurde für die Kontaktierung von SSH-Servern zugewiesen. ^[7]

Ein SSH-Client-Programm wird normalerweise verwendet, um Verbindungen zu einem SSH-Dämon herzustellen, der Remoteverbindungen akzeptiert. Beide sind häufig auf den meisten modernen Betriebssystemen vorhanden, einschließlich MacOS, den meisten Linux-, OpenBSD-, FreeBSD-, NetBSD-, Solaris- und OpenVMS-Distributionen. Insbesondere enthält die Windows-Version vor 1709 standardmäßig kein SSH. Proprietäre, Freeware- und Open-Source-Versionen (z. B. PuTTY ^[8] und die Version von OpenSSH, die Teil von Cygwin ^[9] ist), gibt es in verschiedenen Komplexitäts- und Vollständigkeitsstufen. Dateimanager für UNIX-ähnliche Systeme (z. B. Konqueror) können das FISH-Protokoll verwenden, um eine GUI mit geteiltem Fensterbereich durch Ziehen und Ablegen bereitzustellen. Das Open-Source-Windows-Programm WinSCP ^[10] bietet ähnliche Dateiverwaltungsfunktionen (Synchronisierung, Kopieren, Fernlöschen), die PuTTY als Back-End verwenden. Sowohl WinSCP ^[11] als auch PuTTY ^[12] sind als Paket erhältlich und können direkt von einem USB-Laufwerk ausgeführt werden, ohne dass eine Installation auf dem Client-Computer erforderlich ist. Zum Einrichten eines SSH-Servers in Windows müssen Sie in der Einstellungs-App eine Funktion aktivieren. In Windows 10 Version 1709 ist eine offizielle Win32-Port von OpenSSH verfügbar.

SSH ist im Cloud-Computing wichtig, um Konnektivitätsprobleme zu lösen, und vermeidet die Sicherheitsprobleme, wenn eine cloudbasierte virtuelle Maschine direkt im Internet verfügbar gemacht wird. Ein SSH-Tunnel kann einen sicheren Pfad über das Internet durch eine Firewall zu einer virtuellen Maschine bereitstellen. ^[13]

Geschichte und Entwicklung [ edit

Version 1.x edit ]

Im Jahr 1995 entwarf Tatu Ylönen, Forscher an der Technischen Universität Helsinki, Finnland, die erste Version des Protokolls (jetzt SSH-1 ), die durch ein Kennwort aufgefordert wurde Angriff auf sein Universitätsnetzwerk. ^[14] Das Ziel von SSH war es, die früheren Protokolle rlogin, TELNET, FTP ^[15] und rsh zu ersetzen, die weder eine starke Authentifizierung noch Vertraulichkeit gewährten. Ylönen veröffentlichte seine Implementierung im Juli 1995 als Freeware, und das Tool gewann rasch an Popularität. Gegen Ende 1995 war die Zahl der SSH-Nutzer in fünfzig Ländern auf 20.000 angewachsen.

Im Dezember 1995 gründete Ylönen SSH Communications Security zur Vermarktung und Entwicklung von SSH. In der ursprünglichen Version der SSH-Software wurden verschiedene freie Softwarekomponenten wie GNU libgmp verwendet. Spätere Versionen, die von SSH Communications Security veröffentlicht wurden, entwickelten sich zu einer zunehmend proprietären Software.

Es wurde geschätzt, dass die Anzahl der Benutzer im Jahr 2000 auf 2 Millionen angestiegen war. ^[16]

Version 2.x [ edit

"Secsh" war das offizielle Internet IETF-Name der IETF-Arbeitsgruppe, die für die Version 2 des SSH-Protokolls verantwortlich ist. ^[17] Im Jahr 2006 wurde eine überarbeitete Version des Protokolls SSH-2 als Standard verabschiedet. Diese Version ist nicht mit SSH-1 kompatibel. SSH-2 bietet sowohl Sicherheits- als auch Funktionsverbesserungen gegenüber SSH-1. Bessere Sicherheit wird beispielsweise durch den Austausch von Diffie-Hellman-Schlüsseln und eine strenge Integritätsprüfung über Nachrichtenauthentifizierungscodes erreicht. Zu den neuen Funktionen von SSH-2 gehört die Möglichkeit, eine beliebige Anzahl von Shell-Sitzungen über eine einzige SSH-Verbindung auszuführen. ^[18] Aufgrund der Überlegenheit und Beliebtheit von SSH-2 gegenüber SSH-1 können einige Implementierungen wie libssh (v0.8.0 +) [19659042]Lsh ^[20] und Dropbear ^[21] unterstützen nur das SSH-2-Protokoll.

Version 1.99 [ edit ]

Im Januar 2006, lange nachdem Version 2.1 eingeführt wurde, gab RFC 4253 an, dass ein SSH-Server, der sowohl 2.0 als auch frühere Versionen von SSH unterstützt, seine Version identifizieren sollte Protoversion als 1.99. ^[22] Dies ist keine aktuelle Version, sondern eine Methode zur Ermittlung der Abwärtskompatibilität.

OpenSSH und OSSH [ edit ]

Im Jahr 1999 gingen Entwickler, die eine freie Softwareversion haben wollten, auf die ältere Version 1.2.12 des ursprünglichen SSH-Programms zurück. Dies war die letzte unter einer Open Source-Lizenz veröffentlichte. Aus dieser Codebase wurde anschließend der OSSH von Björn Grönvall entwickelt. Kurz darauf gaben die OpenBSD-Entwickler den Code von Grönvall frei und arbeiteten ausgiebig daran, indem sie OpenSSH entwickelten, das mit der Version 2.6 von OpenBSD ausgeliefert wurde. Von dieser Version aus wurde ein Zweig für "Portabilität" gebildet, um OpenSSH auf andere Betriebssysteme zu portieren. ^[23]

Ab 2005 ^[update] war OpenSSH die standardmäßig am häufigsten verwendete SSH-Implementierung in einer großen Anzahl von Betriebssystemen. OSSH ist mittlerweile veraltet. ^[24] OpenSSH wird weiterhin gewartet und unterstützt das SSH-2-Protokoll, nachdem mit der Veröffentlichung von OpenSSH 7.6 die SSH-1-Unterstützung aus der Codebase gestrichen wurde.

Beispiel für das Tunneln einer X11-Anwendung über SSH: Der Benutzer 'josh' hat SSHed vom lokalen Rechner 'foofighter' auf den entfernten Rechner 'tengwar', um xeyes auszuführen.

SSH ist ein Protokoll, das für viele verwendet werden kann Anwendungen auf vielen Plattformen, einschließlich der meisten Unix-Varianten (Linux, BSDs einschließlich Apples macOS und Solaris) sowie Microsoft Windows. Einige der unten aufgeführten Anwendungen erfordern möglicherweise Funktionen, die nur verfügbar oder mit bestimmten SSH-Clients oder -Servern kompatibel sind. Beispielsweise ist die Verwendung des SSH-Protokolls zum Implementieren eines VPN möglich, derzeit jedoch nur mit der OpenSSH-Server- und -Clientimplementierung.

• Zum Anmelden an einer Shell auf einem Remote-Host (Ersetzen von Telnet und RLOGIN)
• Zum Ausführen eines einzelnen Befehls auf einem Remote-Host (Ersetzen von Rsh).
• Zum Einrichten der automatischen (kennwortlosen) Anmeldung an einem Remote-Server ( B. mit OpenSSH ^[25])
• In Kombination mit rsync zum Sichern, Kopieren und Spiegeln von Dateien effizient und sicher
• Zum Weiterleiten oder Tunneln eines Ports (nicht zu verwechseln mit einem VPN, das Pakete zwischen verschiedenen Paketen weiterleitet Netzwerke oder überbrückt zwei Broadcast-Domänen zu einer.)
• Zur Verwendung als vollwertiges, verschlüsseltes VPN. Beachten Sie, dass nur OpenSSH-Server und -Clients diese Funktion unterstützen.
• Für die Weiterleitung von X von einem Remote-Host (möglich über mehrere Zwischenhosts)
• Für das Surfen im Internet über eine verschlüsselte Proxy-Verbindung mit SSH-Clients, die das SOCKS-Protokoll unterstützen. 19659058] Zum sicheren Einhängen eines Verzeichnisses auf einem Remote-Server als Dateisystem auf einem lokalen Computer unter Verwendung von SSHFS.
• Für die automatische Fernüberwachung und -verwaltung von Servern durch einen oder mehrere der oben beschriebenen Mechanismen.
• Für die Entwicklung auf einem mobilen Gerät oder eingebettetes Gerät, das SSH unterstützt.
• Zum Sichern von Dateiübertragungsprotokollen.

Dateiübertragungsprotokolle [ edit ]

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

Architektur [ edit ]

Diagramm des SSH-2-Binärpakets.

Das SSH-2-Protokoll hat eine interne Architektur (definiert in RFC 4251) mit gut getrenntem Protokoll Schichten, nämlich:

• Die Schicht transport (RFC 4253), die typischerweise auf TCP / IP ausgeführt wird. Diese Schicht übernimmt den ersten Schlüsselaustausch sowie die Serverauthentifizierung und richtet Verschlüsselung, Komprimierung und Integritätsprüfung ein. Es stellt der oberen Schicht eine Schnittstelle zum Senden und Empfangen von Klartextpaketen mit einer Größe von jeweils bis zu 32.768 Bytes zur Verfügung (die Implementierung kann mehr zulassen). Die Transportschicht sorgt auch für den Schlüsselaustausch, in der Regel nach dem Übertragen von 1 GB Daten oder nach Ablauf einer Stunde, je nachdem, was zuerst eintritt.
• Die Schicht Benutzerauthentifizierung (RFC 4252). Diese Schicht behandelt die Clientauthentifizierung und stellt eine Reihe von Authentifizierungsmethoden bereit. Die Authentifizierung ist clientgesteuert : Wenn Sie zur Eingabe eines Kennworts aufgefordert werden, kann es sich um die Aufforderung des SSH-Clients handeln, nicht um den Server. Der Server antwortet lediglich auf die Authentifizierungsanforderungen des Clients. Zu den weit verbreiteten Methoden für die Benutzerauthentifizierung gehören:
  • password : Eine Methode zur unkomplizierten Passwortauthentifizierung, einschließlich einer Einrichtung, mit der ein Passwort geändert werden kann. Nicht alle Programme implementieren diese Methode.
  • publickey : Eine Methode für die Authentifizierung mit öffentlichen Schlüsseln, die normalerweise mindestens DSA-, ECDSA- oder RSA-Schlüsselpaare unterstützt, während andere Implementierungen auch X.509-Zertifikate unterstützen. [19659058] keyboard-interactive (RFC 4256): Eine vielseitige Methode, bei der der Server eine oder mehrere Eingabeaufforderungen zur Eingabe von Informationen sendet. Der Client zeigt sie an und sendet vom Benutzer eingegebene Antworten zurück. Wird zur einmaligen Kennwortauthentifizierung verwendet, z. B. S / Key oder SecurID. Wird von einigen OpenSSH-Konfigurationen verwendet, wenn PAM der zugrunde liegende Hostauthentifizierungsanbieter ist, um die Kennwortauthentifizierung effektiv bereitzustellen, was manchmal dazu führt, dass die Anmeldung nicht bei einem Client möglich ist, der nur die reine -Passwortmethode unterstützt.
  • GSSAPI-Authentifizierung Methoden, die ein erweiterbares Schema zum Durchführen der SSH-Authentifizierung unter Verwendung externer Mechanismen wie Kerberos 5 oder NTLM bereitstellen und SSH-Sitzungen mit Single Sign-On-Funktionalität versehen. Diese Methoden werden normalerweise von kommerziellen SSH-Implementierungen zur Verwendung in Organisationen implementiert, obwohl OpenSSH über eine funktionierende GSSAPI-Implementierung verfügt.
• Die Schicht (RFC 4254). Diese Schicht definiert das Konzept von Kanälen, Kanalanforderungen und globalen Anforderungen, mit denen SSH-Dienste bereitgestellt werden. Eine einzelne SSH-Verbindung kann mehrere Kanäle gleichzeitig hosten, wobei jeweils Daten in beide Richtungen übertragen werden. Kanalanforderungen werden verwendet, um kanalspezifische Out-of-Band-Daten weiterzuleiten, z. B. die geänderte Größe eines Terminalfensters oder den Beendigungscode eines serverseitigen Prozesses. Außerdem führt jeder Kanal eine eigene Flusssteuerung unter Verwendung der Empfangsfenstergröße aus. Der SSH-Client fordert die Weiterleitung eines serverseitigen Ports mithilfe einer globalen Anforderung an. Zu den Standardkanaltypen gehören:
  • shell für Terminal-Shells, SFTP- und Exec-Anforderungen (einschließlich SCP-Transfers)
  • direct-tcpip für Client-zu-Server-Weiterleitungsverbindungen
  • forwarded-tcpip für von Server zu Client weitergeleitete Verbindungen
• Der SSHFP-DNS-Eintrag (RFC 4255) stellt die Fingerabdrücke des öffentlichen Hosts bereit, um die Echtheit des Hosts zu überprüfen.

This open Die Architektur bietet beträchtliche Flexibilität und ermöglicht die Verwendung von SSH für verschiedene Zwecke über eine sichere Shell hinaus. Die Funktionalität der Transportschicht allein ist mit der Transport Layer Security (TLS) vergleichbar. Die Benutzerauthentifizierungsschicht ist mit benutzerdefinierten Authentifizierungsmethoden stark erweiterbar. und die Verbindungsschicht bietet die Möglichkeit, viele sekundäre Sitzungen in eine einzige SSH-Verbindung zu multiplexen, eine Funktion, die mit BEEP vergleichbar ist und in TLS nicht verfügbar ist.

Erweiterungen [ edit ]

Diese sind für Leistungsverbesserungen von SSH-Produkten gedacht:

• SSH-over-SCTP: Unterstützung für SCTP anstelle von TCP als verbindungsorientiertes Transportschichtprotokoll. ^[26]
• ECDSA: Unterstützung für DSA mit elliptischer Kurve anstelle von DSA oder RSA zum Signieren. ^[27]
• ECDH: Unterstützung für elliptische Kurve Diffie – Hellman anstelle von normalem Diffie – Hellman für den Austausch von Verschlüsselungsschlüsseln. ^[5]
• UMAC: eher Unterstützung für UMAC als HMAC für MAC / Integrität. ^[28]

Schwachstellen [ edit ]

SSH-1 [ edit

Im Jahr 1998 wurde eine Schwachstelle beschrieben in SSH 1.5, das die unzulässige Einfügung von Inhalten in einen verschlüsselten SSH-Stream aufgrund eines unzureichenden Schutzes der Datenintegrität durch CRC-32 ermöglicht, der in dieser Version des Protokolls verwendet wird. ^[29][30] Ein als SSH Compensation Attack Detector ^[31] bekannter Fix wurde eingeführt die meisten Implementierungen. Viele dieser aktualisierten Implementierungen enthielten eine neue Ganzzahlüberlauf-Schwachstelle ^[32] durch die Angreifer beliebigen Code mit den Berechtigungen des SSH-Daemons (normalerweise root) ausführen konnte.

Im Januar 2001 wurde eine Sicherheitslücke entdeckt, die es Angreifern ermöglicht, den letzten Block einer IDEA-verschlüsselten Sitzung zu ändern. ^[33] Im selben Monat wurde eine weitere Sicherheitslücke entdeckt, durch die ein böswilliger Server eine Client-Authentifizierung an einen anderen Server weiterleiten konnte. ^[34]

Da SSH-1 inhärente Konstruktionsfehler aufweist, die es anfällig machen, wird es jetzt allgemein als veraltet angesehen und sollte durch explizites Deaktivieren des Rückfalls auf SSH-1 vermieden werden. [19456579] [ ] Zitat benötigt ] Die meisten modernen Server und Clients unterstützen SSH-2. ^{[ Zitat benötigt ]}

CBC-Klartextwiederherstellung [ edit ]

Im November 2008 wurde eine theoretische Schwachstelle für alle Versionen von SSH entdeckt, die die Wiederherstellung von bis zu 32 Bit Klartext aus einem Block von Chiffretext ermöglicht, der mit dem damals standardmäßigen Standardverschlüsselungsmodus CBC verschlüsselt wurde. ^[35] ] Die einfachste s Lösung ist die Verwendung von CTR, Counter-Modus anstelle von CBC-Modus, da SSH dadurch resistent gegen den Angriff wird. ^[35]

Mögliche Schwachstellen [ edit

Am 28. Dezember 2014 Der Spiegel veröffentlichte Verschlusssachen ^[5] die von Whistleblower Edward Snowden durchgesickert wurden, was darauf hindeutet, dass die National Security Agency möglicherweise SSH-Datenverkehr entschlüsseln kann. Die technischen Details eines solchen Prozesses wurden nicht bekannt gegeben.

Eine Analyse der Hacking-Tools BothanSpy & Gyrfalcon aus dem Jahr 2017 deutete darauf hin, dass das SSH-Protokoll selbst nicht gefährdet war. ^[36]

Dokumentation zu Standards [

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

• RFC 4250, zugewiesene Nummern für das Secure Shell (SSH) -Protokoll
• RFC 4251, die Secure Shell (SSH) - Protokollarchitektur
• RFC 4252, Authentifizierungsprotokoll für Secure Shell (SSH)
• RFC 4253, The Secure Shell (SSH) -Transportschichtprotokoll
• RFC 4254, Das Secure Shell (SSH) -Verbindungsprotokoll
• RFC 4255, Verwendung von DNS zur sicheren Veröffentlichung von Secure Shell (SSH) -Schlüsselabdrücken
• RFC 4256, Generic Message Exchange Authentication für das Secure Shell Protocol (SSH)
• RFC 4335, Erweiterung der Secure Shell (SSH) -Sitzungsunterbrechung
• RFC 4344, Die Secure Shell (SSH) -Transportschichtverschlüsselungsmodi
• RFC 4345, Verbesserte Arcfour-Modi für das Secure Shell (SSH) -Transportschichtprotokoll

Es wurde später durch die folgenden Veröffentlichungen modifiziert und erweitert.

• RFC 4419, Diffie-Hellman-Gruppenaustausch für das Secure Shell (SSH) -Transportschichtprotokoll (März 2006)
• RFC 4432, RSA-Schlüsselaustausch für das Secure Shell (SSH) -Transportschichtprotokoll (März 2006) [19659058] RFC 4462, Generic Security Service Application Program Interface (GSS-API) Authentifizierung und Schlüsselaustausch für das Secure Shell (SSH) -Protokoll (Mai 2006)
• RFC 4716, Das Public-Key-Dateiformat von Secure Shell (SSH) (November 2006) )
• RFC 4819: Secure Shell-Public-Key-Subsystem (März 2007)
• RFC 5647: AES-Galois-Counter-Modus für das Secure Shell-Transportschichtprotokoll (August 2009)
• RFC 5656, Integration des elliptischen Kurvenalgorithmus im Secure Shell-Transportschicht (Dezember 2009)
• RFC 6187: X.509v3-Zertifikate für Secure Shell-Authentifizierung (März 2011)
• RFC 6239: Suite B-Verschlüsselungssuites für Secure Shell (SSH) (Mai 2011)
• RFC 6594 : Verwendung des SHA-256-Algorithmus mit RSA, Digital Signature Algorithm (DSA) und Elliptische Kurven-DSA (ECDSA) in SSHFP-Ressourcendatensätzen
• RFC 6668, SHA-2-Datenintegritätsüberprüfung für das Secure Shell (SSH) -Transportschichtprotokoll (Juli 2012)
• RFC 7479: Ed25519 SSHFP-Ressourcendatensätze

In Darüber hinaus enthält das OpenSSH-Projekt mehrere Herstellerprotokollspezifikationen / -erweiterungen:

Siehe auch [ edit ]

Referenzen edit

1. ^ Netzwerkarbeitsgruppe der IETF,   Januar 2006,   RFC 4251,   Die Secure Shell (SSH) -Protokollarchitektur
2. ^ ^{a b c} Netzwerkarbeitsgruppe der IETF   Januar 2006,   RFC 4252,   Das Secure Shell-Authentifizierungsprotokoll (SSH)
3. ^ "OpenSSH für Windows" . 8. Oktober 2018 .
4. ^ "SSH härtet die sichere Hülle". Serverwatch.com . Aus dem Original am 23. Dezember 2008 archiviert.
5. ^ ^{a b} "Neugierige Augen: Im Krieg der NSA gegen Internet-Sicherheit". Spiegel Online. 28. Dezember 2014. Aus dem Original am 24. Januar 2015 archiviert.
6. ^ "So richten Sie autorisierte Schlüssel ein". Archiviert aus dem Original am 2011-05-10.
7. ^ "Dienstnamen- und Transportprotokoll-Portnummernregistrierung". iana.org . Archiviert aus dem Original am 2001-06-04.
8. ^ "Laden Sie PuTTY herunter - einen kostenlosen SSH- und Telnet-Client für Windows". Putty.org. Archiviert aus dem Original am 2014-05-27 . 2014-04-28 .
9. ^ "Cygwin-Paketliste" . Abgerufen 5. Januar 2016 .
10. ^ "WinSCP-Startseite". Archiviert aus dem Original am 17.02.2014.
11. ^ "WinSCP-Seite für PortableApps.com". Archiviert aus dem Original am 2014-02-16.
12. ^ "PuTTY-Seite für PortableApps.com". Aus dem Original am 2014-02-16 archiviert.
13. ^ Amies, A; Wu, CF; Wang, G C; Criveti, M (2012). "Vernetzung in der Cloud". IBM developerWorks . Archiviert aus dem Original am 14.06.2013.
14. ^ Tatu Ylönen. Msgstr "Der neue Schlüssel: Die Sperren in Ihrer Netzwerkumgebung ändern". Archiviert aus dem Original am 2017-08-20.
15. ^ Tatu Ylönen. "SSH-Port". Archiviert aus dem Original am 03.08.2017.
16. ^ Nicholas Rosasco und David Larochelle. "Wie und warum sicherere Technologien in Altmärkten erfolgreich sind: Lehren aus dem Erfolg von SSH" (PDF) . Zitieren von Barrett und Silverman, SSH, Secure Shell: The Definitive Guide, O'Reilly & Associates (2001) . Fachbereich Informatik, Univ. von Virginia. Archiviert (PDF) vom Original am 25.06.2006 . 2006-05-19 .
17. ^ "Secsh Protocol Documents". VanDyke Software, Inc. . Archiviert aus dem Original am 13.01.2010.
18. ^ "SSH - Häufig gestellte Fragen". Archiviert aus dem Original am 10.10.2004.
19. ^ "libssh".
20. ^ "Eine GNU-Implementierung der Secure Shell-Protokolle". Archiviert aus dem Original am 04.02.2012.
21. ^ "Dropbear SSH". Archiviert aus dem Original am 14.10.2011.
22. ^ "RFC 4253". Abschnitt 5. Kompatibilität mit alten SSH-Versionen. Archivierung aus dem Original am 04.07.2010 IETF
23. ^ "OpenSSH: Projektgeschichte und Danksagungen". openssh.com. 2004-12-22. Archiviert aus dem Original am 24.12.2013 . 2014-04-27 .
24. ^ "OSSH-Informationen für VU # 419241". Archiviert aus dem Original am 2007-09-27.
25. ^ Sobell, Mark (2012). Ein praktischer Leitfaden für Linux-Befehle, Editoren und Shell-Programmierung (3. Ausgabe) . Oberer Sattelfluß, New Jersey: Prentice Hall. S. 702–704. ISBN 978-0133085044.
26. ^ Seggelmann, R .; Tuxen, M .; Rathgeb, E.P. (18. bis 20. Juli 2012). "SSH über SCTP - Optimierung eines Mehrkanalprotokolls durch Anpassung an SCTP". Kommunikationssysteme, Netzwerke und digitale Signalverarbeitung (CSNDSP), 8. 8. Internationales Symposium am : 1–6. Doi: 10.1109 / CSNDSP.2012.6292659. ISBN 978-1-4577-1473-3.
27. ^ ^{a b} Stebila, D .; Green J. (Dezember 2009). "RFC5656 - Integration elliptischer Kurvenalgorithmen in der Secure Shell Transport Layer". Nach dem Original am 19. Juli 2012 archiviert . 12. November 2012 .
28. ^ Miller, D .; Valchev, P. (3. September 2007). "Die Verwendung von UMAC im SSH-Transportschichtprotokoll / draft-miller-secsh-umac-00.txt". Nach dem Original am 19. August 2014 archiviert . 12. November 2012 .
29. ^ "SSH Insertion Attack". Kernsicherheitstechnologien . Archiviert aus dem Original am 2011-07-08.
30. ^ "Hinweis zur Sicherheitsanfälligkeit VU # 13877 - Schwaches CRC ermöglicht Paketinjektion in SSH-Sitzungen, die mit Blockchiffren verschlüsselt sind". US CERT . Archiviert aus dem Original am 2010-07-10.
31. ^ "Sicherheitsanfälligkeit bezüglich Kompensationsangriffen durch SSH-CRC-32". SecurityFocus . Aus dem Original am 2008-07-25 archiviert.
32. ^ "Hinweis zur Sicherheitsanfälligkeit VU # 945216 - SSH CRC32-Angriffserkennungscode enthält Remote Integer-Überlauf". US CERT . Archiviert aus dem Original am 2005-10-13.
33. ^ "Hinweis zur Sicherheitsanfälligkeit VU # 315308 - Durch das schwache CRC kann der letzte Block eines IDEA-verschlüsselten SSH-Pakets ohne Vorankündigung geändert werden". US CERT . Archiviert aus dem Original am 11. Juli 2010.
34. ^ "Hinweis zur Sicherheitsanfälligkeit Mit VU # 684820 - SSH-1 kann die Clientauthentifizierung von einem böswilligen Server an einen anderen Server weitergeleitet werden". US CERT . Aus dem Original am 2009-09-01 archiviert.
35. ^ ^{a b} "Vulnerability Note VU # 958563 - SSH CBC Vulnerability". US CERT . Archiviert aus dem Original am 22.06.2011.
36. ^ Tatu Ylonen. "BothanSpy & Gyrfalcon - Analyse von CIA-Hacking-Tools für SSH", ssh.com, 3. August 2017. Abgerufen am 15. Juli 2018.

Weiterführende Literatur [

Externe Links [ bearbeiten ]

Wikimedia Commons hat Medien im Zusammenhang mit SSH .