丰胸按摩手法刺激沉睡双峰 按出C罩杯就这样轻松

SSH

Familie:	Internetprotokollfamilie
Einsatzgebiet:	Datenübertragung auf Anwendungsschicht, Fernsteuerung von Computern
Port:	22/TCP
SSH im TCP/IP-Protokollstapel: Anwendung SSH Transport TCP Internet IP (IPv4, IPv6) Netzzugang Ethernet Token Bus Token Ring FDDI …

百度 但事情超出想象——阿英感受到了持续不断的疼痛，她便拿起手机给小关打电话。

Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke. H?ufig wird es verwendet, um lokal eine entfernte Kommandozeile verfügbar zu machen, d. h., auf einer lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben, und die lokalen Tastatureingaben werden an den entfernten Rechner gesendet. Genutzt werden kann dies z. B. zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Servers. Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP.

Dabei dient SSH als Ersatz für andere, unsichere Methoden wie Telnet. Bei diesen werden alle Informationen, auch sensible wie etwa Passw?rter, im Klartext übertragen. Dies macht sie anf?llig für Man-in-the-Middle-Angriffe sowie einen Vertraulichkeitsverlust durch Packet Analyzer, die die Datenpakete mitschneiden. Die Verschlüsselungstechnik, die durch SSH genutzt wird, hat deshalb den Zweck, die Vertraulichkeit, Integrit?t und Authentizit?t von Daten, die über ein unsicheres Netzwerk (wie z. B. das Internet) gesendet werden, sicherzustellen.

SSH verwendet die Client–Server-Architektur. Eine SSH-Client-Anwendung verbindet sich also mit einem SSH-Server. Die Protokollspezifikation wird in zwei Versionen unterschieden, bezeichnet als SSH-1 und SSH-2. SSH war zuerst für unixoide Betriebssysteme verfügbar, sp?ter auch für Microsoft Windows.

Die IANA hat dem Protokoll den TCP-Port 22, UDP-Port 22 und SCTP-Port 22 zugeordnet.

Geschichte

Version 1

Die erste Version des Protokolls (jetzt SSH-1 genannt) wurde 1995 von Tatu Yl?nen als Reaktion auf die Nachfrage nach drop-in replacements für Berkeley Services unter Unix einschlie?lich der Befehle rsh (remote shell), rcp (remote copy) und rlogin (remote login) entwickelt. Er ver?ffentlichte seine Implementierung 1995 als Freeware, die daraufhin schnell an Popularit?t gewann; Ende des Jahres 1995 z?hlte man bereits 20.000 Benutzer in fünfzig L?ndern.

Im Dezember gründete Tatu Yl?nen die Firma SSH Communications Security, um SSH zu vermarkten und weiterzuentwickeln. Die Originalsoftware enthielt ursprünglich Open-Source-Quellcode, entwickelte sich aber im Laufe der Zeit immer mehr zu propriet?rer Software.

Version 2

Nachdem einige Schwachstellen in der Integrit?tsprüfung von SSH-1 bekannt geworden waren, wurde von einer Arbeitsgruppe der IETF die überarbeitete Version SSH-2 entwickelt. Die technische Implementierung von SSH-2 ist inkompatibel zu SSH-1 und wurde 2006 in einer Reihe von RFCs als Standard ver?ffentlicht. Das Protokoll bekam eine mehrstufige Architektur, in der verschiedene Aufgabenbereiche in separate Ebenen aufgeteilt wurden, n?mlich: Transport (SSH-TRANS), Authentifizierung (SSH-AUTH) und Verbindungsaufbau (SSH-CONNECT). Gleichzeitig wurden (zur Zeit der Entwicklung) aktuelle und sicherere Kryptographieverfahren wie Diffie-Hellman-Schlüsselaustausch, verbesserte Methoden zur Integrit?tsprüfung wie MD5 or SHA-1 oder st?rkere Verschlüsselungsmechanismen wie AES implementiert.

