Secure Shell: Unterschied zwischen den Versionen

Aktuelle Version vom 30. August 2018, 15:18 Uhr

Secure Shell oder SSH ist sowohl ein Programm als auch ein Netzwerkprotokoll, mit dessen Hilfe man sich über eine verschlüsselte Netzwerkverbindung auf einem entfernten Computer einloggen und dort Programme ausführen kann. Die neuere Version SSH2 bietet weitere Funktionen wie Datenübertragung per SFTP. <br\> Die IANA hat dem Protokoll den TCP-Port 22 zugeordnet.

Geschichte

Die erste Version des Protokolls (jetzt SSH-1 genannt) wurde 1995 von Tatu Ylönen als Reaktion auf eine Passwort-Sniffingattacke entwickelt. Er veröffentlichte seine Implementation 1995 als Freeware, die daraufhin relativ 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 wurden, 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 wurde die Schwachstelle beseitigt und derzeit gilt das Protokoll als sicher.

1999 wurde der Wunsch nach einer freien Implementation von SSH laut, und aus der letzten freien Version der Originalimplementation entwickelte sich das separate OpenSSH-Projekt. Spätestens seit dieser Zeit existiert das SSH-Protokoll in zwei „Versionen“: Als Open-Source-Software (OpenSSH) und als kommerzielle Software (Produktname: SSHTectia), 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, ist die Firma SSH Communications Security mit der Generation 3 (SSH G3) an die Öffentlichkeit gegangen. Dieses Protokoll unterstützt die Verwendung des proprietären Snakeoil-Algorithmus „CryptiCore“ (Vorteile angeblich vor allem im Datendurchsatz, dies ist in der Praxis aber völlig irrelevant, da SSH auf heutigen PCs in Leitungsgeschwindigkeit funktioniert), der jedoch als unsicher gilt (siehe „Verschlüsselung“). Die anderen, etablierten Verschlüsselungsalgorithmen, werden weiterhin ebenfalls unterstützt. 2006 wurde dieses Protokoll (Version 2) von der IETF als Internetstandard vorgeschlagen. Eine Zertifizierung nach FIPS-Standard 140-2 (FIPS = Federal Information Processing Standard) besteht bereits länger.

Wichtiger als der neue Algorithmus ist die erstmalige Unterstützung des SSH-Protokolls auf dem Mainframe (IBM z/OS). Damit existiert nun nach Hersteller-Angaben eine durchgängige Unterstützung der Plattformen Unix-Derivate (BSD, Linux, Solaris, AIX, HP-UX, u.a.), Windows, IBM z/OS.

Verwendung

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 und sollten daher nicht mehr verwendet werden.

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 sichere 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 komplettes entferntes Dateisystem auf dem lokalen Rechner gemountet werden.
Wenn der Server A dem Server B ohne interaktive Eingabe des Passworts SSH-Zugriff gestatten soll, trägt man den öffentlichen Schlüssel von B in die SSH-Konfiguration von A ein (authorized_keys). Dann kann B z. B. von der Kommandozeile via SSH auf A Kommandos ausführen oder mit SCP Backupkopien machen.
Mit 'ssh-keyscan' kann der öffentliche Schlüssel eines entfernten Rechners ausgelesen werden. Damit kann man z. B. feststellen, ob der Rechner, der sich derzeit hinter einem DynDns-Namen verbirgt, wirklich der eigene Server ist.

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

Damit lassen sich nun grundsätzlich drei Anwendungsszenarien darstellen:

Secure System Administration (Sichere Systemverwaltung)
zur Absicherung der Fernverwaltung von Servern. Ersetzt Telnet, Rlogin etc.
Secure File Transfer (Sicherer Dateitransfer)
zur Herstellung sicherer, automatisierter und interaktiver Dateitransfers.
Secure Application Tunneling (Sicheres Tunneln)
zum transparenten Schutz TCP/IP-basierender Anwendungen als „End-to-End-Security“.
Anmerkung: Natürlich kann SSH auch über mehrere Stationen laufen.

Auf einem fremden Rechner anmelden

$ ssh -l benutzer rechnername.domaene.tld
$ ssh benutzer@rechnername.domaene.tld
$ # ein Kommando auf dem entfernten Rechner ausführen:
$ ssh benutzer@rechnername.domaene.tld kommando paramater parameter

Dateien mit scp auf einen fremden Rechner kopieren

