Secure Shell

Grundidee und Aufbau

Secure Shell (SSH) ist ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke, insbesondere das Internet. Es dient vor allem dazu, von einem lokalen Rechner aus eine entfernte Kommandozeile sicher zu bedienen. Ausgaben des entfernten Rechners erscheinen lokal; Tastatureingaben werden an ihn übertragen. Ein typisches Einsatzgebiet ist die Fernwartung eines Servers in einem Rechenzentrum.

SSH arbeitet nach dem Client-Server-Prinzip: Eine SSH-Client-Anwendung verbindet sich mit einem SSH-Server. Das Protokoll gehört zur Anwendungsschicht und verwendet im TCP/IP-Protokollstapel gewöhnlich TCP über IP (IPv4 oder IPv6). Die IANA hat dafür TCP-Port 22, UDP-Port 22 und SCTP-Port 22 zugeordnet.

SSH ersetzt unsichere Verfahren wie Telnet, rlogin und rsh. Bei diesen werden auch Passwörter im Klartext übertragen. SSH soll dagegen die Vertraulichkeit, Integrität und Authentizität der übertragenen Daten sicherstellen. Vertraulichkeit bedeutet, dass Unbefugte den Inhalt nicht lesen können; Integrität, dass Veränderungen erkannt werden; Authentizität, dass die beteiligten Rechner beziehungsweise Benutzer überprüfbar sind.

Sichere Verbindung und Anmeldung

Noch vor der Authentifizierung des Clients handeln Server und Client für die Sitzung einen gemeinsamen geheimen Schlüssel aus. Mit diesem Schlüssel wird die anschließende Kommunikation verschlüsselt. Zunächst weist sich der Server gegenüber dem Client mit einem RSA-, DSA- oder ECDSA-Zertifikat aus. Dadurch sollen Manipulationen erkannt und verhindert werden, dass sich ein anderer Rechner als ein bekannter Server ausgibt.

Für die symmetrische Verschlüsselung, bei der beide Seiten denselben Sitzungsschlüssel verwenden, unterstützt SSH-2 unter anderem AES, 3DES, Blowfish und Twofish. Wenn beide Seiten dies unterstützen, kann während einer Sitzung abhängig etwa von übertragener Datenmenge oder vergangener Zeit ein neuer Schlüssel ausgehandelt werden. Diese regelmäßige Neuverhandlung erschwert Angriffe auf die Transportsicherung.

Nach der Sicherung der Transportschicht authentisiert sich der Client. Möglich sind unter anderem:

• Public-Key-Authentifizierung: Der Client besitzt einen privaten Schlüssel, während der zugehörige öffentliche Schlüssel auf dem Server hinterlegt ist.
• Anmeldung mit einem gewöhnlichen Kennwort.
• Weitere Verfahren, darunter bei neueren OpenSSH-Servern Zwei-Faktor- oder Multi-Faktor-Authentisierung. Dabei können beispielsweise ein Kennwort und ein zeitbasiertes Einmalpasswort (TOTP) kombiniert werden.

Private Schlüssel können zusätzlich mit einem Passwort geschützt werden. Public-Key-Authentifizierung erlaubt auch eine Anmeldung ohne Benutzerinteraktion, ohne dass ein Passwort im Klartext auf dem Client gespeichert werden muss.

Versionen und technische Entwicklung

Die erste Protokollversion, SSH-1, wurde 1995 von Tatu Ylönen als Ersatz für Berkeley-Dienste unter Unix entwickelt, darunter rsh, rcp und rlogin. Die zunächst als Freeware veröffentlichte Implementierung verbreitete sich schnell. Später entwickelte sich die ursprüngliche Software zunehmend zu proprietärer Software.

Wegen bekannt gewordener Schwachstellen in der Integritätsprüfung von SSH-1 entwickelte eine IETF-Arbeitsgruppe SSH-2. Diese Version ist technisch inkompatibel zu SSH-1 und wurde 2006 in einer Reihe von RFCs als Standard veröffentlicht. SSH-2 besitzt eine mehrstufige Architektur mit den Ebenen SSH-TRANS für den Transport, SSH-AUTH für die Authentifizierung und SSH-CONNECT für den Verbindungsaufbau.

Ein wesentlicher Unterschied besteht darin, dass SSH-1 teilweise statisch festgelegte Verfahren und eine monolithische Architektur verwendete. SSH-2 lässt Client und Server die konkret eingesetzten Verfahren aushandeln. Der Namensraum erlaubt neben IANA-standardisierten Namen auch frei definierbare Namen mit @-Zeichen. Dadurch können neue Verfahren ergänzt werden, ohne eine neue Protokollversion zu benötigen. 2009 wurde beispielsweise vorgeschlagen, ECDSA und Integritätsprüfung mit SHA-2 einzubinden.

Auch bei Integritätsprüfung, Verschlüsselung und Dateiübertragung gibt es Unterschiede: SSH-1 verwendete laut Vergleichsübersicht CRC32 und unter anderem 3-DES, Blowfish und Arcfour; SSH-2 ursprünglich MD5 und SHA-1, später auch SHA-2, sowie unter anderem aes-ctr, aes-cbc, aes-gcm und chacha-poly. Bei der Dateiübertragung unterstützt SSH-1 SCP, während SSH-2 SCP und SFTP bietet. SSH-2 ermöglicht außerdem periodische Schlüsselneuverhandlung und besitzt ein eigenes, SSL-ähnliches Zertifikatsformat.