Jede der Architektur-Ebenen wurde zudem so strukturiert, dass alle konkret genutzten technischen Verfahren (z. B. Verfahren für Integrit?tsprüfung oder Verschlüsselung) zwischen Server und Client ausgehandelt werden. Hierbei wurde ein Namenssystem verwendet, das anders als bei SSH-1 es auch erlaubt Verfahren zu verhandeln, die nicht durch die IANA standardisiert sind.

Somit k?nnen in der Zukunft neu entwickelte Verfahren verwendet werden, ohne dass eine neue Version des SSH-Protokolls entwickelt werden muss. So wurde z. B. 2009 mit RFC-5656 vorgeschlagen, dass auch das Elliptic-Curve Verfahren ECDSA und Integrit?tsprüfung mittels SHA-2 von Server und Client unterstützt werden.

Vergleich von SSH-1 und SSH-2

Die folgende Tabelle zeigt eine übersicht der ?nderungen zwischen SSH-1 und SSH-2

Funktion	SSH-1	SSH-2
Architektur	Monolithisch.	3 Ebenen: SSH-TRANS, SSH-AUTH, SSH-CONN
Verwendete Verfahren	Teilweise statisch.	Verhandlungssache zwischen Client und Server.
Integrit?tsprüfung/Hashing	Nur CRC32.	Ursprünglich MD5, SHA-1, sp?ter auch SHA-2.
Authentifizierungsmethoden	Public-Key (DSA, RSA, OpenPGP), hostbasiert, Passwort.	Public-Key (nur RSA), RhostsRSA, Passwort, Rhosts, TIS, Kerberos.
Namensraum	Nur IANA	IANA und frei definierbare Namen (mit @-Zeichen).
Verschlüsselung	3-DES, BlowFish, Arcfour, ...	aes-ctr, aes-cbc, aes-gcm, chacha-poly, ...
übertragung von Dateien	SCP	SCP und SFTP.
Zertifizierung von Schlüsseln	Keine	SSH-2 eigenes Zertifikatsformat (SSL-?hnlich).
Periodische Neuverhandlung von Schlüsseln	Nicht verfügbar.	Verfügbar.

Freie und propriet?re Implementierungen

1998 wurde der SSH-Client PuTTY für Microsoft Windows unter einer Freien Lizenz ver?ffentlicht.

1999 wurde der Wunsch nach einer freien Implementierung von SSH laut, und aus der letzten freien Version der Originalimplementierung entwickelte sich das separate OpenSSH-Projekt. Sp?testens seit dieser Zeit existiert das SSH-Protokoll in zwei Varianten: Als Open-Source-Software (OpenSSH) und als propriet?re Software (Produktname: SSH Tectia), entwickelt und vertrieben von der Firma SSH Communications Security, also den Original-Entwicklern rund um Yl?nen.

2005, also zehn Jahre nach der Original-Entwicklung, ging die Firma SSH Communications Security mit der Generation 3 (SSH G3) an die ?ffentlichkeit. Diese Protokollversion unterstützt die Verwendung des umstrittenen propriet?ren Algorithmus CryptiCore. Die anderen, etablierten Verschlüsselungsalgorithmen werden weiterhin unterstützt. 2006 wurde dieses Protokoll (Version 2) von der IETF als Internetstandard vorgeschlagen. Eine Zertifizierung nach FIPS-Standard 140-2 besteht bereits l?nger.

Microsoft Windows stellt als Teil des Betriebssystems seit Ende 2017 einen SSH-Client und Server bereit, der Client ist standardm??ig enthalten.

Verwendung

Eine X11-Verbindung wird über SSH weitergeleitet

SSH erm?glicht eine sichere, authentifizierte und verschlüsselte Verbindung zwischen zwei Rechnern über ein unsicheres Netzwerk. Dadurch dient es unter anderem als Ersatz für die Vorg?nger rlogin, telnet und rsh; diese übertragen jeglichen Netzverkehr, darunter auch die Passw?rter, unverschlüsselt.

Das ursprüngliche Anwendungsgebiet ist das Anmelden an entfernten Rechnern über ein Netzwerk (meistens das Internet), doch insbesondere SSH-2 ist nicht nur auf Terminalfunktionen beschr?nkt.

