Secure Shell (OpenSSH)

Bewertung 2

Die Kandidaten sollten in der Lage sein, sshd für das Zulassen oder Verweigern von Root-Logins zu konfigurieren und X-Forwarding zu aktivieren oder zu deaktivieren. Dieses Lernziel beinhaltet die Generierung von Server-Schlüsseln, das Generieren eines öffentlichen/privaten Schlüsselpaares für einen Benutzer, das Hinzufügen eines öffentlichen Schlüssels zu einer authorized_keys Datei eines Benutzers und die Konfiguration von ssh-agent für alle Benutzer. Prüfungskandidaten sollten weiters in der Lage sein, Portweiterleitung für das Tunneln eines Applikationsprotokolls über ssh zu konfigurieren, ssh für die Verwendung der Protokollversionen 1 und 2 zu konfigurieren, Non-Root-Logins während der Systemwartung zu deaktivieren, vertrauenswürdige Clients für SSH-Logins ohne Paßwort zu konfigurieren und mehrfache Verbindungen von mehreren Hosts aufzubauen, um gegen einen Verbindungsverlust zu entfernten Hosts nach Konfigurationsänderungen vorzubeugen.

Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:

  • ssh, sshd
  • /etc/ssh/sshd_config
  • ~/.ssh/identity.pub und identity, ~/.ssh/authorized_keys
  • .shosts, .rhosts

Architektur von SSH

SSH beruht auf einer Client/Server Architektur. Ein Rechner, der mit einem anderen Rechner mittels SSH in Kontakt treten will, startet den Client ssh. Auf dem Rechner, der angesprochen werden soll, muss der SSH-Server sshd laufen. In der Regel ist der SSH-Server eine Stand-Alone Anwendung, wird also nicht über inetd gestartet, sondern über ein Init-Script.

SSH arbeitet mit zwei unterschiedlichen Protokollversione (1 und 2) um auch älteren Clients (oder Servern) die Kommunikation mit neueren zu ermöglichen. Beide Protokollversionen arbeiten mit ähnlichen Methoden, naturgemäß ist aber die zweite (modernere) etwas sicherer.

Da SSH als sicherer Ersatz für RSH/RLOGIN gedacht war (und ist), verhält es sich in vielerlei Hinsicht sehr ähnlich wie sein Vorgänger. Beispielsweise werden – sofern der SSH-Daemon entsprechend konfiguriert ist – auch .rhosts-Dateien (und evt. .shosts-Dateien) unterstützt, um ein Einloggen ohne Passwort auf diese klassische Methode zu ermöglichen. Allerdings ist das eine sehr unsichere Methode und SSH bietet wesentlich sicherere Methoden an, die auch ohne Passwort auskommen.

Authentifizierung

Grundsätzlich überträgt SSH alle Daten (auch Passwörter) verschlüsselt. Die folgenden Techniken der Authentifizierung haben aber nichts mit dieser Verschlüsselung zu tun, sondern beziehen sich auf die Frage, wie ein User sich auf einem System als derjenigige ausweist, der er vorgibt zu sein.

Die erste Methode, die versucht wird, sobald eine Verbindung zwischen Client (ssh) und Server (sshd) aufgebaut wird ist – sofern aktiviert – die Methode der .rhosts-Dateien. Wenn auf dem Server (der Maschine, auf der der sshd läuft) der Name des Rechners, von dem die Anfrage kommt, in der Datei /etc/hosts.equiv oder /etc/shosts.equiv eingetragen ist, und der Username des Users, der die Anfrage macht auch auf dem Server existiert, dann wird sofort Zugriff gewährt.
Sollte die erste Methode gescheitert sein, dann wird überprüft, ob im Home-Verzeichnis des Users auf dem Server, unter dessen UID sich der Client anmelden will, eine Datei .rhosts oder .shosts befindet und diese eine Zeile enthält, in der sowohl der Name des Rechners von dem die Anfrage kommt, als auch der Name des Users, der die Anfrage durchführt aufgeführt sind. Sollte das der Fall sein, so wird Zugriff gewährt. Die Kombination dieser beiden Methoden ist naturgemäß sehr unsicher und ist daher in der Regel über die Konfigurationsdatei des Servers deaktiviert worden.

