110.3 Lektion 1

110.3 Lektion 1

Zertifikat:

LPIC-1

Version:

5.0

Thema:

110 Sicherheit

Lernziel:

110.3 Daten durch Verschlüsselung schützen

Lektion:

1 von 2

Einführung

Die Sicherung von Daten durch Verschlüsselung ist in vielen Bereichen moderner Systemadministration von größter Bedeutung — gerade wenn es um den Fernzugriff auf Systeme geht. Im Gegensatz zu unsicheren Lösungen wie telnet, rlogin oder FTP wurde das Protokoll SSH (Secure Shell) mit Blick auf die Sicherheit entwickelt. Mit Hilfe der Public-Key-Kryptographie authentifiziert es sowohl die Hosts als auch die Benutzer und verschlüsselt den gesamten nachfolgenden Informationsaustausch. Darüber können Sie mit SSH auch Porttunnel aufbauen, durch die ein nicht verschlüsseltes Protokoll Daten über eine verschlüsselte SSH-Verbindung überträgt. Die aktuelle, empfohlene Version des SSH-Protokolls ist 2.0. OpenSSH ist eine freie Open-Source-Implementierung des SSH-Protokolls.

Diese Lektion behandelt die grundlegende OpenSSH-Client-Konfiguration sowie die Rolle der OpenSSH-Server-Hostschlüssel. Das Konzept der SSH-Porttunnel behandeln wir ebenfalls. Wir nutzen zwei Maschinen mit der folgenden Konfiguration:

Rolle Betriebssystem IP-Adresse Hostname Benutzer

Client

Debian GNU/Linux 10 (buster)

192.168.1.55

debian

carol

Server

openSUSE Leap 15.1

192.168.1.77

halof

ina

Grundlegende Konfiguration und Verwendung von OpenSSH-Client

Obwohl OpenSSH-Server und -Client in separaten Paketen geliefert werden, steht normalerweise ein Metapaket bereit, das beide gleichzeitig installiert. Mit dem Befehl ssh bauen Sie eine Fernsitzung mit dem SSH-Server auf. Dazu geben Sie den Benutzer, mit dem Sie sich auf dem entfernten Rechner verbinden, und die IP-Adresse oder den Hostnamen des entfernten Rechners an. Wenn Sie sich zum ersten Mal mit einem entfernten Rechner verbinden, erhalten Sie eine Meldung wie diese:

carol@debian:~$ ssh ina@192.168.1.77
The authenticity of host '192.168.1.77 (192.168.1.77)' can't be established.
ECDSA key fingerprint is SHA256:5JF7anupYipByCQm2BPvDHRVFJJixeslmppi2NwATYI.
Are you sure you want to continue connecting (yes/no)?

Nachdem Sie yes eingegeben und die Eingabetaste gedrückt haben, werden Sie nach dem Passwort des entfernten Benutzers gefragt. Bei erfolgreicher Eingabe erhalten Sie eine Warnmeldung und werden dann beim entfernten Rechner angemeldet:

Warning: Permanently added '192.168.1.77' (ECDSA) to the list of known hosts.
Password:
Last login: Sat Jun 20 10:52:45 2020 from 192.168.1.4
Have a lot of fun...
ina@halof:~>

Die Meldungen sind weitgehend selbsterklärend: Da Sie zum ersten Mal eine Verbindung zum entfernten Server 192.168.1.77 herstellen, kann seine Authentizität nicht anhand einer Datenbank überprüft werden. Daher stellt der entfernte Server einen ECDSA key fingerprint seines öffentlichen Schlüssels zur Verfügung (unter Verwendung der SHA256-Hashfunktion). Sobald Sie die Verbindung akzeptierten, wird der öffentliche Schlüssel des entfernten Servers der Datenbank known hosts hinzugefügt, was die Authentifizierung des Servers für zukünftige Verbindungen ermöglicht. Diese Liste der öffentlichen Schlüssel von known hosts wird in der Datei known_hosts gespeichert, die sich in ~/.ssh befindet:

ina@halof:~> exit
logout
Connection to 192.168.1.77 closed.
carol@debian:~$ ls .ssh/
known_hosts

Sowohl .ssh als auch known_hosts wurden nach dem Aufbau der ersten Fernverbindung angelegt. ~/.ssh ist das Standardverzeichnis für benutzerspezifische Konfigurations- und Authentifizierungsinformationen.

Note