• SFTP und SCP bieten kryptographisch sicherere Alternativen zu FTP und RCP.
• X11 kann über SSH transportiert und somit gesichert werden.
• über SSH k?nnen beliebige TCP/IP-Verbindungen getunnelt werden (Portweiterleitung); dabei wird jeweils ein einzelner Port von einem entfernten Server auf den Client weitergeleitet oder umgekehrt. So kann etwa eine ansonsten unverschlüsselte VNC-Verbindung abgesichert werden.
• Ein SSH-Client kann sich wie ein SOCKS-Server verhalten und erm?glicht somit einen automatisierten Zugriff auf entfernte Rechner durch den SSH-Tunnel, etwa zum Umgehen einer Firewall.
• über SSHFS kann ein entferntes Dateisystem auf dem lokalen Rechner gemountet werden.
• Mit ?ssh-keyscan“ kann der ?ffentliche Schlüssel eines entfernten Rechners ausgelesen werden. Damit kann man unter Zuhilfenahme des zugeh?rigen ?ffentlichen Schlüssels zum Beispiel feststellen, ob die IP-Adresse und/oder der DNS-Eintrag eines SSH-Servers manipuliert worden ist.

Wahlweise kann die Verbindung auch komprimiert werden, um die Datenübertragung zu beschleunigen und Bandbreite zu sparen.

Damit lassen sich nun grunds?tzlich mehrere Anwendungsszenarien darstellen:

Secure System Administration (Sichere Systemverwaltung)

zur Absicherung der Fernverwaltung von Servern. Ersetzt telnet, rlogin etc.

Secure Application Tunneling (Sicheres Tunneln)

zum transparenten Schutz TCP/IP-basierender Anwendungen als ?End-to-End-Security“.

Secure Remote Command Execution (Sichere Ausführung von Kommandos)

zur Ausführung einzelner Kommandos auf einem anderen Rechner. Dabei werden stdin, stdout und stderr transparent weitergeleitet. Sonderfall davon:

Secure Subsystem Execution (Sichere Ausführung von Subsystemen)

zur Ausführung von auf dem Server vordefinierter Kommandos, wobei stderr jedoch nicht weitergeleitet wird.
Beispiel: Secure File Transfer (Sicherer Dateitransfer)
zur Herstellung sicherer, automatisierter und interaktiver Dateitransfers.

Anmerkung: SSH kann auch über mehrere Stationen laufen.

Subsysteme

Im Fall von Secure Subsystem Execution k?nnen Subsysteme, die in einer SSH-Serverinstallation definiert wurden, aus der Ferne ausgeführt werden, ohne den genauen Pfad des auf dem Server auszuführenden Programms zu kennen. SFTP ist das g?ngigste Subsystem.

In den einschl?gigen RFCs sind jedoch noch mehrere solcher Subsysteme definiert. Jeder Administrator kann darüber hinaus seine eigenen Subsysteme definieren; dabei sollte im Falle von nicht IANA-registrierten Subsystemen die Conventions for Names eingehalten werden (Stichwort @-Syntax).

Dienst	SSH Connection Protocol Subsystem Name	Spezifikation
SFTP	sftp	IETF-Draft
SSH Public Key Subsystem	publickey	RFC 4819
SNMP	snmp	RFC 5592
Netconf	netconf	RFC 6242
SSH transport mapping for SYSLOG	syslog	IETF-Draft
Powershell	powershell	SSH Remoting in PowerShell

Funktionsweise

Sicherung der Transportschicht

Noch vor einer Authentifizierung des Clients wird für die Dauer der Sitzung ein geheimer Schlüssel zwischen Server und Client ausgehandelt, mit dem die gesamte nachfolgende Kommunikation verschlüsselt wird. Dabei identifiziert sich zun?chst der Server dem Client gegenüber mit einem RSA-, DSA- oder ECDSA-Zertifikat, wodurch Manipulationen im Netzwerk erkannt werden k?nnen (kein anderer kann sich als ein bekannter Server ausgeben). Für die eigentliche Verschlüsselung der Verbindung werden bei SSH-2 AES, 3DES, Blowfish, Twofish und andere symmetrische Verschlüsselungsverfahren verwendet. Sofern von beiden Seiten unterstützt, wird unter bestimmten Voraussetzungen (z. B. übertragene Datenmenge, verstrichene Zeit) wieder ein neuer Schlüssel ausgehandelt, um einen Angriff auf die Sicherung der Transportschicht zu erschweren. Die Version SSH G3 unterstützt auch den propriet?ren Algorithmus CryptiCore, der laut Hersteller einen Geschwindigkeitsgewinn bietet, dessen Sicherheit allerdings vom Kryptoexperten Bruce Schneier bezweifelt wird.

