Sicher ist Shell (SSH) ein Netzprotokoll für sichere Datenkommunikation, entfernte Schale-Dienstleistungen oder Befehl-Ausführung und andere sichere Netzdienste zwischen zwei vernetzten Computern, die es über einen sicheren Kanal über ein unsicheres Netz verbindet: ein Server und ein Kunde (SSH Server und SSH Kundenprogramme, beziehungsweise führend). Die Protokoll-Spezifizierung unterscheidet zwei Hauptversionen, die SSH-1 und SSH-2 genannt werden.

Die am besten bekannte Anwendung des Protokolls ist für den Zugang, um Rechnungen auf Unix ähnlichen Betriebssystemen zu schälen. Es wurde als ein Ersatz für Telnet und andere unsichere entfernte Schale-Protokolle wie der Berkeley rsh und die rexec Protokolle entworfen, die Information, namentlich Kennwörter in plaintext senden, sie empfindlich gegen das Auffangen und die Enthüllung mit der Paket-Analyse machend. Die durch SSH verwendete Verschlüsselung ist beabsichtigt, um Vertraulichkeit und Integrität von Daten über ein ungesichertes Netz wie das Internet zur Verfügung zu stellen.

Definition

SSH verwendet Geheimschrift des öffentlichen Schlüssels, um den entfernten Computer zu beglaubigen und ihm zu erlauben, den Benutzer nötigenfalls zu beglaubigen. Jeder kann ein zusammenpassendes Paar von verschiedenen Schlüsseln (öffentlich und privat) erzeugen. Der öffentliche Schlüssel wird auf allen Computern gelegt, die Zugang dem Eigentümer des zusammenpassenden privaten Schlüssels erlauben müssen (der Eigentümer behält das private Schlüsselgeheimnis). Während Beglaubigung auf dem privaten Schlüssel basiert, wird der Schlüssel selbst durch das Netz während der Beglaubigung nie übertragen.

SSH prüft nur nach, ob dieselbe Person, die den öffentlichen Schlüssel auch anbietet, den zusammenpassenden privaten Schlüssel besitzt. Folglich in allen Versionen von SSH ist es wichtig, unbekannte öffentliche Schlüssel nachzuprüfen, d. h. die öffentlichen Schlüssel mit der Identität, vor dem Annehmen von ihnen als gültig zu vereinigen. Das Annehmen eines öffentlichen Schlüssels eines Angreifers ohne Gültigkeitserklärung wird einen nicht bevollmächtigten Angreifer als ein gültiger Benutzer autorisieren.

Schlüsselmanagement

Auf Unix ähnlichen Systemen wird die Liste von autorisierten Schlüsseln in der Hausmappe des Benutzers versorgt, dem erlaubt wird, in entfernt, in der Datei ~/.ssh/authorized_keys zu loggen. Diese Datei wird nur durch ssh respektiert, wenn es nicht writable durch irgendetwas abgesondert vom Eigentümer und der Wurzel ist. Wenn der öffentliche Schlüssel auf einer Seite da ist und der zusammenpassende private Schlüssel auf einer anderen Seite da ist, im Kennwort tippend, ist nicht mehr erforderlich (eine Software wie MPI-Stapel kann diesen Zugang des Kennwortes weniger brauchen, um richtig zu laufen). Jedoch für die zusätzliche Sicherheit kann der private Schlüssel selbst mit einem passphrase geschlossen werden.

Der private Schlüssel kann auch in Standardplätzen gesucht werden, aber sein voller Pfad kann auch als eine Befehl-Linieneinstellung (der Schalter-i für ssh) angegeben werden. Das ssh-keygen Dienstprogramm erzeugt die öffentlichen und privaten Schlüssel immer in Paaren.

SSH unterstützt auch Kennwort-basierte Beglaubigung, die encrypted durch automatisch erzeugte Schlüssel ist. In diesem Fall konnte der Angreifer die legitime Seite imitieren, um das Kennwort bitten und es (Mann im mittleren Angriff) erhalten. Jedoch ist das nur möglich, wenn die zwei Seiten vorher nie beglaubigt haben, weil sich SSH an den Schlüssel erinnert, den die entfernte Seite einmal verwendet hat. Kennwort-Beglaubigung kann arbeitsunfähig sein.

Gebrauch

SSH wird normalerweise verwendet, um in eine entfernte Maschine zu loggen und Befehle durchzuführen, aber er unterstützt auch tunneling, TCP Häfen und X11 Verbindungen nachschickend; es kann Dateien mit der verbundenen SSH Dateiübertragung (SFTP) übertragen oder Kopie (SCP) Protokolle sichern. SSH verwendet das Client/Server-Modell.

