New SSH – Secure Shell · 2019. 10. 26. · IDEA, Arcfour, SEED und AES. Standardmässig wird...
Transcript of 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
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 ....................................................................................................
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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]
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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 )
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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.
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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
Telekommunikation / Elektrotechnik
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
die Verbindung schon verschlüsselt. Noch zu erkennen ist die orientierte Verbindung:
Paket wird vom Server mit einem TCP-Paket (ACK) bestätigt.
-blog.com/wp-content/2010/05/sshv2.cap“ ist diese
Datenkommunikationsprotokolle
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
die Verbindung schon verschlüsselt. Noch zu erkennen ist die orientierte Verbindung:
t (ACK) bestätigt. Auf die
ist diese
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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
Telekommunikation / Elektrotechnik
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
Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik
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.
Datenkommunikationsprotokolle
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
Telekommunikation / Elektrotechnik
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
Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik
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
Datenkommunikationsprotokolle
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
Telekommunikation / Elektrotechnik
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
Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik
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
Datenkommunikationsprotokolle
TETv08
13
i ~/.ssh/id_rsa
l costa”
Tunnel im Hintergrund laufen
mail.me.com: Remote Adresse
login name
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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
HTW Chur Datenkommunikationsprotokolle
Telekommunikation / Elektrotechnik TETv08
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]