Mit ssh können Sie auch nur einen einzigen Befehl auf dem entfernten Rechner ausführen und dann zu Ihrem lokalen Terminal zurückkehren (z.B.: ssh ina@halof ls).

Wenn Sie auf dem lokalen und dem entfernten Rechner denselben Benutzer verwenden, brauchen Sie den Benutzernamen beim Aufbau der SSH-Verbindung nicht anzugeben. Sind Sie zum Beispiel als Benutzer carol auf debian angemeldet und wollen sich mit halof ebenfalls als Benutzer carol verbinden, geben Sie einfach ssh 192.168.1.77 oder ssh halof (wenn der Name aufgelöst werden kann) ein:

carol@debian:~$ ssh halof
Password:
Last login: Wed Jul  1 23:45:02 2020 from 192.168.1.55
Have a lot of fun...
carol@halof:~>

Wenn Sie nun eine neue Fernverbindung mit einem Rechner herstellen, der zufällig dieselbe IP-Adresse wie halof hat (was häufig vorkommt, wenn Sie in Ihrem LAN DHCP verwenden), erhalten Sie eine Warnung vor einem möglichen Man-in-the-Middle Angriff:

carol@debian:~$ ssh john@192.168.1.77
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:KH4q3vP6C7e0SEjyG8Wlz9fVlf+jmWJ5139RBxBh3TY.
Please contact your system administrator.
Add correct host key in /home/carol/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/carol/.ssh/known_hosts:1
  remove with:
  ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77"
ECDSA host key for 192.168.1.77 has changed and you have requested strict checking.
Host key verification failed.

Da Sie es nicht mit einem Man-in-the-Middle-Angriff zu tun haben, fügen Sie den Fingerabdruck des öffentlichen Schlüssels des neuen Hosts gefahrlos zu .ssh/known_hosts hinzu. Wie in der Meldung angegeben, können Sie zunächst mit ssh-keygen -f "/home/carol/.ssh/known_hosts" -R "192.168.1.77" den offending Schlüssel entfernen (alternativ löschen Sie mit ssh-keygen -R 192.168.1.77 alle Schlüssel, die zu 192.168.1.77 gehören, aus ~/.ssh/known_hosts). Danach können Sie eine Verbindung zu dem neuen Host herstellen.

Schlüsselbasierte Logins

Sie können Ihren SSH-Client so einrichten, dass er bei der Anmeldung keine Passwörter, sondern stattdessen öffentliche Schlüssel verwendet. Dies ist die bevorzugte Methode, da es wesentlich sicherer ist, sich über SSH mit einem entfernten Server zu verbinden. Dafür ist zunächst ein Schlüsselpaar auf dem Client-Rechner zu erstellen, und zwar mit ssh-keygen und der Option -t, die den gewünschten Verschlüsselungstyp angibt (in unserem Fall Elliptic Curve Digital Signature Algorithm). Es folgen Fragen nach dem Pfad, in dem das Schlüsselpaar gespeichert werden soll (~/.ssh/ ist praktisch und auch der Standardspeicherort), und nach einer Passphrase. Diese ist zwar optional, wird aber dringend empfohlen.

carol@debian:~/.ssh$ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/carol/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/carol/.ssh/id_ecdsa.
Your public key has been saved in /home/carol/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:tlamD0SaTquPZYdNepwj8XN4xvqmHCbe8g5FKKUfMo8 carol@debian
The key's randomart image is:
+---[ECDSA 256]---+
|      .          |
|     o .         |
|    = o o        |
|     B *         |
|    E B S o      |
|     o & O       |
|      @ ^ =      |
|     *.@ @.      |
|    o.o+B+o      |
+----[SHA256]-----+
Note

Mit der Option -b beim Erzeugen des Schlüsselpaares mit ssh-keygen geben Sie die Schlüsselgröße in Bits an (z.B. ssh-keygen -t ecdsa -b 521).

Der vorangegangene Befehl hat zwei neue Dateien in Ihrem Verzeichnis ~/.ssh erzeugt:

carol@debian:~/.ssh$ ls
id_ecdsa  id_ecdsa.pub  known_hosts
id_ecdsa

Privater Schlüssel

id_ecdsa.pub

Öffentlicher Schlüssel

Note

Bei der asymmetrischen Kryptografie (auch Public-Key-Kryptografie genannt) sind der öffentliche und der private Schlüssel mathematisch so aufeinander bezogen, dass das, was mit dem einen verschlüsselt wird, nur mit dem anderen entschlüsselt werden kann.