Der TCP Standardhafen 22 ist zugeteilt worden, um sich mit SSH Servern in Verbindung zu setzen, obwohl Verwalter ihn oft zu einem Sonderhafen als eine zusätzliche Sicherheitsmaßnahme ändern.

Ein SSH Kundenprogramm wird normalerweise verwendet, um Verbindungen mit einem SSH Dämon herzustellen, der Fernverbindungen akzeptiert. Beide sind allgemein auf den meisten modernen Betriebssystemen, einschließlich Mac OS X, dem grössten Teil des Vertriebs von GNU/Linux, OpenBSD, FreeBSD, Solaris und OpenVMS anwesend. Eigentums-bestehen freeware und offene Quellversionen von verschiedenen Niveaus der Kompliziertheit und Vollständigkeit.

Geschichte und Entwicklung

Version 1.x

1995 hat Tatu Ylönen, ein Forscher an der Helsinkier Universität der Technologie, Finnland, entwickelt die erste Version des Protokolls (hat jetzt SSH-1 genannt) veranlasst durch einen an Kennwort schnuppernden Angriff an seinem Universitätsnetz. Die Absicht von SSH war, früher rlogin, TELNET und rsh Protokolle zu ersetzen, die starke Beglaubigung nicht zur Verfügung gestellt noch Vertraulichkeit versichert haben. Ylönen hat seine Durchführung als freeware im Juli 1995, und das in der Beliebtheit schnell gewonnene Werkzeug veröffentlicht. Zum Ende von 1995 war die SSH Benutzerbasis 20,000 Benutzern in fünfzig Ländern gewachsen.

Im Dezember 1995 hat Ylönen SSH Kommunikationssicherheit gegründet, SSH auf den Markt zu bringen und zu entwickeln. Die ursprüngliche Version der SSH Software hat verschiedene Stücke der kostenlosen Software, wie GNU libgmp, aber spätere Versionen verwendet, die durch SSH Sichere in die immer Mehreigentumssoftware entwickelte Kommunikationen veröffentlicht sind.

Es wird geschätzt, dass, es 2 Millionen Benutzer von SSH gab.

Bemerkenswerte Verwundbarkeit

1998 wurde eine Verwundbarkeit in SSH 1.5 beschrieben, der die unerlaubte Einfügung des Inhalts in einen encrypted SSH Strom wegen des ungenügenden Datenintegritätsschutzes vor in dieser Version des Protokolls verwendetem CRC-32 erlaubt hat. Eine als SSH Entschädigungsangriffsentdecker bekannte üble Lage wurde in die meisten Durchführungen eingeführt. Viele dieser aktualisierten Durchführungen haben eine neue Überschwemmungsverwundbarkeit der ganzen Zahl enthalten, die Angreifern erlaubt hat, willkürlichen Code mit den Vorzügen des SSH Dämons durchzuführen, normalerweise einzuwurzeln.

Im Januar 2001 wurde eine Verwundbarkeit entdeckt, der Angreifern erlaubt, den letzten Block einer Sitzung der IDEE-ENCRYPTED zu modifizieren. Derselbe Monat wurde eine andere Verwundbarkeit entdeckt, der einem böswilligen Server erlaubt hat, eine Kundenbeglaubigung zu einem anderen Server nachzuschicken.

Da SSH-1 innewohnende Designfehler hat, die ihn verwundbar machen, wird es jetzt allgemein veraltet betrachtet und sollte vermieden werden, indem es Rückgriff zu SSH-1 ausführlich unbrauchbar gemacht wird. Die meisten modernen Server und Kunden unterstützen SSH-2.

Version 1.99

Im Januar 2006, ganz nachdem Version 2.1 gegründet wurde, hat RFC 4253 angegeben, dass ein SSH Server, der sowohl 2.0 als auch vorherige Versionen von SSH unterstützt, seinen protoversion als 1.99 identifizieren sollte. Das ist nicht eine wirkliche Version, aber eine Methode, rückwärts gerichtete Vereinbarkeit zu identifizieren.

OpenSSH und OSSH

