new ssh – secure shell · 2019. 10. 26. · idea, arcfour, seed und aes. standardmässig wird...

Autor: Marco Costa, HTW Chur,

Dozent: Bruno Wenk, HTW Chur,

SSH – Secure Shell

Autor: Marco Costa, HTW Chur, [email protected]

Dozent: Bruno Wenk, HTW Chur, [email protected]

Chur, 07. Juni 2010

[email protected]

[email protected]

HTW Chur Datenkommunikationsprotokolle

Telekommunikation / Elektrotechnik TETv08

2

Inhaltsverzeichnis

1 Einleitung ............................................................................................................. 3

2 SSH ...................................................................................................................... 4

2.1 Geschichte..................................................................................................... 4

2.2 Grundfunktionen ............................................................................................ 5

2.3 Verbindungsaufbau ....................................................................................... 5

2.4 Protokollebene ............................................................................................... 7

2.5 Protokollanalyse mit Wireshark ...................................................................... 9

2.6 Open Source Client und Server ................................................................... 10

3 Einsatz ............................................................................................................... 11

3.1 Remote Fernsteuerung ................................................................................ 11

3.2 Tunneling ..................................................................................................... 13

Abbildungsverzeichnis ...............................................................................................

Quellenverzeichnis ....................................................................................................



3

1 Einleitung

Bis heute wurde eine Vielfalt von Protokollen entwickelt, welche für jede

Übertragungsform von Daten geeignet ist: zum Beispiel das RTP (Real-Time Transport

Protocol) ist ein Protokoll zum kontinuierlichen Streaming von Daten oder Telnet für die

Fernverwaltung von Servern. Leider unterstützen viele von diesen Protokollen (z.B.

Telnet) nicht eine verschlüsselte Verbindung zwischen dem Client und dem Server und

sogar wird die Benutzerauthentifizierung unverschlüsselt übermittelt. Folglich sind die

übertragenen Daten von einem Angreifer abhörbar. Um dieses Problem zu beheben,

wurde ein Protokoll entwickelt, welches vollständig die Protokolle Telnet und RSH

(Remote Shell) ersetzt und den Datenaustausch von anderen Protokolle durch die so

genannte „Tunnels“ zu verschlüsseln ermöglicht: Die Datenpakete von einem anderen

Protokoll werden in SSH-Pakete eingepackt. Dieses Protokoll heisst SSH (Secure

Shell).

Diese Arbeit befasst sich mit dem „Secure Shell“ SSH-Protokoll Version 2. Am Anfang

dieser Arbeit wird ein Überblick über seine Geschichte und über die Grundfunktionen

des Protokolls erläutert. Danach in den Kapiteln 2.3, 2.4, 2.5 und 2.6 wird erklärt wie ein

SSH-Paket aufgebaut ist und was es für Client- und Serverprogramme gibt, wo das

SSH-Protokoll implementiert wird. Im letzten Teil der Arbeit werden die zwei wichtigsten

Grundfunktionen des Protokolls anhand von praktischen Beispielen gezeigt.

Die Ziele dieser Arbeit sind:

➢ Geschichte von SSH kennenlernen

➢ Funktionsweise des SSH-Protokoll verstehen

➢ Installation von Client und Server

➢ Mit einem SSH-Server verbinden und diesen fernsteuern

➢ Einen „Tunnel“ erstellen



4

2 SSH

2.1 Geschichte

In Wikipedia ist folgendes zu finden:

„Die erste Version des Protokolls (jetzt SSH-1 genannt) wurde 1995 von TatuYlö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 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 TatuYlö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 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 Implementationen: 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, 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), 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.“[1]



5

2.2 Grundfunktionen

SSH bietet die folgenden Grundfunktionen:

• Vertraulichkeit, Authentifizierung, Autorisierung und Integrität

• Fernsteuerung von Servern

• Übertragung von Daten: SFTP, SCP (Secure Copy) sind Alternativen zu FTP und

RCP

• SSHFS (entferntes Dateisystem auf dem lokalen Rechner mounten)

• Aufbau von Tunnels

• X11 über SSH transportieren (X11 ist ein Netzwerkprotokoll und eine Software, die

Fenster auf Bitmap-Displays in den meisten unixoiden Betriebssystemen und

OpenVMS ermöglicht.)

2.3 Verbindungsaufbau

Heutzutage wird nur die zweite und die dritte Version von SSH verwendet, da SSH-1

Schwachstellen enthält: Ein Angreifer könnte eine SSH-1 Sitzung wegen den

Schwachstellen der verwendeten Integritätsprüfung (CRC-32) abnehmen.