Nun fügen Sie Ihren öffentlichen Schlüssel zur Datei ~/.ssh/authorized_keys des Benutzers hinzu, mit dem Sie sich auf dem entfernten Rechner anmelden wollen — wenn das Verzeichnis ~/.ssh noch nicht existiert, erstellen Sie es zunächst. Es gibt verschiedene Methoden, Ihren öffentlichen Schlüssel auf den entfernten Server kzu opieren: mit einem USB-Stick, mit dem Befehl scp — der die Datei per SSH überträgt — oder indem Sie den Inhalt Ihres öffentlichen Schlüssels per cat ausgeben und ihn wie folgt per ssh übertragen und einfügen:

carol@debian:~/.ssh$ cat id_ecdsa.pub |ssh ina@192.168.1.77 'cat >> .ssh/authorized_keys'
Password:

Sobald Ihr öffentlicher Schlüssel der Datei authorized_keys auf dem entfernten Host hinzugefügt wurde, können Sie beim Versuch, eine neue Verbindung aufzubauen, mit zwei Szenarien rechnen:

  • Haben Sie bei der Erstellung des Schlüsselpaars keine Passphrase angegeben, erfolgt die Anmeldung automatisch. Zwar ist diese Methode bequem, kann je nach Situation aber unsicher sein:

    carol@debian:~$ ssh ina@192.168.1.77
Last login: Thu Jun 25 20:31:03 2020 from 192.168.1.55
Have a lot of fun...
ina@halof:~>

  • Haben Sie bei der Erstellung des Schlüsselpaares eine Passphrase angegeben, müssen Sie diese bei jeder Verbindung eingeben, ähnlich wie ein Passwort. Abgesehen vom öffentlichen Schlüssel bietet diese Methode eine zusätzliche Sicherheitsebene in Form einer Passphrase und ist daher als sicherer anzusehen. In Sachen Bequemlichkeit ist es jedoch dasselbe, wie bei jedem Verbindungsaufbau ein Passwort einzugeben. Wenn Sie keine Passphrase verwenden und jemand an Ihre private SSH-Schlüsseldatei gelangt, hätte er Zugang zu jedem Server, auf dem Ihr öffentlicher Schlüssel hinterlegt ist.

    carol@debian:~/.ssh$ ssh ina@192.168.1.77
Enter passphrase for key '/home/carol/.ssh/id_ecdsa':
Last login: Thu Jun 25 20:39:30 2020 from 192.168.1.55
Have a lot of fun...
ina@halof:~>

Es gibt jedoch ein Verfahren, das Sicherheit und Bequemlichkeit kombiniert: SSH-Authentifizierungsagenten (ssh-agent). Der Authentifizierungsagent muss seine eigene Shell erzeugen und hält Ihre privaten Schlüssel — für die Authentifizierung mit öffentlichen Schlüsseln — für den Rest der Sitzung im Speicher. Lassen Sie uns sehen, wie das im Detail funktioniert:

  1. Starten Sie mit ssh-agent eine neue Bash-Shell:

    carol@debian:~/.ssh$ ssh-agent /bin/bash
carol@debian:~/.ssh$

  2. Legen Sie mit ssh-add Ihren privaten Schlüssel in einem sicheren Bereich des Speichers ab. Wenn Sie bei der Erzeugung des Schlüsselpaares eine Passphrase angegeben haben — was für zusätzliche Sicherheit empfohlen wird — werden Sie danach gefragt:

    carol@debian:~/.ssh$ ssh-add
Enter passphrase for /home/carol/.ssh/id_ecdsa:
Identity added: /home/carol/.ssh/id_ecdsa (carol@debian)

    Sobald Ihre Identität hinzugefügt wurde, können Sie sich bei jedem Remote-Server anmelden, auf dem Ihr öffentlicher Schlüssel hinterlegt ist, ohne Ihre Passphrase erneut eingeben zu müssen. Auf modernen Desktops ist es üblich, diesen Befehl beim Hochfahren des Rechners auszuführen, da er im Speicher bleibt, bis der Computer heruntergefahren wird (oder der Schlüssel vorzeitig manuell entfernt wird).

Sehen wir uns zum Abschluss dieses Abschnitts die vier Public-Key-Algorithmen an, die ssh-keygen unterstützt:

RSA

Benannt nach seinen Schöpfern Ron Rivest, Adi Shamir und Leonard Adleman, wurde es 1977 veröffentlicht. Es gilt als sicher und ist auch heute noch häufig im Einsatz. Die Mindestschlüsselgröße beträgt 1024 Bit (Standard ist 2048).