Authentifizierung

Nach erfolgter Sicherung der Transportschicht kann sich der Client unter anderem per Public-Key-Authentifizierung mit einem privaten Schlüssel, dessen ?ffentlicher Schlüssel auf dem Server hinterlegt wurde, oder einem gew?hnlichen Kennwort authentisieren. W?hrend Letzteres in der Regel eine Benutzerinteraktion erfordert, erm?glicht die Public-Key-Authentifizierung, dass sich Client-Computer auch ohne Benutzerinteraktion auf SSH-Servern einloggen k?nnen, ohne dass dabei ein Passwort auf dem Client im Klartext gespeichert werden muss. Zur weiteren Absicherung k?nnen die privaten SSH-Schlüssel mit einem Passwort geschützt werden. Neuere Versionen des OpenSSH-Servers unterstützen mit verschiedenen Konfigurationsm?glichkeiten die Zwei-Faktor-Authentisierung oder auch eine Multi-Faktor-Authentisierung, bei der eine Kombination unterstützter Authentisierungsverfahren wie beispielsweise eine Kennwortangabe in Kombination mit dem Verfahren Time-based one-time password (TOTP) erfolgreich zur Anmeldung durchlaufen werden muss.

Sicherheit

Der Einsatz von SSH-1 wird nicht mehr empfohlen, da diese Protokollversion kryptographische Schw?chen aufweist, daher sollte SSH-2 verwendet werden. SSH-2 zeichnet sich durch modularen Aufbau der Transport-, Autorisierungs- und Verbindungsschichten aus und erm?glicht im Gegensatz zu SSH-1 die Verwendung von verschiedenen Verschlüsselungsalgorithmen.

Verbindet sich ein Client zum ersten Mal mit einem Server, wird ein sogenannter Fingerprint des ?ffentlichen Schlüssels angezeigt. Wird dieser Fingerprint akzeptiert, gilt er als vertrauenswürdig und in Zukunft wird bei einem abweichenden Fingerprint darauf hingewiesen, dass die Verbindung nicht vertrauenswürdig ist. Dieses Prinzip nennt man auch ?Trust on first use“. Genau hier ist es jedoch m?glich, mit einem Man-in-the-Middle-Angriff anzusetzen, weil der Fingerprint noch nicht bekannt ist. Sowohl für SSH-1 als auch für SSH-2 existieren Tools, mit denen ein MitM-Angriff durchgeführt werden kann.

Implementierungen

SSH-Implementierungen waren ursprünglich nur unter Unix verfügbar. Mittlerweile wurden sowohl SSH-Server als auch Clients für andere Plattformen programmiert (siehe auch: Geschichte). Als Clients sind beispielsweise OpenSSH (für Microsoft Windows, Linux und andere Plattformen), der SSH-Client PuTTY (für Windows und Linux sowie Symbian) popul?r, sowie das Dateiübertragungsprogramm WinSCP.

Serverseitig dominiert OpenSSH, das für nahezu alle Plattformen verfügbar ist. Diese existiert auch unter Cygwin. Seit 2016 gibt es auch eine nativen Portierung für Windows.

Mit dem Windows 10 Fall Creators Update steht (zun?chst in der Beta-Version) ein OpenSSH Server und Client als Feature-on-Demand direkt in Windows 10 zur Verfügung.

Diese erlauben es (in Kombination mit einem SSH Client), sich per SSH auf einem Windows-Rechner einzuloggen und eine Shell zu bedienen. Für skriptgesteuerte Aufgaben, zum Beispiel Datensicherung, ist dies ein m?chtiges Werkzeug.