Die zweite Form der Authentifizierung beruht auf einer Kombination der .rhost-Methode mit der RSA-Schlüsselbasierten Host-Authentifizierung. Nur wenn die oben beschriebene Methode zum Erfolg geführt hätte und gleichzeitig der Server den HostKey des Clients verifizieren kann (über die Dateien /etc/ssh/ssh_known_hosts oder $HOME/.ssh/known_hosts), wird der Zugriff gewährt. Diese Methode sichert die erstgenannte zwar gegen ein paar Angriffsformen wie DNS-Spooging oder IP-Spoofing ab, generell ist aber die Verwendung von .rhosts-Dateien immer Unsicher und daher in einer wirklich sicheren Umgebung abzulehnen.

Die dritte Methode der Authentifizierung basiert alleine auf RSA-Techniken. RSA ist ein Verschlüsselungsmechanismus, der auf Schlüsselpaaren basiert. Grundsätzlich besteht ein solches Paar aus einem öffentlichen und einem privaten Schlüssel. Der Server kennt den öffentlichen Schlüssel und nur der User auf dem Client kennt den privaten Schlüssel. In der Datei $HOME/.ssh/authorized_keys auf dem Server liegen alle öffentlichen Schlüssel der User, die sich unter der entsprechenden UserID hier anmelden dürfen. Wenn sich jetzt ein User am Server anmelden will, dann übermittelt der Client (das ssh-Programm) dem Server (dem sshd-Programm) die Information, mit welchem Schlüssel gearbeitet werden soll. Der Server überprüft daraufhin, ob er den entsprechenden Public-Key besitzt und wenn ja, verschlüsselt er damit eine zufällige Zahlenfolge. Diese verschlüsselte Zahlenfolge (challenge) kann nur vom passenden Private-Key wieder entschlüsselt werden. Der Client entschlüsselt diese Zahlenfolge und kann so dem Server beweisen, dass er der Eigentümer des passenden Private-Keys ist. Sobald der Server das entschlüsselte Challenge zurückbekommen hat, gewährt er Zugriff. In der Regel werden die Public-Keys auf dem Server in der Datei $HOME/.ssh/authorized_keys gespeichert. Diese Methode ist ungleich sicherer als die .rhost-basierte Methode.

Wenn auch diese Technik scheitert, dann erst frägt der Server den Client nach einem Passwort. Da alle Übertragung sowieso verschlüsselt stattfindet, wird somit auch das Passwort verschlüsselt vom Client zum Server transportiert.

Der Authentifizierungsagent ssh-agent

Das Programm ssh-agent ist ein Programm, das geeignet ist, die Private-Keys zu verwalten, die dazu benötigt werden, um sich mit Public-Keys zu authentifizieren. Die Idee dahinter ist die, dass ssh-agent am Anfang einer ssh-Sitzung (oder einer X-Sitzung, die über ssh getunnelt wird) gestartet wird und alle weiteren zu startenden Programme als Clients des SSH-Agenten laufen. Damit kann festgelegt werden, dass nicht jeder Rechner im Netz die entsprechenden Private-Keys gespeichert haben muss, es reicht wenn sie auf dem Rechner liegen, auf dem der Agent läuft.

Schlüsselgenerierung

Grundsätzlich werden die notwendigen Schlüsselpaare mit dem Programm ssh-keygen erstellt. Dieses Programm erstellt sowohl die Schlüsselpaare der User für die oben genannte Authentifizierung, als auch die Hostschlüssel, die zur Verschlüsselung des Datentransfers selbst verwendet werden.

Generierung der User-Schlüsselpaare