DSA

Der Digital Signature Algorithm hat sich als unsicher erwiesen und gilt seit OpenSSH 7.0 als veraltet. DSA-Schlüssel haben eine Länge von genau 1024 Bit.

ecdsa

Der Elliptic Curve Digital Signature Algorithm ist eine Verbesserung des DSA und gilt daher als sicherer. Er verwendet elliptische Kurven-Kryptographie. Die ECDSA-Schlüssellänge bestimmen Sie über eine der drei möglichen elliptischen Kurvengrößen in Bits: 256, 384 oder 521.

ed25519

Der Edwards-curve Digital Signature Algorithm ist eine Implementierung von EdDSA mit der stärkeren 25519 Kurve. Sie gilt als die sicherste von allen. Alle Ed25519-Schlüssel haben eine feste Länge von 256 Bit.

Note

Wenn Sie ssh-keygen ohne -t-Spezifikation aufrufen, erzeugt es standardmäßig ein RSA-Schlüsselpaar.

Die Rolle von OpenSSH Server Host Keys

Das globale Konfigurationsverzeichnis für OpenSSH befindet sich im Verzeichnis /etc:

halof:~ # tree /etc/ssh
/etc/ssh
├── moduli
├── ssh_config
├── ssh_host_dsa_key
├── ssh_host_dsa_key.pub
├── ssh_host_ecdsa_key
├── ssh_host_ecdsa_key.pub
├── ssh_host_ed25519_key
├── ssh_host_ed25519_key.pub
├── ssh_host_rsa_key
├── ssh_host_rsa_key.pub
└── sshd_config

0 directories, 11 files

Neben moduli und den Konfigurationsdateien für Client (ssh_config) und Server (sshd_config) finden Sie vier Schlüsselpaare — eines für jeden unterstützten Algorithmus --, die bei der Installation des OpenSSH-Servers erzeugt werden. Wie bereits erwähnt, nutzt der Server diese Host Keys, um sich bei Bedarf gegenüber Clients zu identifizieren. Ihr Namensmuster lautet wie folgt:

Privater Schlüssel

Präfix ssh_host_ + Algorithmus + Suffix key (z.B.: ssh_host_rsa_key)

Öffentlicher Schlüssel (oder Fingerprint des öffentlichen Schlüssels)

Präfix ssh_host_ + Algorithmus + Suffix key.pub (z.B.: ssh_host_rsa_key.pub)

Note

Ein Fingerprint entsteht durch Anwendung einer kryptografischen Hashfunktion auf einen öffentlichen Schlüssel. Da Fingerabdrücke kürzer sind als die Schlüssel, auf die sie sich beziehen, vereinfachen sie bestimmte Aufgaben der Schlüsselverwaltung.

Die Berechtigungen für die Dateien mit den privaten Schlüsseln sind 0600 oder -rw-------: nur lesbar und schreibbar für den Eigentümer (root). Demgegenüber sind alle öffentlichen Schlüsseldateien auch für die Mitglieder der Eigentümergruppe und alle anderen lesbar (0644 oder -rw-r—​r--):

halof:~ # ls -l /etc/ssh/ssh_host_*
-rw------- 1 root root 1381 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key
-rw-r--r-- 1 root root  605 Dec 21 20:35 /etc/ssh/ssh_host_dsa_key.pub
-rw------- 1 root root  505 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r-- 1 root root  177 Dec 21 20:35 /etc/ssh/ssh_host_ecdsa_key.pub
-rw------- 1 root root  411 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key
-rw-r--r-- 1 root root   97 Dec 21 20:35 /etc/ssh/ssh_host_ed25519_key.pub
-rw------- 1 root root 1823 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key
-rw-r--r-- 1 root root  397 Dec 21 20:35 /etc/ssh/ssh_host_rsa_key.pub

Sie sehen die Fingerabdrücke der Schlüssel, indem Sie ssh-keygen die Option -l mitgeben — mit -f geben Sie den Pfad der Schlüsseldatei an:

halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)
halof:~ # ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)

Um den Fingerabdruck des Schlüssels detaillierter zu betrachten, fügen Sie den Schalter -v wie folgt hinzu:

halof:~ # ssh-keygen -lv -f /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:8cnPrinC49ZHc+/9Ai5pV+1JfZ4WBRZhd3rDOsc2zlA root@halof (ED25519)
+--[ED25519 256]--+
|              +oo|
|             .+o.|
|        .    ..E.|
|         + .  +.o|
|        S +  + *o|
|          ooo Oo=|
|     . . . =o+.==|
|      = o =oo o=o|
|     o.o +o+..o.+|
+----[SHA256]-----+

