Home / LinuxUser / 2006 / 04 / Sichere Verbindungen mit SSH

Newsletter abonnieren

Lies uns auf...

Folge LinuxCommunity auf Twitter

Top-Beiträge

Eingedost
(161 Punkte bei 4 Stimmen)
Aufteiler
(161 Punkte bei 4 Stimmen)

Heftarchiv

LinuxUser Heftarchiv

EasyLinux Heftarchiv

Ubuntu User Heftarchiv

Ubuntu User Heftarchiv

Partner-Links:

Das B2B Portal www.Linx.de informiert über Produkte und Dienstleistungen.

Aufmacher Artikel

Tunnelbauer

Sichere Verbindungen mit SSH

01.04.2006 Die Secure Shell SSH kann weit mehr, als ihr Name vermuten lässt: Ob verschlüsselte Tunnel zwischen mehreren Computern oder grafische Anwendungen via LAN – das Mehrzweckwerkzeug lässt kaum Wünsche offen.

Die wohl bekannteste Lösung, um Benutzern über das Netz einen Konsolenzugang auf entfernten Rechnern zu ermöglichen, stellt Telnet dar. So schön dieses Urgestein der Netzwerk-Kommunikation auch ist – es hat einen entscheidenden Nachteil: Alle Daten gehen im Klartext über die Leitung. Wirft ein Angreifer einen Sniffer an, bleibt das streng vertrauliche Admin-Passwort für den Server nicht lange geheim. Zugegeben, ganz so einfach geht es meist nicht, aber die Gefahr besteht. Und da alle gängigen Linux-Distributionen die Secure Shell (SSH) von Haus aus installieren, sollte diese Telnet wo immer möglich ersetzen.

Die Konfigurationsdateien finden von SSH sich in /etc/ssh. Hier gibt es eine Datei für den Server (sshd_config) und den Client (ssh_config). Diese Dateien enthalten eine Fülle von Optionen, für die Sie ausführliche Erläuterungen in den gleichnamigen Manpages finden. Große Anpassungen stehen für Anwender allerdings in der Regel nicht ins Haus. Bei den Default-Werten zeigt sich insbesondere Debian vorbildlich, und auch die anderen bekannten Distributionen stellen sinnvolle Vorgaben bereit.

Funktionsweise

Die Client-Server-Architektur von SSH basiert auf dem Gespann TCP/IP. Auf einem Rechner läuft der SSH-Server (sshd). Dieser lauscht standardmäßig auf TCP-Port 22 auf eingehende Verbindungen. Der Client seinerseits verbindet sich mit dem Server auf diesem Port.

Beim Verbindungsaufbau passiert im Hintergrund einiges: Zunächst verhandeln Server und Client, welche SSH-Protokollversion sie für die Kommunikation verwenden. Derzeit stehen die Protokolle SSH 1 und SSH 2 zur Verfügung, wobei SSH 2 deutlich sicherer ist. Daher kommt es seit einiger Zeit als Standard zum Einsatz. Details – auch zu der verwendeten Verschlüsselung – finden Sie im Kasten "SSH Protokolle".

SSH Protokolle

Derzeit stellt die Secure Shell die Protokollversionen 1.3, 1.5 und 2 bereit. Gegenüber der Version 2 fallen die Möglichkeiten der Reihe 1 sehr beschränkt aus. Besonders das Angebot an Verschlüsselungsalgorithmen ist recht dürftig: Es kommen das unsichere DES oder das sichere, aber relativ langsame Triple-DES (3DES) zum Einsatz. Mit dem Blowfish-Algorithmus steht Ihnen auch hier eine schnelle und – jedenfalls bislang – sichere Verschlüsselungstechnik zur Verfügung. Version 2 bringt neben dem AES-Algorithmus noch weitere mit.

Weiterhin spricht gegen die Versionen aus der Serie 1, das Lücken im Protokoll theoretisch ein Knacken der Verschlüsselung ermöglichen. Hingegen arbeitet Version 2 deutlich langsamer, was sich beim Übertragen großer Datenmengen bemerkbar macht.

Beim Aushandeln des Schlüssels setzt Version 1 auf Client-seitig generierte Schlüssel, neudeutsch auch Keys genannt. Der Server sendet seinen öffentlichen Schlüssel an den Client. Der erzeugt eine zufällige, 256 Bit lange Zahl, verschlüsselt diese mit dem öffentlichen Schlüssel des Servers und sendet das Ergebnis an denselben.

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) Keys. Mittels Ausprobieren aller Möglichkeiten – der sogenannten Brute-Force-Methode – gelingt es dann den Schlüssel zu ermitteln. Im Schnitt dauert dies allerdings mehrere Jahre.

Protokoll-Version 2 setzt ein Diffi-Hellman-Verfahren ein. Bei diesem Verfahren geht der eigentliche Schlüssel nie hin und her; Server und Client übertragen lediglich Daten, die es den Kommunikationspartnern ermöglichen, unabhängig voneinander den gleichen Schlüssel zu errechnen.