Jeder User kann seine ssh-Schlüssel selbst anlegen. Das Programm ssh-keygen erwartet als Parameter mindestens die Angabe, um welchen Typ von Schlüssel es sich hierbei handeln soll. Folgende Typen stehen zur Verfügung: -t rsa1 Generiert wird ein RSA-Schlüsselpaar, das für die Protokollversion 1 von ssh geeignet ist. Der Private-Key wird in die Datei $HOME/.ssh/identity geschrieben, der Public-Key liegt in $HOME/.ssh/identity.pub -t rsa Hiermit wird ein RSA-Schlüsselpaar für die Protokollversion 2 des SSH-Protokolls erzeugt. Der Private-Key wird nach $HOME/.ssh/id_rsa geschrieben, der Public-Key liegt in $HOME/.ssh/id_rsa.pub -t dsa Hiermit wird ein DSA-Schlüsselpaar für die Protokollversion 2 des SSH-Protokolls erzeugt. Der Private-Key wird nach $HOME/.ssh/id_dsa geschrieben, der Public-Key liegt in $HOME/.ssh/id_dsa.pub

Der Befehl

  ssh-keygen -t rsa

erzeugt also das Schlüsselpaar vom Typ RSA für die Version 2 des SSH-Protokolls.

Beim Anlegen der Schlüsselpaare wird jeweils nach einem Passwort gefragt, das auch leer gelassen werden kann.

Der Inhalt der Datei, die den Public-Key enthält, kann jetzt an die Datei $HOME/.ssh/authorized_keys auf dem Server angehängt werden. Das kann einfach mit dem cat-Befehl erfolgen, entweder über den Transport via Datenträger oder eleganter auch über ssh, indem ein Befehl in der Art

  cat PublicKeyDatei | ssh Servername "cat >> .ssh/authorized_keys"

eingegeben wird. Zu beachten sind die Anführungszeichen, damit die Umleitungssymbole nicht von der lokalen Shell interpretiert werden, sondern von der des Servers. Das erste Mal, wenn dieser Befehl ausgeführt wird, muss noch ein Passwort eingegeben werden, da ja die Authentifizierung über die Schlüssel noch nicht funktioniert, schon direkt nach dem ersten Befehl sollte aber ein ssh-Befehl kein Passwort mehr verlangen.

Generierung eines Hostschlüsselpaares

Die Generierung des Hostschlüsselpaares läuft im Pronzip genauso ab, wie die der Userschlüssel. Allerdings sind hier ein paar Besonderheiten zu beachten:

  • Der Hostschlüssel darf kein Passwort benutzen, die Frage nach dem Passwort muss also leer gelassen werden.
  • Der Hostschlüssel wird in der Regel im Verzeichnis /etc/ssh gespeichert, ältere Versionen erwarten ihn in /etc selbst.
  • Der Namen der Hostschlüsseldatei ist in der Regel ssh_host_key und ssh_host_key.pub Die RSA1 Schlüssel für Protokollversion 1 ssh_host_rsa_key und ssh_host_rsa_key.pub Die RSA Schlüssel für Protokollversion 2 ssh_host_dsa_key und ssh_host_dsa_key.pub Die DSA Schlüssel für Protokollversion 2 Welche Namen tatsächlich verwendet werden, wird in der Serverkonfigurationsdatei sshd_config eingestellt (siehe unten).

Im Normalfall wird das Hostschlüsselpaar bei der Installation von SSH automatisch durch ein Script erzeugt, die entsprechenden Befehle ausführt:

  ssh-keygen -f /etc/ssh/ssh_host_key -N "" -t rsa1
  ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N "" -t rsa
  ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N "" -t dsa

Das -N „“ bedeutet, dass das neue Passwort leer ist, mit -f Dateiname wird der Name der Datei angegeben, in die der Schlüssel abgelegt werden soll.

Falls es notwendig sein sollte, ein neues Schlüsselpaar von Hand zu erzeugen, können diese Befehle vom Systemverwalter jederzeit auch manuell eingegeben werden.

Konfiguration des Servers in sshd_config