Ab Version 2 werden die folgenden Sicherheitsanforderungen erfüllt:

Datenintegrität: Während der Übertragung von Daten auf einem Trägersignal passiert

es oft, dass äussere Störungen den Bitstrom beeinflussten oder die Pakete wurden

durch einen Angreifer manipuliert: Folglich ist das Datenpaket unbrauchbar. Das

Sicherheitsmanagement muss die Integrität der Datenpakete gewährleisten und das

wird durch eine Prüfsumme erreicht. Im SSH-2 werden die Algorithmen hmac-sha1 und

hmac-md5 verwendet.

Vertraulichkeit: Sie wird durch die symmetrische Verschlüsselung realisiert. Hier

kommen die folgenden Verschlüsselungen im Spiel: 3DES, Blowfish, Twofish, CAST,

IDEA, Arcfour, SEED und AES. Standardmässig wird für SSH2 das AES mit einem 128

Bit Schlüssel gearbeitet. SSH-3 verfügt über einen neuen Verschlüsselungsalgorithmus

und zwar der Snakeoil-Algorithmus „CryptiCore“. SSH unterstützt auch die



6

asymmetrische Verschlüsselung (RSA, DSA), jedoch wird diese nur bei der

Teilnehmerauthentifizierung eingesetzt.

Server-Authentifizierung und Client-Authentifizierung: Unter diesem Begriff versteht

man, dass die Identität der Teilnehmer sichergestellt wird. Ist der Server oder Client

wirklich derjenige, für den er sich ausgibt? SSH bietet dem Benutzer mehrere

Möglichkeiten sich am Server zu identifizieren. Die einfache Variante ist, dass sich der

Benutzer mit dem Login des Betriebssystems einloggt. Eine andere Variante, die heute

am meistens verwendet wird, ist die Public-Key-Authentifizierung (RSA oder DSA): Der

Client muss immer ein Schlüsselpaar (public und private key) generieren. Der

öffentliche Schlüssel soll an den Server übereicht werden. [2]

Verbindungsaufbau (vereinfacht):

Ablauf der Verbindungsaufbau (Kombiniertes Verfahren, rote Pfeile):

• Zuerst wird ein TCP-Verbindung (Port 22) aufgebaut

• Danach schickt der Server seine Protokollversion und die verfügbaren Protokolle

• Der Client antwortet ebenfalls mit dem Senden seiner unterstützten Version und das

gewählte Protokoll. Er verlangt auch den öffentlichen Schlüssel des Servers

• Der Server schickt seinen öffentlichen Schlüssel

• Der Client generiert einen Session Key und verschlüsselt ihn mit dem öffentlichen

Schlüssel des Servers

• Der Server entschlüsselt den Session Key mit seinem privaten Schlüssel und ab jetzt

werden alle Daten, die zwischen Server und Client ausgetauscht werden, mit einem

symmetrischen Verfahren (Session Key) verschlüsselt.