Anwendungen und Subsysteme

Das ursprüngliche Einsatzgebiet von SSH ist die sichere Anmeldung an entfernten Rechnern. SSH-2 kann jedoch deutlich mehr:

• SFTP und SCP ermöglichen sicherere Alternativen zu FTP beziehungsweise RCP.
• X11-Verbindungen können über SSH weitergeleitet und dadurch geschützt werden.
• Beliebige TCP/IP-Verbindungen können durch Portweiterleitung getunnelt werden. So lässt sich beispielsweise eine ansonsten unverschlüsselte VNC-Verbindung absichern.
• Ein SSH-Client kann sich wie ein SOCKS-Server verhalten und Zugriffe durch den SSH-Tunnel ermöglichen, etwa zum Umgehen einer Firewall.
• Mit SSHFS kann ein entferntes Dateisystem auf dem lokalen Rechner eingebunden werden.
• Mit ssh-keyscan lässt sich der öffentliche Schlüssel eines entfernten Rechners auslesen. Zusammen mit diesem Schlüssel kann beispielsweise geprüft werden, ob die IP-Adresse oder der DNS-Eintrag eines SSH-Servers manipuliert wurde.

Eine Verbindung kann außerdem komprimiert werden, um Bandbreite zu sparen und die Übertragung zu beschleunigen. SSH kann über mehrere Stationen laufen.

Für die Anwendung unterscheidet der Artikel unter anderem sichere Systemverwaltung, sicheres Tunneln und die sichere Ausführung einzelner Kommandos. Bei der Secure Remote Command Execution werden stdin, stdout und stderr transparent weitergeleitet. Bei der Secure Subsystem Execution werden auf dem Server vordefinierte Kommandos ausgeführt; stderr wird dabei nicht weitergeleitet.

Subsysteme können aus der Ferne gestartet werden, ohne dass der genaue Programmpfad auf dem Server bekannt sein muss. Das verbreitetste Subsystem ist SFTP. Weitere definierte oder mögliche Subsysteme sind publickey, snmp, netconf, syslog und powershell. Administratoren können eigene Subsysteme definieren; für nicht bei der IANA registrierte Namen soll die @-Syntax eingehalten werden.

Sicherheit, Implementierungen und Standards

SSH-1 wird wegen kryptographischer Schwächen nicht mehr empfohlen; verwendet werden sollte SSH-2. Bei der ersten Verbindung zu einem Server zeigt der Client den Fingerprint des öffentlichen Schlüssels an. Ein Fingerprint ist ein kurzer Prüfwert, mit dem sich ein Schlüssel wiedererkennen lässt. Wird er akzeptiert, gilt er künftig als vertrauenswürdig. Weicht er später ab, warnt der Client vor einer möglicherweise nicht vertrauenswürdigen Verbindung. Dieses Verfahren heißt „Trust on first use“. Beim ersten Kontakt ist der Fingerprint jedoch noch nicht bekannt, sodass grundsätzlich ein Man-in-the-Middle-Angriff möglich ist. Für SSH-1 und SSH-2 existieren entsprechende Angriffswerkzeuge.

1998 erschien der freie SSH-Client PuTTY für Microsoft Windows. 1999 entstand aus der letzten freien Version der ursprünglichen Implementierung das OpenSSH-Projekt. Seitdem gibt es SSH als freie beziehungsweise Open-Source-Software, insbesondere OpenSSH, und als proprietäre Implementierung SSH Tectia von SSH Communications Security. 2005 veröffentlichte diese Firma SSH G3, das neben etablierten Verfahren auch den proprietären Algorithmus CryptiCore unterstützt; dessen Sicherheit wurde laut Artikel von Bruce Schneier bezweifelt. Seit Ende 2017 enthält Microsoft Windows standardmäßig einen SSH-Client und stellt auch einen SSH-Server bereit.

OpenSSH ist für nahezu alle Plattformen verfügbar und dominiert auf der Serverseite. Bekannte Clients sind OpenSSH, PuTTY und WinSCP. OpenSSH steht auch für Windows zur Verfügung, seit 2016 mit einer nativen Portierung. Mit dem Windows 10 Fall Creators Update wurden OpenSSH-Client und -Server zunächst als Beta-Feature-on-Demand angeboten. SSH Tectia unterstützt unter anderem Smartcards, USB-Tokens nach PKCS#11 und X.509-v3-Zertifikate; auch OpenSSH kann Smartcards verwenden.

Die Standardisierung von SSH erfolgt vor allem durch RFCs der IETF-secsh-Arbeitsgruppe. RFC 4250 bis RFC 4256 beschreiben unter anderem zugewiesene Nummern, Architektur, Authentifizierung, Transportschicht und Verbindungsprotokoll. Weitere RFCs ergänzen beispielsweise Diffie-Hellman Group Exchange, RSA-Schlüsselaustausch, GSS-API-Authentifizierung, das öffentliche Schlüsselformat, AES-Galois-Counter-Mode, elliptische Kurven, X.509v3-Zertifikate und SHA-2-Integritätsprüfung. RFC 4819, RFC 5592 und RFC 6242 behandeln unter anderem das Public-Key-Subsystem, SNMP beziehungsweise NETCONF über SSH.