Die SSH Communications Security bietet mit dem SSH Tectia Client/Server eine kommerzielle SSH-Implementierung an, die eine Authentisierung mittels Smartcards und USB-Tokens (PKCS#11) sowie X.509-v3-Zertifikaten erm?glicht. Auch OpenSSH kann Smartcards verwenden.

Normen und Standards

SSH ist durch die nachfolgenden RFCs, welche durch die IETF “secsh” Arbeitsgruppe als Internet-Standard vorgeschlagen wurden, standardisiert:

• RFC: 4250 – The Secure Shell (SSH) Protocol Assigned Numbers. (englisch).
• RFC: 4251 – The Secure Shell (SSH) Protocol Architecture. (englisch).
• RFC: 4252 – The Secure Shell (SSH) Authentication Protocol. (englisch).
• RFC: 4253 – The Secure Shell (SSH) Transport Layer Protocol. (englisch).
• RFC: 4254 – The Secure Shell (SSH) Connection Protocol. (englisch).
• RFC: 4255 – Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints. (englisch).
• RFC: 4256 – Generic Message Exchange Authentication for the Secure Shell Protocol (SSH). (englisch).
• RFC: 4335 – The Secure Shell (SSH) Session Channel Break Extension. (englisch).
• RFC: 4344 – The Secure Shell (SSH) Transport Layer Encryption Modes. (englisch).
• RFC: 4345 – Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol. (englisch).

Es wurde anschlie?end durch die folgenden RFCs modifiziert und erweitert:

• RFC: 4419 – Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol. M?rz 2006 (englisch).
• RFC: 4432 – RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol. M?rz 2006 (englisch).
• RFC: 4462 – Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol. Mai 2006 (englisch).
• RFC: 4716 – The Secure Shell (SSH) Public Key File Format. November 2006 (englisch).
• RFC: 4819 – Secure Shell Public Key Subsystem. M?rz 2007 (englisch).
• RFC: 5647 – AES Galois Counter Mode for the Secure Shell Transport Layer Protocol. August 2009 (englisch).
• RFC: 5656 – Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer. Dezember 2009 (englisch).
• RFC: 6187 – X.509v3 Certificates for Secure Shell Authentication. M?rz 2011 (englisch).
• RFC: 6239 – Suite B Cryptographic Suites for Secure Shell (SSH). Mai 2011 (englisch).
• RFC: 6594 – Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records. April 2012 (englisch).
• RFC: 6668 – SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol. Juli 2012 (englisch).
• RFC: 7479 – Ed25519 SSHFP Resource Records (M?rz 2015). (englisch).
• RFC: 5592 – Secure Shell Transport Model for the Simple Network Management Protocol (SNMP). Juni 2009 (englisch).
• RFC: 6242 – Using the NETCONF Protocol over Secure Shell (SSH). Juni 2011 (englisch).
• draft-gerhards-syslog-transport-ssh-00 – SSH transport mapping for SYSLOG (Juli 2006)
• draft-ietf-secsh-filexfer-13 – SSH File Transfer Protocol (Juli 2006)

Zus?tzlich enth?lt das OpenSSH-Projekt folgende herstellerspezifische Protokollspezifikationen und Erweiterungen:

• OpenSSH Protokoll übersicht
• OpenSSH certificate/key übersicht

Literatur

• Daniel J. Barrett, Richard E. Silverman, Robert G. Byrnes: SSH, the Secure Shell – The Definitive Guide. 2. Ausgabe. O’Reilly, Sebastopol CA 2005, ISBN 0-596-00895-3.
• Michael W. Lucas: SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys. CreateSpace, 2012, ISBN 978-1-4700-6971-1.

Weblinks

Commons: SSH – Sammlung von Bildern, Videos und Audiodateien

• ssh(1) – Debian GNU/Linux Ausführbare Programme oder Shell-Befehle Handbuchseite
• Secure Shell (secsh) – Seite der Arbeitsgruppe bei der IETF (englisch).
• OpenSSH – offizielle Startseite
• SSH-MITM proxy server ssh mitm server for security audits supporting public key authentication, session hijacking and file manipulation