1999 sind Entwickler, die eine Version der kostenlosen Software wollen verfügbar sein, zurück zur älteren 1.2.12 Ausgabe des ursprünglichen SSH Programms gegangen, das das laut einer offenen Quelllizenz veröffentlichte letzte war. Der OSSH von Björn Grönvall wurde nachher von diesem codebase entwickelt. Kurz danach haben Entwickler von OpenBSD den Code von Grönvall gegabelt und haben umfassende Arbeit daran getan, OpenSSH schaffend, der sich mit der 2.6 Ausgabe von OpenBSD eingeschifft hat. Von dieser Version wurde ein "Beweglichkeits"-Zweig gebildet, um OpenSSH zu anderen Betriebssystemen zu tragen., OpenSSH war die einzelne populärste SSH Durchführung, standardmäßig in einer Vielzahl von Betriebssystemen kommend. OSSH ist inzwischen veraltet geworden. OpenSSH setzt fort, unterstützt zu werden, und unterstützt jetzt sowohl 1.x als auch 2.0 Versionen.

Version 2.x

"Secsh" war der Name der offiziellen Internet Engineering Task Force (IETF) für die IETF für die Version 2 des SSH Protokolls verantwortliche Arbeitsgruppe. 2006 wurde eine revidierte Version des Protokolls, SSH-2, als ein Standard angenommen. Diese Version ist mit SSH-1 unvereinbar. SSH-2 zeigt sowohl Sicherheit als auch Eigenschaft-Verbesserungen über SSH-1. Bessere Sicherheit kommt zum Beispiel durch Diffie-Hellman Schlüsselaustausch und starke Integritätsüberprüfung über Nachrichtenbeglaubigungscodes durch. Neue Eigenschaften von SSH-2 schließen die Fähigkeit ein, jede Zahl von Schale-Sitzungen über eine einzelne SSH Verbindung zu führen. Wegen der Überlegenheit von SSH-2 und Beliebtheit über SSH-1, einige Durchführungen wie Lsh und Dropbear, SSH-2 Protokoll der nur Unterstützung.

Verwundbarkeit

Im November 2008 wurde eine Verwundbarkeit für alle Versionen von SSH entdeckt, der Wiederherstellung von bis zu 32 Bit von plaintext von einem Block von ciphertext erlaubt hat, der das Encrypted-Verwenden war, was dann die Standardverzug-Verschlüsselungsweise, CBC war.

Internetstandarddokumentation

Die folgenden RFC Veröffentlichungen durch den IETF "secsh" Arbeitsgruppe-Dokument SSH-2 als ein vorgeschlagener Internetstandard.

• RFC 4250, Sicherer Shell (SSH) Protokoll Zugeteilte Zahlen
• RFC 4251, Sicherer Shell (SSH) Protokoll-Architektur
• RFC 4252, Sicherer Shell (SSH) Beglaubigungsprotokoll
• RFC 4253, Sicherer Shell (SSH) Transportschicht-Protokoll
• RFC 4254, Sicherer Shell (SSH) Verbindungsprotokoll
• RFC 4255, mit DNS, um Sicheren Shell (SSH) Schlüsselfingerabdrücke Sicher Zu veröffentlichen
• RFC 4256, Allgemeine Nachrichtenaustauschbeglaubigung für das Sichere Protokoll von Shell (SSH)
• RFC 4335, Sicherer Shell (SSH) Sitzungskanalbrechungserweiterung
• RFC 4344, Sicherer Shell (SSH) Transportschicht-Verschlüsselungsweisen
• RFC 4345, Verbesserte Arcfour Weisen für Sicheren Shell (SSH) Transportschicht-Protokoll

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

• RFC 4419, Austausch von Diffie-Hellman Group für Sicheren Shell (SSH) Transportschicht-Protokoll (März 2006)
• RFC 4432, RSA Schlüsselaustausch für Sicheren Shell (SSH) Transportschicht-Protokoll (März 2006)
• RFC 4462, Allgemeine Sicherheitsdienstanwendungsprogramm-Schnittstelle (GSS-API) Beglaubigung und Schlüsselaustausch für Sicheren Shell (SSH) Protokoll (Mai 2006)
• RFC 4716, Sicherer Shell (SSH) Publikum-Schlüsseldateiformat (November 2006)
• RFC 5656, Elliptische Kurve-Algorithmus-Integration in der Sicheren Transportschicht von Shell (Dezember 2009)

Gebrauch