SSH-Porttunnel

OpenSSH bietet eine sehr mächtige Weiterleitungsfunktion, die den Verkehr an einem Quellport durch einen SSH-Prozess tunnelt (und verschlüsselt) und ihn dann an einen Port auf einem Zielhost weiterleitet. Dieser Mechanismus ist als Port Tunnelling oder Port Forwarding bekannt und bietet große Vorteile:

  • Firewalls umgehen, um auf Ports auf entfernten Hosts zuzugreifen.

  • Zugriff von außen auf einen Host in Ihrem privaten Netzwerk.

  • Verschlüsselung für den gesamten Datenaustausch.

Grob kann man zwischen lokalem und entferntem Port Tunnelling unterscheiden.

Lokaler Porttunnel

Sie bestimmen lokal einen Port, über den der Datenverkehr an den Zielhost geleitet wird — über den dazwischen liegenden SSH-Prozess. Der SSH-Prozess läuft auf dem lokalen Host oder auf einem entfernten Server. Wollen Sie zum Beispiel eine Verbindung zu www.gnu.org per SSH über Port 8585 auf Ihrem lokalen Rechner tunneln, sieht das etwa so aus:

carol@debian:~$ ssh -L 8585:www.gnu.org:80 debian
carol@debian's password:
Linux debian 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
(...)
Last login: Sun Jun 28 13:47:27 2020 from 127.0.0.1

Zur Erklärung: Mit dem Schalter -L geben wir den lokalen Port 8585 an, um uns mit dem http Port 80 auf www.gnu.org zu verbinden. Dazu nutzen wir den SSH-Prozess, der auf debian läuft — unser localhost. Wir hätten auch ssh -L 8585:www.gnu.org:80 localhost mit dem gleichen Effekt schreiben können. Wenn Sie nun http://localhost:8585 in einem Webbrowser aufrufen, werden Sie zu www.gnu.org weitergeleitet. Zu Demonstrationszwecken nutzen wir lynx (einen Webbrowser im Textmodus):

carol@debian:~$ lynx http://localhost:8585
(...)
  * Back to Savannah Homepage
     * Not Logged in
     * Login
     * New User
     * This Page
     * Language
     * Clean Reload
     * Printer Version
     * Search
     * _
(...)

Um dieselbe Verbindung über einen SSH-Prozess herzustellen, der auf halof läuft, lautet das Vorgehen:

carol@debian:~$ ssh -L 8585:www.gnu.org:80 -Nf ina@192.168.1.77
Enter passphrase for key '/home/carol/.ssh/id_ecdsa':
carol@debian:~$
carol@debian:~$ lynx http://localhost:8585
(...)
  * Back to Savannah Homepage
     * Not Logged in
     * Login
     * New User
     * This Page
     * Language
     * Clean Reload
     * Printer Version
     * Search
     * _
(...)

Es ist wichtig, die folgenden drei Details des Befehls beachten:

  • Dank der Option -N haben wir uns nicht in halof eingeloggt, sondern stattdessen die Portweiterleitung durchgeführt.

  • Die Option f weist SSH an, im Hintergrund zu laufen.

  • Wir haben den Benutzer ina für die Weiterleitung angegeben: ina@192.168.1.77

Entfernte Porttunnel

Beim Remote Port Tunnelling (oder Reverse Port Forwarding) wird der auf einem Port des Remote-Servers ankommende Verkehr an den SSH-Prozess weitergeleitet, der auf Ihrem lokalen Rechner läuft, und von dort an den angegebenen Port des Zielservers (der auch Ihr lokaler Rechner sein kann). Um beispielsweise einem Benutzer außerhalb Ihres Netzwerks über Port 8585 des SSH-Servers, der auf halof (192.168.1.77) läuft, Zugriff auf den bei Ihnen lokal laufenden Apache-Webserver zu geben, lautet der Befehl:

carol@debian:~$ ssh -R 8585:localhost:80 -Nf ina@192.168.1.77
Enter passphrase for key '/home/carol/.ssh/id_ecdsa':
carol@debian:~$

Jetzt sieht jeder, der auf dem Host halof auf Port 8585 eine Verbindung zu localhost herstellt, die Standard-Homepage von Debians Apache2:

