Secure Shell: Unterschied zwischen den Versionen
Michi (Diskussion | Beiträge) (Die Seite wurde neu angelegt: Die <b>Secure Shell / SSH</b> ist ein Netzwerkprotokoll, mit dem man sich über eine verschlüsselte Rechnernetz-Verbindung auf einem entfernten Rechner anm...) |
Michi (Diskussion | Beiträge) |
||
Zeile 23: | Zeile 23: | ||
|- | |- | ||
| width=20% | <b>Verschlüsselungsalgorithmen</b> | | width=20% | <b>Verschlüsselungsalgorithmen</b> | ||
| width=40% | Dürftiges Angebot (u. a. das unsichere DES oder das sichere aber langsame [[3DES]], sowie das schnelle und sichere [[Blowfish]]). Lücken im Protokoll ermöglichen theoretisch ein Knacken des Protokolls. | | width=40% | Dürftiges Angebot (u. a. das unsichere [[DES]] oder das sichere aber langsame [[3DES]], sowie das schnelle und sichere [[Blowfish]]). Lücken im Protokoll ermöglichen theoretisch ein Knacken des Protokolls. | ||
| width=40% | Zusätzlich [[AES]] und weitere. | | width=40% | Zusätzlich [[AES]] und weitere. | ||
|- | |- | ||
Zeile 31: | Zeile 31: | ||
|- | |- | ||
| <b>Aushandeln des Schlüssels</b> | | <b>Aushandeln des Schlüssels</b> | ||
| | | Clientseitig erzeugte Schlüssel (engl. keys). Der SSH-Server sendet seinen öffentlichen Schlüssel an den SSH-Client. Dieser erzeugt eine zufällige 156 Bit lange Zahl, verschlüsselt diese mit dem öffentlichen Schlüssel und sendet das Ergebnis an den SSH-Server. Fortan läuft der Datenstrom mit dieser übermittelten Zufallszahl verschlüsselt ab. Schneidet ein Lauscher diese Kommunikation mit, befindet er sich im Besitz des (verschlüsselten) Schlüssels. Mittels Ausprobieren aller Möglichkeiten (Brute Force-Methode) kann es gelingen, den Schlüssel zu ermitteln - im Schnitt dauert das allerdings mehrere Jahre... | ||
| Einsatz des Diffi-Hellman-Verfahrens, bei dem der eigentliche Schlüssel nie hin und her geht. Server und Client übertragen lediglich Daten, die es den | | Einsatz des Diffi-Hellman-Verfahrens, bei dem der eigentliche Schlüssel nie hin und her geht. SSH-Server und -Client übertragen lediglich Daten, die es den Verbindungspartnern ermöglichen, unabhängig voneinander den gleichen Schlüssel zu errechnen. Einem Lauscher nützen diese Daten nichts, da ihm die Werte zum Berechnen des Schlüssels fehlen. Dieses Verfahren zur Schlüsselgenerierung ist wesentlich sicherer, da keiner der beiden Verbindungspartner den Schlüssel alleine bestimmt. | ||
|- | |- | ||
| <b>Datenintegritätsprüfung</b> | | <b>Datenintegritätsprüfung</b> |
Version vom 29. Januar 2009, 20:28 Uhr
Die Secure Shell / SSH ist ein Netzwerkprotokoll, mit dem man sich über eine verschlüsselte Rechnernetz-Verbindung auf einem entfernten Rechner anmelden und dort Programme ausführen kann. Es ist damit eine sichere Alternative zum Konsolenzugang über telnet und gilt als de-facto-Standard für die Remote-Verwaltung von Unix-Systemen. Die Client/Server-Architektur von SSH basiert auf dem Gespann TCP/IP.
Die IANA hat dem Protokoll den TCP-Port 22 zugeordnet.
Das bekannteste Programm zur Nutzung von SSH unter Linux heisst ssh.
Ein SSH-Server für Microsoft Windows ist in der Programmsammlung Cygwin enthalten, die Windows zugleich um eine Unix-Umgebung und viele Befehlszeilenwerzeuge erweitert. Als SSH-Client ist Putty gut geeignet.
Protokollversionen
Es gibt inzwischen zwei Protokollversionen:
- Die ältere wird heute SSH1 genannt.
- Die neuere Version SSH2 bietet weitere Funktionen wie Datenübertragung per SFTP.
Das Netzwerkprotokoll Secure Shell / SSH stellt zur Zeit die SSH-Protokollversionen 1.3, 1.5 und 2 bereit. Gegenüber der Version 2 fallen die Möglichkeiten der Reihe 1 sehr beschränkt aus.
Secure Shell Version 1 | Secure Shell Version 2 | |
---|---|---|
Verschlüsselungsalgorithmen | Dürftiges Angebot (u. a. das unsichere DES oder das sichere aber langsame 3DES, sowie das schnelle und sichere Blowfish). Lücken im Protokoll ermöglichen theoretisch ein Knacken des Protokolls. | Zusätzlich AES und weitere. |
Geschwindigkeit | deutlich langsamer | |
Aushandeln des Schlüssels | Clientseitig erzeugte Schlüssel (engl. keys). Der SSH-Server sendet seinen öffentlichen Schlüssel an den SSH-Client. Dieser erzeugt eine zufällige 156 Bit lange Zahl, verschlüsselt diese mit dem öffentlichen Schlüssel und sendet das Ergebnis an den SSH-Server. Fortan läuft der Datenstrom mit dieser übermittelten Zufallszahl verschlüsselt ab. Schneidet ein Lauscher diese Kommunikation mit, befindet er sich im Besitz des (verschlüsselten) Schlüssels. Mittels Ausprobieren aller Möglichkeiten (Brute Force-Methode) kann es gelingen, den Schlüssel zu ermitteln - im Schnitt dauert das allerdings mehrere Jahre... | Einsatz des Diffi-Hellman-Verfahrens, bei dem der eigentliche Schlüssel nie hin und her geht. SSH-Server und -Client übertragen lediglich Daten, die es den Verbindungspartnern ermöglichen, unabhängig voneinander den gleichen Schlüssel zu errechnen. Einem Lauscher nützen diese Daten nichts, da ihm die Werte zum Berechnen des Schlüssels fehlen. Dieses Verfahren zur Schlüsselgenerierung ist wesentlich sicherer, da keiner der beiden Verbindungspartner den Schlüssel alleine bestimmt. |
Datenintegritätsprüfung | CRC-Verfahren (Cyclic Redundancy Check), welches als betagt und unzuverlässig gilt. | Kryptologische Hash-Summen (Message Authentication Code-Verfahren) |
Multiplexing (dabei übertragen beide Seiten die Daten scheinbar gleichzeitig) |
Läuft besser. |
Tunneln: SSH über HTTP
Auf dem Webrechner läuft ein Werkzeug, das SSH über HTTP verlegt. Solche Remote-Werkzeuge gibt es jede Menge:
- Anyterm - A terminal anywhere - mit einer angestaubten, aber brauchbaren Liste
- Weirdmind