$ scp meine-lokale.datei benutzer@zielrechner.domaene.tld:/pfad/zum/Zielverzeichnis/
$ scp -l benutzer zielrechner.domaene.tld:/pfad/zum/Zielverzeichnis/ziel.datei /lokaler/pfad/
$ # auch ganze Verzeichnisstrukturen können rekursiv kopiert werden
$ scp -r /pfad/zum/Quellverzeichnis benutzer@zielrechner.domaene.tld:/pfad/zum/Zielverzeichnis

Zertifikate generieren

Für das kennwortlose Anmelden müssen erst Zertifikate generiert werden. Der erzeugte Privatschlüssel ("private key") muss geheim gehalten werden Der öffentliche Schlüssel ("public key") kann dann z.B. dem jeweiligen Server-Administrator gegeben werden, auf den man Zugang möchte. Dieser trägt ihn beim jeweiligen Benutzer in dessen authorized_keys-Datei ein. Der öffentliche Schlüssel muss nicht speziell geheim gehalten werden, er ist alleine nutzlos.

$ ssh-keygen

Host durchtunneln

Diese Methode dient dazu, über eine Drittstelle zu verbinden. Sie kann für sämtliche SSH-Dienste genutzt werden. Üblicherweise ist dieses Vorgehen nötig, wenn man keinen direkten Zugriff auf ein Netzwerk hat. Typischerweise ist es durch eine Firewall abgeschottet, welche ausschliesslich Zugriff auf einen SSH-Bastion-Host erlaubt. Auf dem Bastion-Host muss netcat oder ein ähnliches Werkzeug installiert sein.

$ ssh -o "ProxyCommand=nohup ssh benutzer@zwischenstation.domaene.tld nc -w1 %h %p" benutzer@rechnername.domaene.tld

Tunnels auf Anfrage

Möchte man einen unsicheren Dienst übers Internet betreiben, sind SSH-Tunnels natürlich ideal. Ist es nicht möglich diese jeweils manuell zu starten oder soll der Dienst regelmässig oder sogar dauerhaft laufen, währe es praktisch, wenn sich der Tunnel von sich aus aufbaut. Um dies zu realisieren benötigt man zusätzlich zu SSH einen installierten inetd-Dienst auf dem client und netcat auf dem Server, der bei Verbindungen zu einem lokalen Port automatisch den Tunnel aufbaut. Zuerst sollte man ein separates Zertifikat mit leerem Kennwort generieren und dieses in der authorized_keys-Datei des Zielhosts zusammen mit einigen Parametern installieren. Im Beispiel soll ein Tunnel zu einem MySQL-Server eingerichtet werden, der auf Port 3306 läuft.

benutzer@server:~$ cd .ssh/
benutzer@server:~$ ssh-keygen -t rsa -b 4096 -f id_mysql
benutzer@server:~$ cat id_mysql.pub >> authorized_keys

Die unterste Zeile der authorized_keys2-Datei enthält den neu generierten Schlüssel. Am Anfang dieser Zeile muss folgendes ergänzt werden:

command="nc localhost 3306",no-X11-forwarding,no-agent-forwarding,no-port-forwarding ssh-rsa XXX...

Nun muss man noch das Zertifikat auf den Client übertragen und in das ".ssh"-Verzeichnis von root ablegen. Idealerweise manuell, notfalls per scp. Anschliessend muss noch inetd konfiguriert werden. Dazu die Datei "/etc/inetd.conf" ergänzen...

# ssh tunnel auf mysql server 
127.0.0.1:3306   stream   tcp   nowait   root   /usr/bin/ssh   -q -T -i /root/.ssh/id_mysql benutzer@server.domaene.tld

...und inetd neu laden.

root@client:~# /etc/init.d/openbsd-inetd reload

Um den Tunnel zu nutzen gibt man in den Applikationen einfach 127.0.0.1 als Server an.

SSH als SOCKS-Server

Manchmal möchte man mehreren Programmen die Möglichkeit bieten über einen anderen Rechner ins Internet zu gehen. Statt für jede Applikation obigen Aufwand zu betreiben, kann man SSH auch als SOCKS-Server verwenden. Alle Programme welche diesen SOCKS-Server benutzen werden dann umgeleitet und scheinen vom Zielsystem aus ins Netz zu gehen. Sämtlicher Verkehr dazwischen ist verschlüsselt. Im Beispiel soll der SOCKS-Dienst auf Port 9999 lokal erreichbar sein und über den Rechner server.domaene.tld ins Netz gehen.

benutzer@server:~$ ssh -D 9999 benutzer@server.domaene.tld sleep 30