Die zentrale Konfigurationsdatei des SSH-Servers sshd liegt in /etc/ssh/sshd_config (in älteren Versionen auch direkt in /etc/sshd_config). Diese Datei enthält alle nötigen Einstellungen des Servers. Jede Zeile (die nicht leer oder Kommentar ist) besteht aus einem Schlüsselwort (Gross/Kleinschreibung wird nicht unterschieden) und einem Wert (Gross/Kleinschreibung wird unterschieden). Die wichtigsten Konfigurationsbefehle sind:

Grundsätzliche Konfiguration von sshd

Port Portnummer

Gibt die Portnummer an, auf der sshd lauschen soll. Voreingestellt ist Port 22. Es können mehrere dieser Anweisungen angegeben sein, wenn sshd auf mehreren Ports arbeiten soll.

Protocol Protokollnummer(n)

Gibt das SSH-Protokoll an, mit dem gearbeitet werden soll. Mögliche Werte sind 1 oder 2. Wenn mehrere Protokolle verwendet werden sollen, dann müssen sie durch Kommas getrennt angegeben werden. Voreingestellt ist 2,1.

HostKey Dateiname

Gibt den Dateinamen mit Pfad des Private-Host-Keys an. Voreingestellt sind die oben genannten Dateinamen. Es können mehrere dieser Anweisungen in der Datei enthalten sein, etwa um die drei verschiedenen Schlüsseltypen für rsa1, rsa und dsa zu spezifizieren. sshd weigert sich die angegebenen Dateien zu benutzen, wenn sie Dateien für Gruppen oder Rest lesbar sind. Sie sollten also ein Zugriffsrecht von 600 besitzen.

KeepAlive yes|no

Gibt an, ob der Server TCP-KeepAlive Meldungen an den Client schicken soll. Wenn solche Meldungen geschickt werden, so kann erkannt werden, ob eine Verbindung physikalisch abgebrochen wurde oder einer der Kommunikationspartner abgestürzt ist. Allerdings heisst das auch, dass eine Verbindung abbricht, wenn kurzzeitig eine Route ausfällt. Auf der anderen Seite wird so vermieden, dass sich Sessions aufhängen und trotzdem Reste im System hängenbleiben. Voreingestellt ist yes (KeepAlive Meldungen werden geschickt).

Authentifizierungsbefehle

LoginGraceTime Sekunden

Der Server trennt die Verbindung nach der angegebenen Anzahl von Sekunden, wenn ein User sich bis dahin nicht erfolgreich eingeloggt hat. Voreingestellt sind 600 (Sekunden). Steht hier eine 0, dann gibt es kein Zeilimit.

PermitRootLogin yes|no|without-password|forced-commands-only

Gibt an, ob und wie sich der Systemverwalter über ssh einloggen darf. Voreingestellt ist yes. Steht diese Einstellung auf without-password, so wird die Passwortabfrage für root abgeschalten. Das bedeutet, er kann sich nur einloggen, wenn er über ein entsprechend anderes Authentifizierungsverfahren verfügt. Steht der Wert auf forced-commands-only, so darf root nur Befehle ausführen (die an den ssh-Befehl angehängt werden), sich aber nicht regulär einloggen.

RhostsAuthentication yes|no

Gibt an, ob Authentifizierung über .rhosts oder /etc/hosts.equiv erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 1.

RhostsRSAAuthentication yes|no

Gibt an, ob Authentifizierung über .rhosts oder /etc/hosts.equiv zusammen mit RSA Host-Authentifizierung erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 1.

RSAAuthentication yes|no

Gibt an, ob reine RSA Authentifizierung erlaubt sein soll. Voreingestellt ist yes. Diese Option gilt nur für Protokollversion 1.

HostbasedAuthentication yes|no

Gibt an, ob Authentifizierung über .rhosts oder /etc/hosts.equiv zusammen mit RSA Host-Authentifizierung erlaubt sein soll. Voreingestellt ist no. Diese Option gilt nur für Protokollversion 2 und entspricht der Einstellung von RhostsRSAAuthentication für Version 1.

