Secure Shell

Secure Shell oder SSH bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke.[1] 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.

SSH

Familie:

Internetprotokollfamilie

Einsatzgebiet:

Datenübertragung auf Anwendungsschicht,
Fernsteuerung von Computern

Port:

22/TCP, 22/UDP, 22/SCTP

SSH im TCP/IP-Protokollstapel:
Anwendung	SSH
Transport	TCP
Internet	IP (IPv4, IPv6)
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

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.[2] 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.[3] Die Protokollspezifikation wird in zwei Versionen unterschieden, bezeichnet als SSH-1 und SSH-2. SSH wurde ursprünglich hauptsächlich unter unixoiden Betriebssystemen eingesetzt, seit kurzem jedoch auch unter Microsoft Windows.[4][5]

Die IANA hat dem Protokoll den TCP-Port 22 und SCTP-Port 22 zugeordnet.[6]

Geschichte

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.

Nachdem einige Schwachstellen in der Integritätsprüfung von SSH-1 bekannt geworden waren, wurde 1996 mit SSH-2 eine überarbeitete Version des Protokolls entwickelt. Sie ist inkompatibel zu SSH-1. Dabei wurde unter anderem das Protokoll in verschiedene Einzelteile aufgegliedert und somit die Verwendung sicherer Verschlüsselungs- und Authentifikations-Algorithmen ermöglicht. Damit wurden die Schwachstellen von SSH-1 beseitigt.

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.

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.[7] 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 laut RFC 4250	Spezifikation
SFTP	sftp	draft-ietf-secsh-filexfer
SSH Public Key Subsystem	publickey	RFC 4819
SNMP	snmp	RFC 5592
Netconf	netconf	RFC 6242
SSH transport mapping for SYSLOG	syslog	draft-gerhards-syslog-transport-ssh-00.txt
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.[8][3] 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.[9]

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 Time-based One-time Password Algorithmus (TOTP) erfolgreich zur Anmeldung durchlaufen werden muss.[10][11]

Sicherheit

Die von SSH-1 verwendete Integritätsprüfung weist Schwachstellen auf, die es einem Angreifer ermöglichen, eine SSH-1-Sitzung auszuspähen. Daher sollte nur noch SSH-2 verwendet werden, das derzeit als sicher gilt.[12] Diese Version 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 SSHv1 als auch für SSHv2[13] existieren Tools, mit denen ein MitM Angriff durchgeführt werden kann.

Implementierungen

SSH-Implementierungen waren ursprünglich nur unter Unix verfügbar, mittlerweile wurden jedoch sowohl SSH-Server als auch Clients für andere Plattformen programmiert (siehe auch: Geschichte). Populär sind beispielsweise die SSH-Clients PuTTY (für Microsoft Windows und Unix sowie Symbian) sowie WinSCP. Unter Cygwin gibt es auch einen Sshd für Windows, der auf OpenSSH basiert. Damit kann man sich per SSH auf einer Windows-Maschine einloggen und bekommt dort eine Shell. Für skriptgesteuerte Aufgaben, zum Beispiel Datensicherung, ist dies ein mächtiges Werkzeug.

Mit OpenSSH existiert eine freie Implementierung von SSH, die mittlerweile einen sehr großen Verbreitungsgrad erreicht hat. Weitere freie Ausführungen sind dropbear oder lsh.

Weiterhin gibt es für Microsoft Windows die kostenlose SSH-Implementierung freeSSHd. Der SSH-Server lässt sich unter Windows als Dienst installieren. Die Benutzersteuerung unterstützt NT-Authentifizierung, somit kann man sich an einer Domäne anmelden. Noch umfangreicher ist der Bitvise SSH Server, welcher für den persönlichen und nichtkommerziellen Einsatz ebenfalls kostenlos zur Verfügung steht. Mit dem Windows 10 Fall Creators Update steht nun (zunächst in der Beta-Version) ein OpenSSH Server und Client als Feature-on-Demand in Windows 10 zu Verfügung.[14]

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
RFC 4251 - The Secure Shell (SSH) Protocol Architecture
RFC 4252 - The Secure Shell (SSH) Authentication Protocol
RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol
RFC 4254 - The Secure Shell (SSH) Connection Protocol
RFC 4255 - Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
RFC 4256 - Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
RFC 4335 - The Secure Shell (SSH) Session Channel Break Extension
RFC 4344 - The Secure Shell (SSH) Transport Layer Encryption Modes
RFC 4345 - Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol

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)
RFC 4432 - RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol (März 2006)
RFC 4462 - Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol (Mai 2006)
RFC 4716 - The 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 for the Secure Shell Transport Layer Protocol (August 2009)
RFC 5656 - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer (Dezember 2009)
RFC 6187 - X.509v3 Certificates for Secure Shell Authentication (März 2011)
RFC 6239 - Suite B Cryptographic Suites for Secure Shell (SSH) (Mai 2011)
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)
RFC 6668 - SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol (Juli 2012)
RFC 7479 - Ed25519 SSHFP Resource Records (März 2015)
RFC 5592 - Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) (Juni 2009)
RFC 6242 - Using the NETCONF Protocol over Secure Shell (SSH) (Juni 2011)
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:

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 978-0-596-00895-6.
Michael W. Lucas: SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys. CreateSpace Ind. Publ., 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) (englisch) – Seite der Arbeitsgruppe bei der IETF
OpenSSH – offizielle Startseite
SSH-MITM proxy server ssh mitm server for security audits supporting public key authentication, session hijacking and file manipulation