carol@halof:~$ lynx localhost:8585
(...)
                                                                 Apache2 Debian Default Page: It works (p1 of 3)
   Debian Logo Apache2 Debian Default Page
   It works!

   This is the default welcome page used to test the correct operation of the Apache2 server after
   installation on Debian systems. If you can read this page, it means that the Apache HTTP server
   installed at this site is working properly. You should replace this file (located at
   /var/www/html/index.html) before continuing to operate your HTTP server.
(...)

Damit der entfernte Rechner halof einen Tunnel mit all seinen Netzwerkschnittstellen auf einem bestimmten Port erstellen kann, muss zuerst sichergestellt werden, dass der Parameter GatewayPorts yes in der Datei sshd_config konfiguriert ist; so funktioniert die Zuordnung zu allen Schnittstellen. Standardmäßig ist der Parameter auf no gesetzt, was dazu führt, dass nur die Schnittstelle localhost dem Tunnel zugeordnet wird.

carol@debian:~$ ssh -R 0.0.0.0:8585:localhost:80 -Nf ina@192.168.1.77
Enter passphrase for key '/home/carol/.ssh/id_ecdsa':
carol@debian:~$

Nun wird jeder, der eine Verbindung zu halof auf Port 8585 auf einer beliebigen IP-Adresse herstellt, die Standard-Homepage von Debians Apache2 sehen:

carol@debian:~$ lynx 192.168.1.77:8585
(...)
                                                                 Apache2 Debian Default Page: It works (p1 of 3)
   Debian Logo Apache2 Debian Default Page
   It works!
(...)
Note

Es gibt noch eine dritte, komplexere Art der Portweiterleitung, die wir in dieser Lektion nicht behandeln: dynamische Portweiterleitung. Statt mit einem einzigen Port zu interagieren, nutzt diese Art der Weiterleitung verschiedene TCP-Kommunikationen über eine Reihe von Ports.

X11 Tunnel

Mit dem Wissen über Porttunnel, kommen wir abschließend zu X11 Tunnelling (auch bekannt als X11 Forwarding). Durch einen X11-Tunnel wird das X Window System auf dem entfernten Rechner an Ihren lokalen Rechner geleitet. Dazu übergeben Sie ssh einfach die Option -X:

carol@debian:~$ ssh -X ina@halof
...

Sie können nun eine grafische Anwendung wie den Webbrowser firefox mit folgendem Ergebnis starten: Die Anwendung wird auf dem entfernten Server ausgeführt, aber die Anzeige wird an Ihren lokalen Host weitergeleitet.

Wenn Sie stattdessen eine neue SSH-Sitzung mit der Option -x starten, ist das X11 Forwarding deaktiviert. Versuchen Sie nun, firefox zu starten, erhalten Sie eine Fehlermeldung wie die folgende:

carol@debian:~$ ssh -x ina@halof
carol@192.168.0.106's password:
(...)
ina@halof:~$ firefox

(firefox-esr:1779): Gtk-WARNING **: 18:45:45.603: Locale not supported by C library.
	Using the fallback 'C' locale.
Error: no DISPLAY environment variable specified
Note

Die drei Konfigurationsanweisungen, die sich auf die lokale Portweiterleitung, die Weiterleitung von entfernten Ports und die X11-Weiterleitung beziehen, sind AllowTcpForwarding, GatewayPorts und X11Forwarding. Für weitere Informationen geben Sie man ssh_config und/oder man sshd_config ein.