PubkeyAuthentication yes|no

Gibt an, ob Authentifizierung über Public-Keys erlaubt sein soll. Voreingestellt ist yes. Diese Option gilt nur für Protokollversion 2.

IgnoreRhosts yes|no

Gibt an, dass die Dateien .rhosts und .shosts nicht verwendet werden dürfen, wenn RhostsAuthentication, RhostsRSAAuthentication oder HostbasedAuthentication verwendet werden. Die Dateien /etc/hosts.equiv und /etc/shosts.equiv werden weiterhin abgearbeitet.

PasswordAuthentication yes|no

Gibt an, ob Authentifizierung über Passwörter erlaubt ist. Voreingestellt ist yes.

PermitEmptyPasswords yes|no

Gibt an, ob es bei erlaubtem PasswordAuthentication auch erlaubt sein soll, wenn User leere Passwörter haben. Voreingestellt ist no.

AllowUsers Muster|Liste

Hier kann eine durch Leerzeichen getrennte Liste von Usernamen/Mustern angegeben werden. Nur die hier angegebenen User dürfen sich einloggen. Für die Musterbildung stehen * und ? zur Verfügung wie auf der Shell. Es werden nur Namen, keine UserIDs interpretiert. Möglich ist auch, Einträge in der Form Username@Hostname zu machen, um nur User von bestimmten Rechnern aus zuzulassen. Voreingestellt ist, dass alle User sich einloggen dürfen.

AllowGroups Muster|Liste

Hier kann eine durch Leerzeichen getrennte Liste von Gruppennamen/Mustern angegeben werden. Nur User, die Mitglied der hier angegebenen Gruppen sind, dürfen sich einloggen. Für die Musterbildung stehen * und ? zur Verfügung wie auf der Shell. Es werden nur Namen, keine GroupIDs interpretiert. Voreingestellt ist keine Einschränkung auf bestimmte Gruppen.

Tunneling Optionen

AllowTcpForwarding yes|no

Gibt an, ob TCP-Forwarding erlaubt sein soll. Voreingestellt ist yes. Nachdem sich jeder User mit Shellzugriff seine eigenen Forwarder installieren kann, macht eine Einschränkung dieser Einstellung nur dann Sinn, wenn der User keinen Shellzugriff hat.

X11Forwarding yes|no

Gibt an, ob X11-Forwarding erlaubt sein soll. Voreingestellt ist no.

X11UseLocalhost yes|no

Gibt an, ob sshd den (virtuellen) X11-Forwarding Server an die Loopback-Adresse binden soll, oder an die Wildcard-Adresse. Voreingestellt ist yes (Loopback-Adresse). Damit wird der Hostnamenteil der DISPLAY-Variable auf localhost gesetzt. Damit wird verhindert, dass fremde Clients auf den virtuellen X-Server zugreifen können. Allerdings können ein paar ältere X11-Clients mit dieser Einstellung Schwierigkeiten haben. In diesem Fall kan diese Einstellung auf no gesetzt werden.

X11DisplayOffset Zahl

Gibt die Servernummer für den virtuellen X-Server an, um Verwechslungen mit echten X-Servern zu vermeiden. Voreingestellt ist 10.

XAuthLocation Pfad

Gibt den Pfad zum xauth Programm an. Voreingestellt ist /usr/bin/X11/xauth.

Natürlich muss der SSH-Daemon sshd nach einer Veränderung der Konfigurationsdatei entweder neu gestartet werden, oder es wird ihm ein HUP-Signal geschickt, das den Server zwingt, die Konfigurationsdatei neu zu laden.

X11 Forwarding

Nachdem ssh häufig in einer X11-Umgebung eingesetzt wird, in der graphische Programme auf einem Server aufgerufen werden, aber auf dem Bildschirm (genauer: auf dem X-Server) einer Workstation dargestellt werden sollen, hat ssh einen eingebauten Mechanismus, der eine sichere verschlüsselte Übertragung für solche Anwendungen bietet.