Man hat nun 30 Sekunden Zeit um eine erste Verbindung über diesen SOCKS-Server herzustellen. Es gibt zwei Möglichkeiten das zu tun. Die meisten Webbrowser und E-Mail-Clients unterstützen SOCKS nativ. Diese können einfach mit dem SOCKS-Server 127.0.0.1:9999 konfiguriert werden. Alle anderen Programme kann man mit tsocks "umbiegen".

rsync mit root-Rechten

Möchte man, z.B. für ein Backup, per von einem entfernten Rechner per rsync über SSH Systemdateien sichern (z.B. aus /etc), benötigt man auf dem Zielrechner einen Benutzer mit den entsprechenden Zertifikaten in seiner authorize_keys Datei. Damit dieser Benutzer nicht root selbst sein muss, kann man die nötigen Rechte nur für den rsync-Befehl in der Datei /etc/sudoers einem Normalsterblichen (im Beispiel ein Benutzer namens "backup") gewähren:

backup ALL = NOPASSWD: /usr/bin/rsync

Zusätzlich kann man mit einigen restriktionen am Anfang der betreffenden Zeile in der authorize_keys Datei den Zugriff weiter begrenzen:

from="192.168.0.1",no-port-forwarding,no-agent-forwarding,no-pty,no-X11-forwarding ssh-rsa ...

Sicherheit

Die Sicherheit von SSH wird durch eine Reihe von kryptographischen Algorithmen zur Verschlüsselung und Authentifizierung gewährleistet.

Authentifizierung

Der Server identifiziert sich dem Client gegenüber mit einem RSA-Zertifikat, wodurch Manipulationen im Netzwerk erkannt werden können (niemand anderer kann sich als ein bekannter Server ausgeben).

Der Client kann sich wahlweise mit einem öffentlichen Schlüssel, der auf dem Server hinterlegt ist, (sogenannte Pubkey-Authentifizierung) oder einem gewöhnlichen Textpasswort authentifizieren.

Verschlüsselung

Nach erfolgreicher Authentifizierung wird für die Dauer der Sitzung ein geheimer Schlüssel erzeugt, mit dem die gesamte nachfolgende Kommunikation verschlüsselt wird. Je nach Protokollversion kommt dabei ein anderer Verschlüsselungsalgorithmus zum Einsatz: SSH2 benutzt standardmäßig den AES mit einer 128-Bit-Schlüssellänge. Des Weiteren werden 3DES, Blowfish, Twofish, CAST, IDEA, Arcfour, SEED und AES mit anderen Schlüssellängen unterstützt. Die neue Generation SSH G3 unterstützt auch den proprietären Snakeoil-Algorithmus CryptiCore, der unter Cryptoexperten als Security-through-obscurity-Algorithmus verpönt ist und außer dem angeblichen Geschwindigkeitsgewinn keinerlei weitere Sicherheitsoptionen bietet. <ref>Crypto-Gram</ref>

Es wird von allen seriösen Cryptoexperten empfohlen, weiterhin SSH mit Protokollversion 2 zu benutzen.

Schwachstellen

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 die neue Protokollversion ab SSH-2 aufwärts verwendet werden. Diese zeichnet sich durch einen modularen Aufbau der Transport-, Autorisierungs- und Verbindungsschichten aus und ermöglicht im Gegensatz zu SSH-1 die Verwendung von verschiedenen Verschlüsselungsalgorithmen.

Implementierungen

SSH-Implementationen 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 ist beispielsweise der SSH-Client PuTTY für Microsoft Windows, welcher mittlerweile auch auf Unix portiert wurde, oder auch Tera Term, Teemtalk, Neoware, Pericom, ZOC.

Mit OpenSSH existiert auch eine freie Implementierung von SSH, die mittlerweile einen sehr großen Verbreitungsgrad erreicht hat. Der Streit, was denn nun das „bessere“ SSH ist (kommerzielles oder freies SSH) ist so alt, wie die Existenz der beiden Implementierungen selbst. Dem kostenlosen Bezug der OpenSSH-Variante stehen abgesicherte Lizenzrechte, Weiterentwicklungs-Know how (incl. Roadmap) und Support-Unterstützung der kommerziellen Variante gegenüber. Durch die Unterstützung von plattform-übergreifender Zertifikats-Authorisierungsmöglichkeit und Unterstützung auf dem Mainframe positioniert sich die kommerzielle Variante klar und ausschließlich für Unternehmen, wohingegen OpenSSH sehr wohl seine Bedeutung im Privatkunden-Umfeld, aber auch bei versierten Administratoren in Firmen hat.

Weblinks

Spezifikationen

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
RFC 4419 – Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4432 – RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4462 – Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
RFC 4716 – The Secure Shell (SSH) Public Key File Format

Implementierungen