SSH ist ein Protokoll, das für viele Anwendungen über viele Plattformen einschließlich der meisten Varianten von Unix (Linux, Der BSD'S, & Solaris), Windows von Microsoft verwendet werden kann, und OS X. Some des Apfels der Anwendungen unten Eigenschaften verlangen kann, die nur verfügbar oder mit spezifischen SSH Kunden oder Servern vereinbar sind. Zum Beispiel ist das Verwenden des SSH Protokolls, um einen VPN durchzuführen, aber jetzt nur mit dem Server von OpenSSH und der Kundendurchführung möglich.

• Für die Anmeldung zu einer Schale auf einem entfernten Gastgeber (Telnet und rlogin ersetzend)

,

• Für einen einzelnen Befehl auf einem entfernten Gastgeber durchzuführen (rsh ersetzend)

,

• Sichere Dateiübertragung
• In der Kombination mit rsync, um zu unterstützen, kopieren Sie und Spiegeldateien effizient und sicher
• Für den Versand oder tunneling ein Hafen (um mit einem VPN, der Weg-Pakete zwischen verschiedenen Netzen oder Brücken zwei Sendungsgebiete in ein nicht verwirrt zu sein).
• Um als ein flügger encrypted VPN zu verwenden. Bemerken Sie, dass nur Server von OpenSSH und Kunde diese Eigenschaft unterstützen.
• Um X von einem entfernten Gastgeber (möglich durch vielfache Zwischengastgeber) nachzuschicken
• Für das Web durch eine encrypted Proxyverbindung mit SSH Kunden zu durchsuchen, die das SOCKE-Protokoll unterstützen.
• Für ein Verzeichnis auf einem entfernten Server als ein filesystem auf einem lokalen Computer mit SSHFS sicher zu besteigen.
• Für die automatisierte entfernte Überwachung und das Management von Servern bis ein oder mehr von den Mechanismen, die oben besprochen sind.
• Für die Entwicklung auf einem beweglichen oder eingebetteten Gerät, das SSH unterstützt.

Dateiübertragungsprotokolle mit SSH

Es gibt vielfache Mechanismen, um Dateien mit den Sicheren Protokollen von Shell zu übertragen.

• Sichere Kopie (SCP), der sich aus dem RCP Protokoll über SSH entwickelt

hat

• rsync, beabsichtigt, um effizienter zu sein, als SCP
• SSH File Transfer Protocol (SFTP), eine sichere Alternative zu FTP (um mit FTP über SSH nicht verwirrt zu sein)

,

• Dateien haben über das Schale-Protokoll übergewechselt (a.k.a. FISCH), veröffentlicht 1998, der sich von Schale-Befehlen von Unix über SSH entwickelt

hat

Architektur

Das SSH-2 Protokoll hat eine innere Architektur (definiert in RFC 4251) mit gut getrennten Schichten. Diese sind:

• Die Transportschicht (RFC 4253). Diese Schicht behandelt anfänglichen Schlüsselaustausch sowie Server-Beglaubigung, und stellt Verschlüsselung, Kompression und Integritätsüberprüfung auf. Es stellt zur oberen Schicht eine Schnittstelle aus, um plaintext Pakete mit Größen von bis zu 32,768 Bytes jeder zu senden und zu erhalten (mehr kann durch die Durchführung erlaubt werden). Die Transportschicht trifft auch für Schlüsselrücktausch gewöhnlich Vorkehrungen, nachdem das 1 GB von Daten übertragen worden ist, oder nachdem 1 Stunde gegangen ist, welch auch immer eher ist.
• Die Benutzerbeglaubigungsschicht (RFC 4252). Diese Schicht behandelt Kundenbeglaubigung und stellt mehrere Beglaubigungsmethoden zur Verfügung. Beglaubigung wird kundengesteuert: Wenn einer für ein Kennwort veranlasst wird, kann es der SSH Kunde sein, der, nicht der Server veranlasst. Der Server antwortet bloß auf die Beglaubigungsbitten des Kunden. Weit verwendete Benutzerbeglaubigungsmethoden schließen den folgenden ein:
• Kennwort: Eine Methode für die aufrichtige Kennwort-Beglaubigung, einschließlich einer Möglichkeit, die ein Kennwort erlaubt, geändert zu werden. Diese Methode wird durch alle Programme nicht durchgeführt.
• publickey: Eine Methode für das Publikum schlüsselbasierte Beglaubigung, gewöhnlich mindestens DSA oder RSA keypairs mit anderen Durchführungen unterstützend, die auch X.509 Zertifikate unterstützen.
• mit der Tastatur interaktiv (RFC 4256): Eine vielseitige Methode, wohin der Server ein sendet oder veranlasst mehr, um in Information einzugehen, und der Kunde zeigt sie und sendet Antworten eingegeben - in durch den Benutzer zurück. Verwendet, um ehemalige Kennwort-Beglaubigung wie S/Key oder SecurID zur Verfügung zu stellen. Verwendet durch einige Konfigurationen von OpenSSH, wenn PAM der zu Grunde liegende Gastgeber-Beglaubigungsversorger ist, um Kennwort-Beglaubigung effektiv zur Verfügung zu stellen, manchmal zu Unfähigkeit führend, in mit einem Kunden zu loggen, der gerade die einfache Kennwort-Beglaubigungsmethode unterstützt.
• GSSAPI Beglaubigungsmethoden, die ein ausziehbares Schema zur Verfügung stellen, SSH Beglaubigung mit Außenmechanismen wie Kerberos 5 oder NTLM durchzuführen, einzelnes Zeichen auf der Fähigkeit zu SSH Sitzungen zur Verfügung stellend. Diese Methoden werden gewöhnlich durch kommerzielle SSH Durchführungen für den Gebrauch in Organisationen durchgeführt, obwohl OpenSSH wirklich ein Arbeiten GSSAPI Durchführung hat.
• Die Verbindungsschicht (RFC 4254). Diese Schicht definiert das Konzept von Kanälen, Kanalbitten und dem globalen Bitte-Verwenden, das SSH Dienstleistungen zur Verfügung gestellt werden. Eine einzelne SSH Verbindung kann vielfache Kanäle gleichzeitig, jeder veranstalten, Daten in beiden Richtungen übertragend. Kanalbitten werden verwendet, um Kanal aus dem Band spezifische Daten, wie die geänderte Größe eines Endfensters oder der Ausgangscode eines Prozesses der Server-Seite weiterzugeben. Der SSH Kunde bittet einen Hafen der Server-Seite, mit einer globalen Bitte nachgeschickt zu werden. Standardkanaltypen schließen ein:
• Schale für Endschalen, SFTP und Exec-Bitten (einschließlich SCP-Übertragungen)
• direkt-tcpip für den Kunden zum Server hat Verbindungen nachgeschickt
• nachgeschickt-tcpip für den Server zum Kunden hat Verbindungen nachgeschickt
• Der SSHFP DNS Aufzeichnung (RFC 4255) stellt die öffentlichen Gastgeber-Schlüsselfingerabdrücke zur Verfügung, um im Überprüfen der Echtheit des Gastgebers zu helfen.

Diese offene Architektur stellt beträchtliche Flexibilität zur Verfügung, SSH erlaubend, für eine Vielfalt von Zwecken außer einer sicheren Schale verwendet zu werden. Die Funktionalität der Transportschicht allein ist mit Transport Layer Security (TLS) vergleichbar; die Benutzerbeglaubigungsschicht ist mit kundenspezifischen Beglaubigungsmethoden hoch ausziehbar; und die Verbindungsschicht stellt die Fähigkeit zur Verfügung, viele sekundäre Sitzungen in eine einzelne SSH Verbindung, eine Eigenschaft gleichzeitig zu senden, die mit dem SIGNALTON vergleichbar ist und in TLS nicht verfügbar ist.

Erhöhungen

Diese sind für Leistungserhöhungen von SSH Produkten beabsichtigt:

• SSH-over-SCTP: Die Unterstützung für SCTP aber nicht TCP als die Verbindung hat Transportschicht-Protokoll orientiert.
• ECDSA: Unterstützung für die elliptische Kurve DSA aber nicht DSA oder RSA für das Unterzeichnen.
• ECDH: Unterstützung für die elliptische Kurve Diffie-Hellman aber nicht die Ebene Diffie-Hellman für den Verschlüsselungsschlüsselaustausch.
• UMAC: Unterstützung für UMAC aber nicht HMAC für MAC/integrity.

Siehe auch

• Ident
• Webbasierter SSH - Zugang zu SSH Servern durch Standard-WWW-Browser
• Autossh - ein Werkzeug, um eine unveränderliche SSH Verbindung aufrechtzuerhalten, es als notwendiger wiederanfangend
• Vergleich von SSH Kunden
• Vergleich von SSH Servern
• Korkenzieher - ein Werkzeug, das einem Benutzer ermöglicht, SSH über HTTPS Proxyserver zu führen
• Geheimschrift des öffentlichen Schlüssels

Weiterführende Literatur

• Daniel J. Barrett, Richard E. Silverman, und Robert G. Byrnes, SSH: Sicherer Shell (Der Endgültige Führer), O'Reilly 2005 (2. Ausgabe). Internationale Standardbuchnummer 0-596-00895-3
• Michael Stahnke, Pro OpenSSH, internationale 2005-Standardbuchnummer von Apress 1-59059-476-2

• Ursprüngliche Ansage von Ssh
• Himanshu Dwivedi; SSH, Wiley 2003 durchführend. Internationale Standardbuchnummer 978-0-471-45880-7

Links

• Die alte Einstiegsseite für IETF 'secsh' Arbeitsgruppe, die (für SSH-2) aufgehört hat
• SSH Protokolle