Geführte Übungen

  1. Melden Sie sich als Benutzer sonya auf Ihrem Client-Rechner an und führen Sie die folgenden SSH-Aufgaben auf dem entfernten Server halof aus:

    • Führen Sie den Befehl aus, um den Inhalt von ~/.ssh als Benutzer serena auf dem entfernten Rechner aufzulisten. Kehren Sie dann zu Ihrem lokalen Terminal zurück.

    • Melden Sie sich als Benutzer serena auf dem entfernten Rechner an.

    • Melden Sie sich als Benutzer sonya auf dem entfernten Rechner an.

    • Löschen Sie alle Schlüssel, die zu halof gehören, aus Ihrer lokalen Datei ~/.ssh/known_hosts.

    • Erstellen Sie auf Ihrem Client-Rechner ein Schlüsselpaar ecdsa mit 256 Bit.

    • Erstellen Sie auf Ihrem Client-Rechner ein Schlüsselpaar ed25519 mit 256 Bit.

  2. Führen Sie die folgenden Schritte in der richtigen Reihenfolge aus, um eine SSH-Verbindung mit dem SSH-Authentifizierungsagenten herzustellen:

    • Starten Sie auf dem Client eine neue Bash-Shell für den Authentifizierungsagenten mit ssh-agent /bin/bash.

    • Erstellen Sie auf dem Client ein Schlüsselpaar mit ssh-keygen.

    • Auf dem Client ergänzen Sie Ihren privaten Schlüssel mit ssh-add in einem sicheren Bereich des Speichers.

    • Fügen Sie den öffentlichen Schlüssel Ihres Clients in die Datei ~/.ssh/authorized_keys des Benutzers ein, mit dem Sie sich auf dem entfernten Rechner anmelden wollen.

    • Falls noch nicht vorhanden, erstellen Sie ~/.ssh für den Benutzer, mit dem Sie sich auf dem Server anmelden wollen.

    • Verbinden Sie sich mit dem entfernten Server.

      Die richtige Reihenfolge ist:

      Schritt 1:

      Schritt 2:

      Schritt 3:

      Schritt 4:

      Schritt 5:

      Schritt 6:

  3. Welche Option und welche Anweisung werden bei Port Forwarding für die folgenden Tunneltypen verwendet?

    Tunneltyp Option Anweisung

    Lokal

    Remote oder Reverse

    X

  4. Sie geben den Befehl ssh -L 8888:localhost:80 -Nf ina@halof in das Terminal Ihres Client-Rechners ein. Auf dem Client-Rechner rufen Sie mit einem Browser http://localhost:8888 auf. Was werden Sie erhalten?

Offene Übungen

  1. Bezüglich der SSH-Sicherheitsrichtlinien:

    • Welche Anweisung setzen Sie in /etc/ssh/sshd_config, um root-Logins zu ermöglichen?

    • Welche Anweisung setzen Sie in /etc/ssh/sshd_config, um nur einen lokalen Account anzugeben, der SSH-Verbindungen akzeptiert?

  2. Sie nutzen denselben Benutzer auf dem Client und dem Server. Welchen ssh-Befehl geben Sie ein, um den öffentlichen Schlüssel des Clients auf den Server zu übertragen, so dass Sie sich über die Authentifizierung mit öffentlichem Schlüssel anmelden können?

  3. Erstellen Sie zwei lokale Porttunnel mit einem einzigen Befehl, der die lokalen unprivilegierten Ports 8080 und 8585 über den entfernten Server halof an die Websites www.gnu.org bzw. www.melpa.org weiterleitet. Verwenden Sie den Benutzer ina auf dem entfernten Server — und vergessen Sie nicht den Schalter -Nf.

Zusammenfassung

In dieser Lektion haben wir OpenSSH 2 besprochen, das das Secure Shell-Protokoll zur Verschlüsselung der Kommunikation zwischen Server und Client verwendet. Sie haben gelernt:

  • Wie Sie sich an einem entfernten Server anmelden.

  • Wie Sie Befehle remote ausführen.

  • Wie Sie Schlüsselpaare erstellen.

  • Wie Sie eine schlüsselbasierte Anmeldungen einrichten.

  • Wie Sie den Authentifizierungsagenten für zusätzliche Sicherheit und Komfort verwenden.

  • Die von OpenSSH unterstützten Public-Key-Algorithmen: RSA, DSA, ecdsa, ed25519.

  • Die Rolle der OpenSSH-Hostschlüssel.

  • Wie Sie Porttunnel erstellen: lokal, remote und X.

Die folgenden Befehle wurden in dieser Lektion behandelt:

ssh

Auf einem entfernten Rechner anmelden und Befehle ausführen .

ssh-keygen

Authentifizierungsschlüssel erzeugen, verwalten und umwandeln.

ssh-agent

OpenSSH-Authentifizierungsagent.

ssh-add

Dem Authentifizierungsagenten private Schlüsselidentitäten hinzufügen.