Einem Lauscher nützen diese Daten dagegen nichts, da ihm Werte zum Berechnen des Schlüssels fehlen. Dieses Verfahren zum Generieren des Schlüssels bietet deutlich mehr Sicherheit, weil keiner der beiden Kommunikationspartner den Schlüssel alleine bestimmt.

Zu den weiteren Verbesserungen gegenüber Version 1 gehört, dass die Software zum Prüfen der Integrität der Daten nicht mehr das betagte und unzuverlässigen CRC-Verfahren (Cyclic Redundancy Check) überlässt. Stattdessen verwendet Version 2 kryptologische Hash-Summen (Message-Authentication-Code-Verfahren). Auch das Multiplexing läuft nun besser. Dabei übertragen beide Seiten die Daten scheinbar gleichzeitige.

Alle Beispiele in diesem Artikel beziehen sich auf Protokoll-Version 2, auch wenn einiges mit Version 1 ebenfalls funktioniert.

Im nächsten Schritt handeln Server und Client den Algorithmus aus, gefolgt vom Schlüssel, den beide für diesen Datentransfer verwenden. Der Schlüssel gilt einmalig für diese Kommunikation und beide Seiten vernichten ihn nach Verbindungsende. Für längere Verbindungen ändert sich der Schlüssel zusätzlich in regelmäßigen Abständen, standardmäßig stündlich.

Ein erstes Login

Am einfachsten melden Sie sich mit der klassischen Benutzername/Passwort-Methode an. Dabei verwendet der SSH-Client automatisch Ihren Benutzername als Anmeldename auf dem entfernten Rechner. Beim ersten Login kennt der Client den Host-Key des Servers noch nicht und verlangt daher eine Bestätigung, dass Sie sich wirklich mit diesem Rechner verbinden wollen. Erst nach einer positiven Antwort importiert das Programm den so genannten Fingerprint (Fingerabdruck, Abbildung 1).

Abbildung 1

Abbildung 1: Beim ersten Login importiert SSH den Host-Key des entfernten Rechners.

Dies ist ein guter Moment, den Administrator des entfernten Rechners zu kontaktieren und den Key-Fingerprint abzugleichen. So verhindern Sie sogenannte Man-in-the-Middle-Attacken. Bei diesen leitet ein Angreifer Ihren Netzwerkverkehr auf seinen Rechner um und täuscht Ihnen ein entsprechendes Login vor.

Bestätigen Sie in einem solchen Fall unbedacht und geben Ihr Passwort ein, befindet sich der Angreifer im Besitz Ihres (verschlüsselten) Passworts. Aus diesem Grund ist hier Vorsicht angebracht. Ändert sich der Host-Key, dann verweigert der Client bei einem späteren Login die Verbindungsaufnahme. Abbildung 2 zeigt die entsprechende Ausgabe des SSH-Clients.

Abbildung 2

Abbildung 2: Ändert sich der Host-Key, verweigert Ihnen der SSH-Client den Zugang.

Hier hilft nur, den betreffenden Fingerprint aus $HOME/.ssh./known_hosts zu löschen und nach Rücksprache mit dem betreffenden Admin den neuen Key zu akzeptieren. Sie konfigurieren dieses Verhalten über die Variable StrictHostKeyChecking in ssh_config.

Möchten Sie sich auf dem entfernten Rechner nicht unter Ihrem derzeitigen Benutzernamen, sondern als ein anderer Benutzer anmelden, verwenden Sie die Option -l Login-Name. So meldet Sie etwa die Zeile ssh -l tuppes sector als Benutzer tuppes auf dem Remote-Rechner an. Alternativ akzeptiert SSH auch die folgende Syntax: ssh tuppes@sector. Um lediglich einen einzelnen Befehl auf dem anderen Rechner auszuführen, hängen Sie diesen einfach hinten an (Listing 1).

Listing 1

jha@scotti:~$ ssh sector "ls -l"
Password:
insgesamt 52
drwxr-xr-x   3 tuppes users  4096 2005-08-26 12:38 .
drwxr-xr-x  16 root   root   4096 2005-09-07 13:47 ..
-rw-rw-r--   1 tuppes users   266 2005-04-12 12:00 .alias

Falls es Ihnen lästig fällt, stets Ihr Passwort einzugeben, können Sie auf Public-Key-Authentication zurückgreifen. Hier kommen Verschlüsselungsverfahren zum Einsatz, wie sie auch von GnuPG bekannt sind. Um diese Methode zu verwenden, generieren Sie mit ssh-keygen als erstes ein Schlüsselpaar: ssh-keygen -b 1024 -t rsa. Die Software meldet daraufhin, dass sie einen Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel nach dem RSA-Verfahren erzeugt hat. Die Abfrage nach dem Passwort bestätigen Sie zweimal mit [Enter]. Anschließend signalisiert das Programm, in welchen Dateien es die Daten ablegt, und zeigt dann den Fingerprint des neuen Schlüssels an.