Abb. 1: Verbindungaufbau (Quelle:

http://suedmeyer.net/inhalte/pdf/ssh_lecture.pdf )



7

Ablauf einer Authentifizierung (RSA-Verfahren, grüne Pfeile):

1. Client sendet eine Verbindungsaufbauanfrage (Login-Anfrage) am Server

2. Der Server erhält diese Anfrage und antwortet mit einer „Challenge“: Ein Zufallswert

wird generiert und mit dem öffentlichen Schlüssel des Benutzers (Client)

verschlüsselt.

3. Der Client entschlüsselt diesen Zufallswert mit seinem privaten Schlüssel und bildet

den dazugehörigen Hashwert. Dieser Hashwert wird mit dem privaten Schlüssel

verschlüsselt und dem Server geschickt.

4. Der Server entschlüsselt den empfangenen Hashwert mit dem öffentlichen Schlüssel

des Benutzers und konfrontiert seinen generierten Hashwert mit dem vom Client.

5. Wenn beide Hashwerte übereinstimmen, wird der Zugriff auf dem Server

zugelassen.[3,4]

2.4 Protokollebenen

SSH arbeitet auf der Anwendungsschicht (5. bis 7. Schicht OSI-Modell). Die SSH-

Pakete werden immer über eine zuverlässige Verbindung auf der Transportschicht (z.B.

TCP, Port 22) übermittelt.

SSH-2 Protokoll besteht aus drei Teilen (SSH Architektur RFC 4251):

• SSH Transport Layer Protocol (SSH-TRANS, RFC 4253)

• SSH Authentication Protocol (SSH-AUTH, RFC 4252)

• SSH Connection Protocol (SSH-CONN, RFC 4254)

Transport Layer Protocol: Das Transport Protocol setzt als erste Protokollebene auf.

Seine Aufgaben sind: die Regelung der Aushandlung von Algorithmen, Austausch von

Sitzungs-Schlüsseln usw.

Authentication Protocol: Das Authentication Protocol setzt auf dem SSH-Transport

Layer Protocol auf. Seine Aufgabe ist die Client-Authentifizierung und

Passwortänderung.



8

Connection Protocol: Es setzt auch wie das Authentication Protocol auf dem

Transport Layer Protocol auf und verwaltet die TCP-Port-Forwarding, die Verwaltung

von virtuellen Terminals, die Datenkomprimierung usw.[3,4]

Aufbau eines SSH-Paketes

Nach dem Verbindungsaufbau auf der Transportschicht tauschen der Client und der

Server SSH-Pakete. Diese werden als Nutzdaten an einem sogenannte Service Access

Point (SAP) der unterstehenden Schicht (z.B. TCP) übergeben. Ein entsprechendes

Paket hat die folgende Struktur:

• Gesamtlänge von Paketlänge inklusive Padding muss ein vielfaches der Blocklänge

oder ein vielfaches von 8 ergeben

• Maximale Blocklänge: < 35‘000 Byte

• Paketlänge = Paddinglänge + Nutzdaten + Padding

Abb. 2: SSH Architektur (Quelle: http://suedmeyer.net/inhalte/pdf/ssh_lecture.pdf)

Abb. 3: Paketaufbau (Quelle: http://suedmeyer.net/inhalte/pdf/ssh_lecture.pdf)

HTW Chur

Telekommunikation / Elektrotechnik

• Nutzdaten: falls Kompression aktiv

• MAC: Checksumme (hmac

vor der Verschlüsselung

2.5 Protokollanalyse mit Wires

In diesem Abschnitt werden

untenstehende Paketaufzeichnung entspricht

Authentifizierung.

Wie aus der Abbildung 4 ersichtlich

mit dem SSH-Server (192.168.1.200)

sogenannten TCP-Drei-Wege

Austausch von Informationen (Version des Clients und des Server

Verschlüsselungsmethode) zwischen

Session Key (Diffie-Hellman

die Verbindung schon verschlüsselt. Noch zu erkennen ist die orientierte Verbindung:

Jedes SSH-Paket wird vom Server mit einem TCP

Adresse „http://www.hitech-

Aufzeichnung zu finden.

Abb. 4: Wireshark

Datenkommunikationsprotokolle


falls Kompression aktiviert, wird dieses Feld mit zlib kompri

(hmac-sha1 oder hmac-md5) des gesamten Paket

berechnet.

Protokollanalyse mit Wireshark

werden grob die empfangenen Pakete untersucht

stehende Paketaufzeichnung entspricht einem Verbindungsaufbau

ersichtlich, wird der Client (192.168.1.109) eine Verbindung

Server (192.168.1.200) erstellen. Die ersten drei Pakete sind

Wege-Handshake (Verbindungsaufbau). Danach folgt der

Austausch von Informationen (Version des Clients und des Server,

) zwischen dem Client und dem Server und es wird ein

Hellman-Schlüsselaustausch) vereinbart. Ab Paket Nummer


Paket wird vom Server mit einem TCP-Paket (ACK) bestätigt.

-blog.com/wp-content/2010/05/sshv2.cap“ ist diese


TETv08

9

komprimiert

n Paketes. Sie wird

untersucht. Die

aufbau mit

, wird der Client (192.168.1.109) eine Verbindung

llen. Die ersten drei Pakete sind die

Handshake (Verbindungsaufbau). Danach folgt der

Server und es wird ein

Ab Paket Nummer 19 ist


t (ACK) bestätigt. Auf die

ist diese



10

2.6 Open Source Client und Server

Es sind verschiedene Programme (Clientseitig und Serverseitig) im Internet zu finden.

Hier sind ein paar aufgelistet:

Client:

PuTTY (Windows, Unix):

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

OpenSSH (Unix): http://www.openssh.com/

MacSSH (Mac OS X): http://sourceforge.net/projects/macssh/

Server:

OpenSSH (Unix): http://www.openssh.com/

MobaSSH (Windows): http://mobassh.mobatek.net/en/

Cygwin + SSHd (Windows): http://www.fz-

juelich.de/jsc/docs/tki/tki_html/t0375/t0375.html

WinSSHD (Windows): www.bitvise.com/winsshd

Mac OS X: Client (ssh) und Server (sshd) sind schon vorinstalliert. Client ist schon aktiviert und der Server muss ihn unter „Systemeinstellungen->Freigaben->Entfernte Anmeldung“ aktivieren. Ubuntu, Suse, Solaris, etc.:SSH-Clients (ssh) ist schon vorinstalliert. Am einfachsten um einen SSH-Server auf Ubuntu zu installieren, ist es das folgende Paket zu installieren: „openssh-server“. Befehl für die Installation: „sudo apt-get install openssh-server“. Um den SSH-Server zu starten den Befehl „sudo /etc/init.d/ssh start“ im Terminal eintippen. Windows: SSH-Client und SSH-Server sind nicht vorhanden. Erzeugung von öffentlichen und privaten Schlüsseln: GnuPGP (http://www.gnupg.org/), PuTTY gen (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) oder ssh-keygen (siehe Kapitel 3.1 - Schlüsselgenerierung) im Terminal.

HTW Chur


3 Einsatz

3.1 Remote Fernsteuerung

Wie ich schon im Kapitel 2.3

Key am meistens verwendet. Der Public Key

werden. Es gibt zwei Möglichkeiten dies zu tun.

1. Den öffentlichen Schlüssel lokal

2. beim Verbindungsaufbau den

Verbindung mit einem SSH

SSH Client: mit dem Befehl „

einem SSH-Server erstellt.

Abb. 5: SSH-Client



Remote Fernsteuerung

Wie ich schon im Kapitel 2.3 erläutert habe, wird die Authentifizierung mit dem Public

Key am meistens verwendet. Der Public Key des Clients soll dem Server überreicht

werden. Es gibt zwei Möglichkeiten dies zu tun.

Den öffentlichen Schlüssel lokal auf den Server zu schreiben.

Verbindungsaufbau den öffentlichen Schlüssel auszutauschen

Verbindung mit einem SSH-Server

nt: mit dem Befehl „ssh cosweb.dyndns.org -l costa“ wird eine Verbindung mit

In der Abbildung 5 ist zu erkennen,

dass der Client nicht die

Authentifizierung des Servers

überprüfen kann. Grund dafür ist,

dass der öffentliche Schlüssel

Servers nicht in die

„~/.ssh/known_hosts

eingetragen wurde und dieser wird

beim Verbindungsaufbau

geschickt.


TETv08

11

die Authentifizierung mit dem Public

soll dem Server überreicht

Schlüssel auszutauschen.

“ wird eine Verbindung mit

Abbildung 5 ist zu erkennen,

dass der Client nicht die

Authentifizierung des Servers

überprüfen kann. Grund dafür ist,

dass der öffentliche Schlüssel des

Datei

„~/.ssh/known_hosts“ auf dem Client

und dieser wird

beim Verbindungsaufbau dem Client

HTW Chur


Putty:

Schlüsselgenerierung:

Der Befehl „ssh-keygen –t rsa

Schlüssel. Nach der Generierung wird der

gespeichert, während sich der private Schlüssel als

Dann muss der öffentliche Schlüssel in die Datei

SSH-Server angehängt werden.

Server muss richtig eingestellt werden:

„AuthorizedKeysFile ~/.ssh/authorized_keys“

„PasswordAuthentication no“

Abb. 6: PuTTY



t rsa“ erzeugt einen öffentlichen und einen privaten

enerierung wird der öffentliche Schlüssel in „~/.ssh/id_rsa.pub“

nd sich der private Schlüssel als „~/.ssh/id_rsa“ speichert

Schlüssel in die Datei „~/.ssh/authorized_keys“

werden. Die Konfigurationsdatei (/etc/ssh/sshd_config

Server muss richtig eingestellt werden: „PubkeyAuthentification yes“,

„AuthorizedKeysFile ~/.ssh/authorized_keys“, „PermitRootLogin no“ und

„PasswordAuthentication no“.

PuTTY


TETv08

12

erzeugt einen öffentlichen und einen privaten RSA-

„~/.ssh/id_rsa.pub“

speichert.

„~/.ssh/authorized_keys“ auf dem

/etc/ssh/sshd_config) des

und

HTW Chur


Befehl einer SSH-Verbindung mit Public

cosweb.dyndns.org -l costa

3.2 Tunneling

SSH-Client:

Befehl: “ssh -2 -N -f -L 6001

2: SSH Version 2, N: not execute a remote command,

lassen, L: Adresse (6001: Locale Port auf dem Rechner,

143: Remote Port), cosweb.dyndns.org

Putty:

Abb. 7: SSH-Keygen

Abb. 8



Verbindung mit Public-Key Verfahren: „ssh -i ~/.ssh/id_rsa

l costa“

1:mail.me.com:143 cosweb.dyndns.org -l costa

not execute a remote command, f: Tunnel im Hintergrund laufen

Locale Port auf dem Rechner, mail.me.com

cosweb.dyndns.org: Adresse des SSH-Servers, l:

Keygen

Abb. 8: PuTTY


TETv08

13

i ~/.ssh/id_rsa

l costa”

Tunnel im Hintergrund laufen

mail.me.com: Remote Adresse

login name



14

In der Abbildung 9 wird gezeigt, wie ein Tunnel aufgebaut wird. Die Situation ist, dass

der Laptop (Client) eine Verbindung mit dem IMAP-Server (me.com) auf Port 143

aufbauen will. Wegen der strengen Regeln der Firewall werden solche Verbindungen

geblockt. Um dieses Problem umzugehen, wird der Client zuerst eine Verbindung auf

Port 22 mit einem SSH-Server aufbauen: der Verkehr auf Port 22 wird von der Firewall

zugelassen. Danach stellt der SSH-Server eine Verbindung mit dem IMAP-Server auf

Port 143, wo die Firewall den Verkehr auf Port 143 nicht blockt. Jetzt wenn der Client

auf die Adresse „localhost:6001“ zugreift, wird er eine Verbindung durch SSH-Server

mit me.com erstellen: Client schickt Datenpakete an SSH-Server und diese werden an

me.com weitergeleitet und umgekehrt die Datenpakete, die vom IMAP-Server me.com

ankommen, werden am Client geschickt.

Laptop

IMAP-Server

Internet

192.168.1.100

RouterFirewallVerkehr auf Port 143

ist gesperrt

RouterFirewall

Verkehr auf Port 143 ist zugelassen

200.56.143.20080.115.80.3/192.168.1.1

200.56.143.1

Papierkorb

Verbindungsanfrage an 200.56.143.200:143

Papierkorb

Ohne Tunnel

Laptop

IMAP-Server

Internet

192.168.1.100

RouterFirewall

Verkehr auf Port 143 ist gesperrt. Port 22

ist offen

RouterFirewall

Verkehr auf Port 143 ist zugelassen

200.56.143.20080.115.80.3/192.168.1.1

200.56.143.1

Papierkorb

Verbindungsanfrage an 156.23.256.70:22

SSH-Server

156.23.256.1

156.23.256.70

FirewallVerkehr auf Port 143

und 22 ist zugelassen

Mit Tunnel

Abb. 9: Tunnel



Abbildungsverzeichnis

Abb. 1: Verbindungaufbau .............................................................................................. 6

Abb. 2: SSH Architektur ................................................................................................. 8

Abb. 3: Paketaufbau ....................................................................................................... 8

Abb. 4: Wireshark ........................................................................................................... 9

Abb. 5: SSH-Client ....................................................................................................... 11

Abb. 6: PuTTY .............................................................................................................. 12

Abb. 7: SSH-Keygen .................................................................................................... 13

Abb. 8: PuTTY .............................................................................................................. 13

Abb. 9: Tunnel .............................................................................................................. 14



Quellenverzeichnis

[1] Wikipedia: SSH, gefunden am 15. April 2010 [http://de.wikipedia.org/wiki/Ssh]

[2] Daniel J. Barrett & Richard E. Silverman, SSH, The Secure Shell: The Definitive

Guide, O’Reilly, 2001

[3] RFC 4251 – The Secure Shell (SSH) Protocol Architecture, gefunden am 17. April

2010 [http://tools.ietf.org/html/rfc4251]

[3] RFC 4252 – The Secure Shell (SSH) Authentication Protocol, gefunden am 17.

April 2010 [http://tools.ietf.org/html/rfc4252]

[3] RFC 4253 – The Secure Shell (SSH) Transport Layer Protocol, gefunden am 17.

April 2010 [http://tools.ietf.org/html/rfc4253]

[3] RFC 4254 – The Secure Shell (SSH) Connection Protocol, gefunden am 17. April

2010 [http://tools.ietf.org/html/rfc4254]

[4] IT-Sicherheit - Sicherheit vernetzter Systeme, gefunden am 16. April 2010

[http://www.nm.ifi.lmu.de/teaching/Vorlesungen/2009ws/itsec/_skript/itsec-k13-v5.0.pdf]

new ssh – secure shell · 2019. 10. 26. · idea, arcfour, seed und aes. standardmässig wird...

Documents