X11-Anwendungen erfahren aus der Umgebungsvariable DISPLAY, auf welchem Display, also auf welchem X-Server sie sich darstellen sollen. Außerdem arbeiten diese Anwendungen mit einem sogenannten Cookie, das ihre Berechtigung festlegt, auf dem Bildschirm eines anderen Rechners etwas darzustellen. All diese Arbeiten nimmt uns ssh komplett ab.

Normalerweise müssten wir auf dem Client folgenden Befehl eingeben, um das Programm xclock des Servers auf unserem Bildschirm zu sehen:

  ssh SERVER /usr/X11R6/bin/xclock -display CLIENT:0.0

Diese Übertragung wäre – ganz nebenbei – auch nicht verschlüsselt, denn wir haben ja nur den Befehl verschlüsselt übertragen. Der Weg zurück, vom Server auf unseren Bildschirm, würde ja vom X11-Protokoll übertragen und wäre somit völlig unverschlüsselt. (Auch wenn die Übertragung einer Uhr in der Regel nicht so geheim sein wird…)

Wenn wir aber auf dem Server jetzt den sshd so konfigurieren, dass er in seiner Konfigurationsdatei /etc/ssh/sshd_config den Eintrag

  X11Forwarding yes

aufweist und wir gleichzeitig auch unserem Client in der Datei /etc/ssh/ssh_config die Anweisung

  ForwardX11 yes

verpassen, dann funktioniert obiger Befehl jetzt viel einfacher. Wir schreiben auf dem Client nur noch

  ssh SERVER /usr/X11R6/bin/xclock

und schon ist die Uhr auf unserem Bildschirm. Die Vorteile sind jetzt im Einzelnen:

  • Verschlüsselte Übertragung der Daten (ssh-Tunnel, der das X11-Protokoll transportiert)
  • Keine Angabe von DISPLAY, denn der ssh-Server hat automatisch einen „virtuellen“ X-Server gestartet, der sozusagen das eine Ende des Tunnels darstellt. Die Umgebungsvariable DISPLAY auf dem Server ist jetzt standardmäßig auf localhost:10 gesetzt.
  • Keine Einstellungen für Cookies nötig. SSH stellt automatisch „gefälschte“ Cookies zur Verfügung und erledigt andere Fragen der Authorisierung.

Wichtig ist, dass nicht vergessen werden darf, dass auch auf der Client-Seite von SSH die Einstellung ForwardX11 yes in der Datei /etc/ssh/ssh_config vorgenommen werden muß. Nicht verwechseln, es handelt sich nicht um die Datei der Servereinstellung (sshd_config) sondern um die Clientkonfiguration (ssh_config)!

Tunneling unsicherer Anwendungen

Um sichere Tunnels zwischen zwei Rechnern aufzubauen, wird der SSH-Client benutzt. Eigentlich handelt es sich um eine Art Port-Forwarding, denn es wird ein lokaler (oder entfernter) Port auf einen entfernten (oder lokalen) Port abgebildet und dazwischen wird eine ssh Verbindung aufgebaut. ssh -L localerPort:fremderRechner:fremderPort User@Rechner Mit diesem Befehl wird veranlasst, dass der angegebene Port des lokalen Rechners (localerPort) mit dem Port fremderPort des Rechners fremderRechner verbunden wird und das diese Verbindung über ssh verschlüsselt läuft. Die Angabe User@Rechner bezieht sich auf den Eigentümer der Verbindung und den Rechner, auf dem der lokale Port läuft. Um also den Port 12345 des Rechners einstein mit dem Port 80 des Rechners bohr zu verbinden, schreibt der User root auf einstein

  ssh -L 12345:bohr:80 root@einstein

ssh -R fremderPort:fremderRechner:lokalerPort User@Rechner Das ist sozusagen die Umkehrung des vorherigen Prinzips.

Links zum Thema

Ähnliche Beiträge

Nameserver einrichten
Unix-Texttools
Samba als NT-PDC/BDC

Schreibe einen Kommentar