In diesem Beispiel generiert die Software ein RSA-Schlüsselpaar (Option -t rsa) von 1024 Bit Länge (Option -b 1024) generiert. Einen RSA-Key eignet sich für den Einsatz mit beiden Protokollversionen. Die Key-Länge sollte aus Sicherheitsgründen 1024 Bit nicht unterschreiten. Wollen Sie auf Nummer sicher gehen, verwenden Sie einen Schlüssel mit 2048 Bit Länge. Der gilt nach derzeitigem Wissensstand bis etwa zum Jahr 2020 als sicher. Die Key-Länge hat übrigens keinen Einfluss auf die Geschwindigkeit des Datentransfers, da das Programm die Daten ja nicht mit diesem Key verschlüsselt.

Im nächsten Schritt kopieren Sie den öffentlichen Schlüssel auf den Zielrechner in die Datei $HOME/.ssh/authorized_keys, beispielsweise via Diskette:

mount /media/floppy
cat /media/floppy/id.rsa.pub >> $HOME/.ssh/authorized_keys
umount /media/floppy

Keinesfalls sollten Sie den Key mit einem unsicheren Verfahren wie übertragen, etwa per E-Mail oder via FTP. Das unspektakuläre Login mit dem neuen Schlüssel zeigt Abbildung 3.

Abbildung 3

Abbildung 3: Mit Public-Key-Authentifizierung verläuft der Login komfortabler, da ohne Passwort-Abfrage.

Schlüssel für interaktive Sitzungen sollten Sie mit einem Passwort versehen. Ansonsten ermöglichen Sie jedem mit einem physikalischen Zugang zu Ihrem Rechner, sich unter Ihrem Namen am entfernten Rechner anzumelden. Das passwortfreie Login mittels Schlüssel kommt häufig bei automatisiertem Kopieren von Dateien auf einen Remote-Rechner zum Einsatz.

Wenn Sie beispielsweise jeden Abend ein Backup fahren, dass Sie automatisch auf einen anderen Rechner kopieren möchten, eignen sich Keys ohne Passwort bestens. Wäre der Schlüssel mit einem Passwort versehen, müssten Sie dieses bei jedem Kopiervorgang eingeben – von automatisch keine Spur mehr.

Tip a friend    Druckansicht Bookmark and Share
Kommentare

1053 Hits
Wertung: 0 Punkte (0 Stimmen)

Schlecht Gut

Infos zur Publikation

Infos zur Publikation

LinuxUser 05/2014

Aktuelle Ausgabe kaufen:

Heft als PDF kaufen

LinuxUser erscheint monatlich und kostet in der Nomedia-Ausgabe EUR 5,95 und mit DVD EUR 8,50. Weitere Informationen zum Heft finden Sie auf der LinuxUser-Homepage.

Im LinuxUser-Probeabo erhalten Sie drei Ausgaben für 3 Euro. Das Jahresabo (ab EUR 60,60) können Sie im Medialinx-Shop bestellen.

Tipp der Woche

Bilder vergleichen mit diffimg
Bilder vergleichen mit diffimg
Tim Schürmann, 01.04.2014 12:40, 1 Kommentare

Das kleine Werkzeug diffimg kann zwei (scheinbar) identische Bilder miteinander vergleichen und die Unterschiede optisch hervorheben. Damit lassen sich nicht nur Rätsel a la „Orignial und Fäls...

Aktuelle Fragen

programm suche
Hans-Joachim Köpke, 13.04.2014 10:43, 8 Antworten
suche noch programme die zu windows gibt, die auch unter linux laufen bzw sich ähneln sozusagen a...
Funknetz (Web-Stick)
Hans-Joachim Köpke, 04.04.2014 07:31, 2 Antworten
Bei Windows7 brauche ich den Stick nur ins USB-Fach schieben dann erkennt Windows7 Automatisch, a...
Ubuntu 13.10 überschreibt immer Windows 8 Bootmanager
Thomas Weiss, 15.03.2014 19:20, 8 Antworten
Hallo Leute, ich hoffe das ich richtig bin. Ich habe einen Dell Insipron 660 Ich möchte gerne Ub...
USB-PTP-Class Kamera wird nicht erkannt (Windows-only)
Wimpy *, 14.03.2014 13:04, 15 Antworten
ich habe meiner Frau eine Digitalkamera, AGFA Optima 103, gekauft und wir sind sehr zufrieden dam...
Treiber
Michael Kristahn, 12.03.2014 08:28, 5 Antworten
Habe mir ein Scanner gebraucht gekauft von Canon CanoScan LiDE 70 kein Treiber wie bekomme ich de...