Einzelnachweise

T. Ylonen, C. Lonvick: RFC 4251. – The Secure Shell (SSH) Protocol Architecture. Januar 2006. (englisch).
SSH Hardens the Secure Shell.
T. Ylonen, C. Lonvick: RFC 4252. – The Secure Shell (SSH) Authentication Protocol. Januar 2006. (englisch).
Microsoft Docs OpenSSH in Windows.
OpenSSH for Windows.
Service Name and Transport Protocol Port Number Registry. Abgerufen am 27. Mai 2020.
Secure Shell (SSH) Protocol Parameters. IANA, abgerufen am 15. Juni 2020.
T. Ylonen, C. Lonvick: RFC 4253. – The Secure Shell (SSH) Transport Layer Protocol. Januar 2006. (englisch).
Crypto-Gram
Changelog OpenSSH 6.2
How To Set Up Multi-Factor Authentication for SSH on Ubuntu 16.04. Abgerufen am 9. März 2018.
Teil 4 – Verwendung von Secure Shell (SSH). (PDF) In: Technische Richtlinie TR-02102-4 | Kryptographische Verfahren: Empfehlungen und Schlüssellängen. Bundesamt für Sicherheit in der Informationstechnik, Januar 2020, abgerufen am 16. Juni 2020: „Die Verwendung von SSH-2 wird empfohlen.“
ssh-mitm/ssh-mitm. ssh mitm server for security audits supporting public key authentication, session hijacking and file manipulation, 17. Januar 2021, abgerufen am 18. Januar 2021.
Windows 10 OpenSSH als Feature-On-Demand. Microsoft, abgerufen am 2. Januar 2017.

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. The authors of the article are listed here. Additional terms may apply for the media files, click on images to show image meta data.

[rfc4251-1] T. Ylonen, C. Lonvick: RFC 4251. – The Secure Shell (SSH) Protocol Architecture. Januar 2006. (englisch).

[2] SSH Hardens the Secure Shell.

[rfc4252-3] T. Ylonen, C. Lonvick: RFC 4252. – The Secure Shell (SSH) Authentication Protocol. Januar 2006. (englisch).

[4] Microsoft Docs OpenSSH in Windows.

[5] OpenSSH for Windows.

[6] Service Name and Transport Protocol Port Number Registry. Abgerufen am 27. Mai 2020.

[7] Secure Shell (SSH) Protocol Parameters. IANA, abgerufen am 15. Juni 2020.

[8] T. Ylonen, C. Lonvick: RFC 4253. – The Secure Shell (SSH) Transport Layer Protocol. Januar 2006. (englisch).

[9] Crypto-Gram

[10] Changelog OpenSSH 6.2

[ocean1-11] How To Set Up Multi-Factor Authentication for SSH on Ubuntu 16.04. Abgerufen am 9. März 2018.

[12] Teil 4 – Verwendung von Secure Shell (SSH). (PDF) In: Technische Richtlinie TR-02102-4 | Kryptographische Verfahren: Empfehlungen und Schlüssellängen. Bundesamt für Sicherheit in der Informationstechnik, Januar 2020, abgerufen am 16. Juni 2020: „Die Verwendung von SSH-2 wird empfohlen.“

[13] ssh-mitm/ssh-mitm. ssh mitm server for security audits supporting public key authentication, session hijacking and file manipulation, 17. Januar 2021, abgerufen am 18. Januar 2021.

[14] Windows 10 OpenSSH als Feature-On-Demand. Microsoft, abgerufen am 2. Januar 2017.