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: 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: Ä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: 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.

LinuxCommunity kaufen

Einzelne Ausgabe
 
Abonnements
 

Ähnliche Artikel

  • Remote-Zugriff über Betriebssystem-Grenzen

    Das GUI-Programm Kontrolpack, jetzt in Version 3.0.0 erhältlich, ermöglicht den Dateizugriff und das Ausführen von Befehlen auf entfernten Rechner über Betriebssystem-Grenzen hinweg.
  • SSH bequem
    Sämtliche SSH-Transaktionen kann man auch über die Konsole ausführen: Aber wer will die langen Kommandos schon von Hand eingeben? Hier hilft Secpanel.
  • Sicher unterwegs im Wireless LAN
    Wireless LAN endet nicht an der Grundstücksgrenze, und gerade in Städten finden sich immer wieder unerwünschte Zaungäste. Wir zeigen Ihnen, wie Sie es Angreifern möglichst schwer machen, in Ihr drahtloses Netz einzudringen.
  • SSH über unzuverlässige Leitungen
    SSH nervt, wenn die WLAN-Verbindung immer wieder abbricht, sich die IP-Adresse ändert, die Datenpakete über GSM nur tröpfeln und man das Getippte erst nach Sekunden zu Gesicht bekommt. Glücklicherweise gibt es AutoSSH und Mosh.
  • Angetestet
Kommentare

Infos zur Publikation

LU 11/2014: VIDEOS BEARBEITEN

Digitale Ausgabe: Preis € 4,95
(inkl. 19% MwSt.)

Mit der Zeitschrift LinuxUser sind Sie als Power-User, Shell-Guru oder Administrator im kleinen Unternehmen monatlich auf dem aktuelle Stand in Sachen Linux und Open Source.

Sie sind sich nicht sicher, ob die Themen Ihnen liegen? Im Probeabo erhalten Sie drei Ausgaben zum reduzierten Preis. Einzelhefte, Abonnements sowie digitale Ausgaben erwerben Sie ganz einfach in unserem Online-Shop.

NEU: DIGITALE AUSGABEN FÜR TABLET & SMARTPHONE

HINWEIS ZU PAYPAL: Die Zahlung ist auch ohne eigenes Paypal-Konto ganz einfach per Kreditkarte oder Lastschrift möglich!       

Tipp der Woche

Schnell Multi-Boot-Medien mit MultiCD erstellen
Schnell Multi-Boot-Medien mit MultiCD erstellen
Tim Schürmann, 24.06.2014 12:40, 0 Kommentare

Wer mehrere nützliche Live-Systeme auf eine DVD brennen möchte, kommt mit den Startmedienerstellern der Distributionen nicht besonders weit: Diese ...

Aktuelle Fragen

Artikelsuche
Erwin Ruitenberg, 09.10.2014 07:51, 1 Antworten
Ich habe seit einige Jahre ein Dugisub LinuxUser. Dann weiß ich das irgendwann ein bestimmtes Art...
Windows 8 startet nur mit externer Festplatte
Anne La, 10.09.2014 17:25, 4 Antworten
Hallo Leute, also, ich bin auf folgendes Problem gestoßen: Ich habe Ubuntu 14.04 auf meiner...
Videoüberwachung mit Zoneminder
Heinz Becker, 10.08.2014 17:57, 0 Antworten
Hallo, ich habe den ZONEMINDER erfolgreich installiert. Das Bild erscheint jedoch nicht,...
internes Wlan und USB-Wlan-Srick
Gerhard Blobner, 04.08.2014 15:20, 2 Antworten
Hallo Linux-Forum: ich bin ein neuer Linux-User (ca. 25 Jahre Windows) und bin von WIN 8 auf Mint...
Server antwortet mit falschem Namen
oin notna, 21.07.2014 19:13, 1 Antworten
Hallo liebe Community, Ich habe mit Apache einen Server aufgesetzt. Soweit, so gut. Im Heimnet...