Lösungen zu den geführten Übungen

  1. Melden Sie sich als Benutzer sonya auf Ihrem Client-Rechner an und führen Sie die folgenden SSH-Aufgaben auf dem entfernten Server halof aus:

    • Führen Sie den Befehl aus, um den Inhalt von ~/.ssh als Benutzer serena auf dem entfernten Rechner aufzulisten. Kehren Sie dann zu Ihrem lokalen Terminal zurück.

      ssh serena@halof ls .ssh

    • Melden Sie sich als Benutzer serena auf dem entfernten Rechner an.

      ssh serena@halof

    • Melden Sie sich als Benutzer sonya auf dem entfernten Rechner an.

      ssh halof

    • Löschen Sie alle Schlüssel, die zu halof gehören, aus Ihrer lokalen Datei ~/.ssh/known_hosts.

      ssh-keygen -R halof

    • Erstellen Sie auf Ihrem Client-Rechner ein Schlüsselpaar ecdsa mit 256 Bit.

      ssh-keygen -t ecdsa -b 256

    • Erstellen Sie auf Ihrem Client-Rechner ein Schlüsselpaar ed25519 mit 256 Bit.

      ssh-keygen -t ed25519

  2. Führen Sie die folgenden Schritte in der richtigen Reihenfolge aus, um eine SSH-Verbindung mit dem SSH-Authentifizierungsagenten herzustellen:

    • Starten Sie auf dem Client eine neue Bash-Shell für den Authentifizierungsagenten mit ssh-agent /bin/bash.

    • Erstellen Sie auf dem Client ein Schlüsselpaar mit ssh-keygen.

    • Auf dem Client ergänzen Sie Ihren privaten Schlüssel mit ssh-add in einem sicheren Bereich des Speichers.

    • Fügen Sie den öffentlichen Schlüssel Ihres Clients in die Datei ~/.ssh/authorized_keys des Benutzers ein, mit dem Sie sich auf dem entfernten Rechner anmelden wollen.

    • Falls noch nicht vorhanden, erstellen Sie ~/.ssh für den Benutzer, mit dem Sie sich auf dem Server anmelden wollen.

    • Verbinden Sie sich mit dem entfernten Server.

      Die richtige Reihenfolge ist:

      Schritt 1:

      * Erstellen Sie auf dem Client ein Schlüsselpaar mit ssh-keygen.

      Schritt 2:

      Falls noch nicht vorhanden, erstellen Sie ~/.ssh für den Benutzer, mit dem Sie sich auf dem Server anmelden wollen.

      Schritt 3:

      Fügen Sie den öffentlichen Schlüssel Ihres Clients in die Datei ~/.ssh/authorized_keys des Benutzers ein, mit dem Sie sich auf dem entfernten Rechner anmelden wollen.

      Schritt 4:

      Starten Sie auf dem Client eine neue Bash-Shell für den Authentifizierungsagenten mit ssh-agent /bin/bash.

      Schritt 5:

      Auf dem Client ergänzen Sie Ihren privaten Schlüssel mit ssh-add in einem sicheren Bereich des Speichers.

      Schritt 6:

      Verbinden Sie sich mit dem entfernten Server.

  3. Welche Option und welche Anweisung werden bei Port Forwarding für die folgenden Tunneltypen verwendet?

    Tunneltyp Option Anweisung

    Lokal

    -L

    AllowTcpForwarding

    Remote oder Reverse

    -R

    GatewayPorts

    X

    -X

    X11Forwarding

  4. Sie geben den Befehl ssh -L 8888:localhost:80 -Nf ina@halof in das Terminal Ihres Client-Rechners ein. Auf dem Client-Rechner rufen Sie mit einem Browser http://localhost:8888 auf. Was werden Sie erhalten?

    Die Homepage des Webservers von halof, wie localhost aus Sicht des Servers verstanden wird.

Lösungen zu den offenen Übungen

  1. Bezüglich der SSH-Sicherheitsrichtlinien:

    • Welche Anweisung setzen Sie in /etc/ssh/sshd_config, um root-Logins zu ermöglichen?

      PermitRootLogin

    • Welche Anweisung setzen Sie in /etc/ssh/sshd_config, um nur einen lokalen Account anzugeben, der SSH-Verbindungen akzeptiert?

      AllowUsers

  2. Sie nutzen denselben Benutzer auf dem Client und dem Server. Welchen ssh-Befehl geben Sie ein, um den öffentlichen Schlüssel des Clients auf den Server zu übertragen, so dass Sie sich über die Authentifizierung mit öffentlichem Schlüssel anmelden können?

    ssh-copy-id

  3. Erstellen Sie zwei lokale Porttunnel mit einem einzigen Befehl, der die lokalen unprivilegierten Ports 8080 und 8585 über den entfernten Server halof an die Websites www.gnu.org bzw. www.melpa.org weiterleitet. Verwenden Sie den Benutzer ina auf dem entfernten Server — und vergessen Sie nicht den Schalter -Nf.

    ssh -L 8080:www.gnu.org:80 -L 8585:www.melpa.org:80 -Nf ina@halof

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.