Fachhochschule Frankfurt am Main Fachbereich 2: Informatik WS 2008/2009 IT-Security Teil 4: Secure Shell (SSH) Dr. Erwin Hoffmann E-Mail: it-security@fehcom.de
Secure Shell (SSH) vs. OpenSSH Secure Shell (SSH) wurde 1995 vom Finnen Tatu Ylönen an der Helsinki Unversität für Technologie entwickelt. Parallel hierzu gründete Ylönen die Firma CSP (SSH Communication Security [http://www.ssh.com], die sich für die Weiterentwicklung von SSH verantwortlich zeichnet, Produkte vermarktet und diese zudem an Firmen wie FSecure lizensiert wurde. SSHv1 wurde anschliessend Public Domän SW und parallel dazu als IETF Dokument veröffentlicht und durch eine eigene Workgroup begleitet. 1998 wurde SSH2 als Produkt von CSP ins Leben gerufen, während sich SSH-1 (als Protokoll) noch grosser Beliebtheit erfreute (auch wegen der Lizenzrechte). In der Version 2 (RFC 4250-4256) steht nun SSH-2 als sicherer Ersatz für Telnet und FTP zur Verfügung, und findet Weiterentwicklung durch OpenSSH [http://www.openssh.com] als freie Software. SSH-1 und SSH-2 sind im O'Reilly Buch "SSH The Secure Shell" umfangreich dokumentiert (die meisten Abbildungen stammen hieraus).
SSH-2 Scope und Geschichte SSH-2 besitzt eine geschichteten Aufbau, während SSH-1 monolithisch strukturiert war. Da SSH-1 sehr früh in die "Public Domain" abgeben wurde und SSH-2 zunächst kommerziell entwickelt und angeboten wurd, sind viele Teile der heutigen OpenSSH Implementierung noch kompatibel mit der (als unsicher betrachteten) SSH-1 Implementierung. Beide Implementierung sind aber hinsichtlich des "UI" (User Interfaces) ähnlich aber hinsichtlich der Arbeitsweise subtil verschieden, wodurch sich in der Praxis immer Unklarheiten bezüglich der Client/Server- Kommunikation ergeben. Die Server-Anwendung mag nach SSH-2 aufgesetzt sein, während der Client (auf dem gleichen Rechner) noch SSH-1 kompatibel ist. Die veröffentlichten RFC 4251-4254 sind auch nicht immer eine uneingeschränkte Freude/ Informationsquelle.
SSH RFCs Die IETF Working Group [http://www.ietf.org/html.charters/old/secsh-charter.html] hat ihre Arbeiten an SSH mittlerweile abgeschlossen: 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
Arbeitsweise von SSH SSH ist eine Client/Server Applikation: Der SSH-Server lauscht auf Port 22, Authentisierung den Client, der sich hierauf konnektet und nimmt dessen Befehle entgegen (beides über verschlüsselte Kanäle) Der Client verbindet sich mit dem SSH-Port 22 (und beide bauen eine verschlüsselte Verdingung auf), Authentisiert sich und führt hiernach Aktionen auf dem Zielsystem aus. Trotz seines Namens stellt SSH keine "Shell" im eigentlichen Sinne auf dem Server zur Verfügung, sondern einen gesicherten Transportkanal auf Applikationsebene. SSH erlaubt im weitesten Sinne "Applikations-Forwarding", indem es Proxy- Funktionen bereitstellt, bei dem die Kommandos und Nutzdaten über den gesicherten Übertragungskanal ablaufen können. Im Gegensatz zu SSL/TLS ist SSH nicht an Zertifikate gebunden, sondern stellt (auch) eine Peer-Authentisierung zur Verfügung.
SSH im Schichtenmodell Applikation Anwendung Presentation SSH- Auth Client Auth Pubkey Password Hostkey PWD Change SSH- Conn Port Forwarding Auth Agent Foward Session Support Pseudo Terminal Compresssion Flow Control RPC Session Transport SSH- Trans - Server Authentication - Algorithim Negotiation - Session Key Exchange - Session ID TCP Network IPv4, IPv6 Data Link
SSH Ablauf der Kommunikation
SSH2 Kommunikation
SSH2 'Applikationen' Nach der erfolgreichen Initiierung der SSH-Sitzung, stellt sich der weitere Kommunikationsablauf wie folgt dar: [SSH-Auth] Authentisierung - der Anwender wird authentisiert mittels Hostkey Public Key Log-In (User/Password) [SSH-Conn] Pseudo-Terminal - der Anwender bekommt eine Terminal- Sitzung (eine Shell angeboten) angeboten -- oder -- [SSH-Conn] local Command Execution via Agent - der Anwender kann beliebige Kommandos absetzen, die z.b. über ein eigenes Client-Inteface genutzt werden scp sftp [SSH-Conn] Proxying - forward TCP Port: SSH Server ruft andere Programme auf, die über SSH getunnelt werden können X-Windows HTTP
SSH Kommunikation über Schichten
Verbindungsaufnahme: SSH Trans 1. Client stellt Verbindung zum SSH-Server (Port 22) her. 2. Client und Server verständigen sich über SSH-Version. 3. Beide Seiten ergänzen ihre Pakete um Sequenzen von zufällig generierten Füllbytes und beginnen mit dem Key Exchange (KEX): Server: Übermittelt sein (DH) Public Host Key an Client. Erzeugt Session Key (SSH-1: Server Key) Erzeugt Check Bytes (pro Session zur Erzeugung des Session Identifieres) Bietet Liste von Verschlüsselungs- und Kompri-mierungs- sowie Authentisierungsverfahren.
Verbindungsaufnahme: SSH-Trans (2) Client: Sucht Host Key von Server in SSH Host Database (.shost/); falls nicht vorhanden, fragt diese beim Server nach. Wählt aus Server-Liste Verschlüsselung, Komprimierung und Authentisierung. Erzeugt symmetrischen Session Key (per DH). Init: Sendet Auswahl, Session Key verschlüsselt mit Host Key und Sever Key. Server: Entschlüsselt Session Key. Reply: Übermittelt Bestätigung (verschlüsselt mit Session Key).
Verbindungsaufnahme: SSH-Trans (3) 4. Übergang in verschlüsselten Übertragungsmode. Client: Init: Führt Authentisierung gegenüber Server durch. Sever: Reply: Bestätigt Authentisierung des Client. 5. Ende des Key-Exchange: Beide Seiten verfügen nun je über einen eigenen Session Key K (Shared Secret), der dem Partner mitgeteilt wurde über den Hash-Wert H des Session Keys => diese werden zur Verschlüsselung herangezogen. Client: Service Request SSH_MSG_SERVICE_REQUEST Nachricht: "sshuserauth" bzw. "ssh-connection". Server: Startet Service akzeptiert via SSH_MSG_SERVICE ACCEPT oder sendet Nachricht SSH_MSG_DISCONNECT.
SSH2 Transport Protokoll: SSH-Trans Das SSH-Trans Protokoll leistet folgendes: Austausch der Public Hostkeys zwischen Client und Server. Erzeugung des symmetrischen Schlüssels (Host gezogen) zur verschlüsselten Datenkommunikation (Session Key). Ggf. unter Komprimierung nach dem LZ77 Verfahren Ergänzung der Nutzinformation durch ein geeignetes Padding (für den Block-Chiffrecode). Verschlüsselung/Entschlüsselung der Nutzdaten durch den ausgewählten Chiffre-Code. Berechnung eines MACs zur Sicherstellung der Integrität der Nutzdaten. Optional kann der SSH-Server per DNS die "Glaubwürdigkeit" des SSH- Client Hosts überprüfen.
SSH-Trans: Der Session Key Für die SSH-Sitzung wird "one time" Session Key generiert. Unterstützte Verfahren: Diffie-Hellmann (Gruppe 1) mit SHA-1 (RFC 2409) Diffie-Hellmann (Gruppe 14) mit SHA-1 (RFC 2412) SSH-2 nutzt für die Voll-Duplex Kommunikation zwei getrennte Session Keys: Client --> Server Server --> Client Die Lebensdauer des Session Keys ist begrenzt (und Endet natürlich beim Ablauf der Verdindung) Spätestens am Ende der TCP Sequence-Nummerierung wird neurer Session Key generiert und ausgetauscht. Empfohlen wird die Erzeugung eines neuen Sessions Keys nach der Übertragung von 1 GByte Daten, bzw. nach 1 Stunde Verbindungszeit.
SSH-Trans: Symmetrische Verschlüsselungsverfahren Verfahren Status Bemerkung 3des-cbc REQUIRED three-key 3DES in CBC mode blowfish-cbc OPTIONAL Blowfish in CBC mode twofish256-cbc OPTIONAL Twofish in CBC mode, with a 256-bit key twofish-cbc OPTIONAL alias for "twofish256-cbc" (this is being retained for historical reasons) twofish192-cbc OPTIONAL Twofish with a 192-bit key twofish128-cbc OPTIONAL Twofish with a 128-bit key aes256-cbc OPTIONAL AES in CBC mode, with a 256-bit key aes192-cbc OPTIONAL AES with a 192-bit key aes128-cbc RECOMMENDED AES with a 128-bit key serpent256-cbc OPTIONAL Serpent in CBC mode, with a 256-bit key serpent192-cbc OPTIONAL Serpent with a 192-bit key serpent128-cbc OPTIONAL Serpent with a 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher with a 128-bit key idea-cbc OPTIONAL IDEA in CBC mode cast128-cbc OPTIONAL CAST-128 in CBC mode Es ist möglich, zusätzliche (private) Verfahren einzubinden. Diese werden bei der Übertragung mit einem "@" gekennzeichnet: my-idea-cbc@example.com
SSH-Trans: Public Key + MAC Verfahren Public Key: Verfahren Status Bemerkung ssh-dss REQUIRED Raw DSS Key ssh-rsa RECOMMENDED Raw RSA Key pgp-sign-rsa OPTIONAL OpenPGP certificates (RSA key) pgp-sign-dss OPTIONAL OpenPGP certificates (DSS key) HMAC: Verfahren Status Bemerkung hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key length = 20) hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1(digest length = 12, key length = 20) hmac-md5 OPTIONAL HMAC-MD5 (digest length = key length = 16) hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest length = 12, key length = 16)
SSH-Trans: Aufbau der PDUs encrypted compressed (none, zlib; LZ77) Length Pad.- Length Payload Random Padding MAC MAC = mac(session-key, sequence-number unencrypted_packet) Padding: SSH-Trans nimmt kein minimales Padding vor, sondern ein Random Padding [=> Konfusion] MAC: Das SSH-Trans Message Digest Verfahren nutzt die Variablen Packet Sequence Number und Session Key (unterschiedliche für die Kommunikationsrichtungen) Payload (SSH Nachrichten) byte: string: string: string:... SSH_MSG_USERAUTH_REQUEST user_name service_name method_name
SSH-Trans Nachrichten und Service Requests SSH-Trans Message Nummer SSH-Trans Disconnect Messages Reason Code SSH_MSG_DISCONNECT 1 SSH_MSG_IGNORE 2 SSH_MSG_UNIMPLEMENTED 3 SSH_MSG_DEBUG 4 SSH_MSG_SERVICE_REQUEST 5 SSH_MSG_SERVICE_ACCEPT 6 SSH_MSG_KEXINIT 20 SSH_MSG_NEWKEYS 21 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 SSH_DISCONNECT_PROTOCOL_ERROR 2 SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 SSH_DISCONNECT_RESERVED 4 SSH_DISCONNECT_MAC_ERROR 5 SSH_DISCONNECT_COMPRESSION_ERROR 6 SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 SSH_DISCONNECT_CONNECTION_LOST 10 SSH_DISCONNECT_BY_APPLICATION 11 SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 SSH_DISCONNECT_ILLEGAL_USER_NAME 15
SSH2: Authorisierung
SSH-Auth: Ablauf der Authentisierung Nachdem die verschlüsselte SSH-Verbindung aufgebaut wurde, beginnt die eigentliche Benutzer-Authentisierung. Bei SSH-2 kann das Verhalten des Servers durch die "Preferred Authentications" festgesetzt werden (1), (2) oder (3): Hostbased Authentication: Via.shosts/ Verzeichnis (.rhosts/ bei SSH-1), Public key Authentication: Wurde per ssh-keygen ein Public/Privat Key Pärchen erzeugt, wird der Public Key zum Server übermittelt. Es kann sowohl der DSA/DSS wie auch der RSA Algorithmus benutzt werden. Die Keys werden typischerweise hinterlegt als: Client: ~/.ssh/id_dsa(.pub), ~/ssh/id_rsa(.pub) Server: ~/.ssh/authorized_keys Keyboard-interactive: Liegt kein Public Key vor (und wurde z.b. Hostbased Authentication abgewählt), wird die Authentisierung mittels Password versucht.
SSH-Auth: Authentisie- rungs- Methoden
SSH-Auth: Ablauf der Benutzer-Authentisierung Der SSH-Server teilt dem Client mit, welche Auth-Verfahren unterstützt werden: Public Key Passwort Hostbased None Das SSH-Auth Protokoll stützt sich auf folgende Nachrichten: SSH_MSG_USERAUTH_REQUEST [50] SSH_MSG_USERAUTH_FAILURE [51] SSH_MSG_USERAUTH_SUCCESS [52] SSH_MSG_USERAUTH_BANNER [53]
SSH-Auth: Verfahren Hostbased + Passwort Hostbased: SSH_MSG_USERAUTH_REQUEST Benutzername Service Name "hostbased" Public Key Algorithm für den Host Key Public Host Key und Zertifikate des Clients Client Hostname als FQDN Benutzername auf dem Client UTF-8 kodiert Signatur: Session-Key + signiert mit dem Private Key des Rechners Benutzer muss Zugriff auf den "Private Key" des Rechners haben! Passwort: SSH_MSG_USE- RAUTH_REQUEST Benutzername Service Name "password" Boolean "false" Plaintext "password" in UTF-8 Unter Unix muss der SSH-Server unter "root" laufen, damit er Zugriff auf /etc/passwd hat!
SSH-Auth: Passwort Verifikation Zur Verifikation des Passworts braucht der SSH-Server Zugriff auf die lokale Authentisierungsinformation. Prinzipiell die Information über den Benutzer und sein Passwort lokal, z.b. in der Datei /etc/passwd liegen im LDAP oder NIS (NIS+) abgelegt sein unter Windows per NTLM oder Active Directory (AD) verfügbar sein oder auch per Kerberos zugänglich sein. Unter Unix wird der Zugriff auf die Benutzer-Authentisierungsdaten typischerweise per PAM (= Pluggable Authentication Module) ermöglicht. Der SSH-Server muss das entsprechende PAM unterstützen; bzw. dieses muss eingebunden sein. Hierdurch kann auch der Wechsel des Passworts via SSH realisiert werden. Ferner behalten so lokale Passwort-Policies auch über SSH Gültigkeit.
SSH-Auth: Public Key Zur Nutzung dieses Verfahrens muss der Public Key des Benutzers auf dem SSH Server liegen und der Anwender (natürlich) über einen gültigen SSH bzw. PGP Private Key verfügen Der (lokale) Private Key kann mit einer Passphrase geschützt sein. Ablauf: Client sendet Nachricht mit SSH_MSG_USERAUTH_REQUEST = "public key", dem Flag "false" und weiterführenden Angaben (s.u.). Server antwortet mit Nachricht SSH_MSG_USERAUTH_PK_OK falls unterstützt; andernfalls mit SH_MSG_USERAUTH_FAILURE. Client wiederholt Nachricht SSH_MSG_USERAUTH_REQUEST = "public key" nun mit dem Flag "true" und den Angaben über Service Name, Algorithmus, Public Key und Signatur. Im Erfolgsfall signalisiert Server dies durch ein SSH_MSG_USERAUTH_SUCCESS (_FAILURE).
SSH-Conn: Das SSH Connection Protokoll Nach erfolgter Authentisierung (auch vom Type "None") wird der weiter Ablauf der SSH-Verbindung über das SSH-Conn Protokoll abgewickelt. Folgende Möglichkeiten stehen zur Verfügung: Interaktives Arbeiten per login shell auf dem Server-Host bzw. Ausführen von remote procedures. Umleitung einer gestarteten X-Session auf dem Server über die SSH- Verbindung zum X-Server auf dem Client. Forwarding von TCP-Verbindungen, d.h. Tunneling von TCP-Verbindungen die auf dem Server bestehen zum SSH-Client. SSH-Conn bietet mehrere Kanäle, über die unterschiedliche TCP- Verbindungen ablaufen können (Multiplexing). Alle Kanäle arbeiten bi-direktional und werden durch eine Kanal-Nummer identifiziert. Sowohl Client als auch Server können Kanäle mit unterschiedlichen TCP- Optionen (Windowsize) öffnen.
SSH-Conn: Kanaltypen für lokale Anwendungen SSH-Conn kennt folgende Verbindungsarten "Channel Types" für lokale Anwendungen Kanal-Typ pty-req x11-req x11 env shell exec subsystem window-change xon-xoff signal exit-status exit-signal Bedeutung Anfordern eine Pseudo-Terminals Forwarding Request für eine X-Session X-Session über diesen Kanal Übertragung von Environment Variablen Starten einer Login-Shell Kommandos Ausführen eines Kommandos Starten einer Anwendung (scp, sftp) Ändern der Fenstergrösse auf dem Client (resize) Flusskontrolle Übertragung von Signalen an die Applikation Übertragung des Exit-Status von Applikationen Signale der Anwendung an den Client SSH-Conn bietet somit eine out-of-band Kommunikation mit den Anwendungen, die über die zugeordnete Kanal- Nummer identifiziert werden. Die in-band überragenden Signale müssen daher entsprechend maskiert werden.
SSH-Conn: Nachrichten für lokale Anwendungen Ein SSH-Conn Kanal kann von jeder Seite angefordert werden. Dies unterstützt den Einsatz von Protokollen, die mehrere Verbindungen (in unterschiedliche Richtungen) benötigen, wie beispielsweise FTP (=> sftp). Folgende Nachrichten stehen bereit: Öffnen eines Kanals Bestätigung der Öffnung Fehler beim Öffnen: Fehlercodes: SSH_MSG_CHANNEL_REQUEST Typ des Kanals Boolean "want reply" SSH_MSG_CHANNEL_OPEN_CONFIRMATION Recipient Channel Sender Channel Window Parameter SSH_MSG_CHANNEL_OPEN_FAILURE Reason Code Description SSH_OPEN_ADMINISTRATIVELY_PROHIBITED SSH_OPEN_CONNECT_FAILED SSH_OPEN_UNKNOWN_CHANNEL_TYPE SSH_OPEN_RESOURCE_SHORTAGE
SSH-Conn: X-Window Unterstützung Beim X-Windows (X.11 Protokoll) läuft der X-Server auf dem lokalen Rechner, während der Server-Host X-11 Funktionen bereit stellt. Diese X-11 Funktionen (z.b. xterm) werden über Remote Procedure Calls (rpc, rexec) aufgerufen, die einerseits die Authentisierung vornehmen, andererseits der X-Anwendung ein Laufzeit- Environment bereitstellen und speziell über die $DISPLAY-Variable der X-Anwendung mitteilen zu welchem Rechner, Port und ggf. Bildschirm sie sich zu verbinden hat. SSH-Conn nutzt die Authentisierung von SSH-Auth und startet die vom SSH-Client angeforderte X-Anwendung unter Setzung der $DISPLAY=localhost:screen, wobei der SSH-Server auf dem X-11 Port (6000/6010) horcht und die X-Sitzung an den SSH-Client tunnelt. Nachrichten: SSH_MSG_CHANNEL_REQUEST ("x11-req", autentication protocol, cookie, screen) SSH_MSG_CHANNEL_OPEN ("x11", Sender Kanal, Window Size) SSH_MSG_CHANNEL_REQUEST ("env")
SSH-Conn: X-Windows Forwarding
SSH-Conn: TCP-Port Forwarding SSH-Conn (auf dem SSH-Server) kann auch als "Proxy" fungieren. SSH-Conn erlaubt: Remote-Port Forwarding hierbei befindet sich die zu forwardende Anwendung auf dem SSH-Client und die Client-Anwendung auf dem SSH-Server Local-Port Forwarding Anwendungs-Client und SSH-Client befinden sich auf dem gleichen Rechner, während die zu forwardende Anwendung sich auf dem SSH-Server befindet. Zum Aufbau einer zu forwardenden Verbindung können die folgenden Nachrichten genutzt werden: SSH_MSG_CHANNEL_OPEN ("tcp-ip forward", want-reply, address-to-bind) Remote: SSH_MSG_CHANNEL_OPEN (forwarded-tcpip", sender channel, address that was connected, port that was connected, originator IP address, originator port) Local: SSH_MSG_CHANNEL_OPEN ("direct-tcpip", host to connect, port to connect, originator IP address, originator port)
Theorem SSH ist eine extrem flexible Applikation, die mir ihren Proxy-Fähigkeiten FireWalls ohne Probleme durchdringen kann. Ein kompromittierter SSH-Client (Trojaner) kann ohne Probleme über einen SSH-Proxy sämtliche Firmengeheimnisse unerkannt nach aussen tragen. Technische Schutzvorrichtungen wie FireWalls und Inhaltsfilter sind hier wirkungslos.