SDB:OpenSSH konfigurieren
| Getestet mit openSUSE | Empfohlene Artikel | Verwandte Artikel | |||
|
|
|
|
||
Inhaltsverzeichnis
Voraussetzungen
Um mit diesem Artikel zu arbeiten werden Grundkenntnisse in Linux/openSUSE gebraucht, inklusive:
- Arbeiten mit der Kommandozeile (CLI)
- Bearbeitung von Textdateien
- Erwerben von root-Rechten (verwenden von su, sudo oder Login als root)
- Vertrauter Umgang mit YaST-Modulen:“Benutzer- und Gruppenverwaltung” und "Firewall"
Und natürlich brauchen Sie ein funktionstüchtiges und laufendes Netzwerk. Wenn Sie eine Verbindung von außerhalb Ihres LANs einrichten wollen, müssen Sie den benötigten Port an Ihrem Router öffnen können.
Konfigurationsdateien
Der SSHD und die SSH verwenden Konfigurationsdateien (config files). Diese Dateien können ganz einfach mit Ihrem bevorzugten Texteditor überarbeitet werden. Wenn Sie zuerst in die Konfigurationsdateien schauen, werden Sie erkennen, dass die meisten Optionen auskommentiert sind.(z.B. # Port) Das bedeutet, dass sie als ein “Kommentar” gelesen werden und keine aktuelle Einstellung beinhalten. Wenn eine Variable als Einstellung gelesen wird, bedeutet das, dass die Standardwerte verwendet werden. Etwas Schönes daran ist, dass die von Standard auskommentierten Optionen den Standardwert anzeigen, so dass Sie eine Idee kriegen können, was die Verbindung in den Standardeinstellungen machen würde. Um eine Option zu ändern, entfernen Sie das Kommentarzeichen # am Anfang der Zeileund ändern Sie den Wert hinter der Option. Wann auch immer Sie das Gefühl haben, dass die neue Einstellung nicht richtig funktioniert, stellen Sie einfach den Kommentar (#) zurück und der Standard wird wieder verwendet.
SSHD – Der Server
Der SSHD (Secure Shell Daemon) sollte auf dem Server laufen (Remote Host). Der SSHD verwaltet die eingehenden Verbindungen, Authentifizierungen, Regeln und Verschlüsselung.
Der SSHD hat nur eine Konfigurationsdatei, die in /etc/ssh/sshd_config gefunden werden kann. Sie können diese überarbeiten, indem Sie Ihren bevorzugten Editor als root verwenden. Die Konfiguration des SSHD ist ganz allgemein und nur Einschränkungen für Benutzer einzubauen, die (versuchen) sich anzumelden. Die aktuellen Verbindungs-Parameter werden von der Client-Seite gesetzt. Wenn Sie den SSHD einrichten, müssen sie beachten, was Ihrer Meinung nach sicher ist oder erlaubt sein sollte. Für die Instanz: Wenn Sie X11-Forwarding in SSHD verhindern, ist es sinnlos den Client mit X Forwarding einzurichten. Denken Sie also nach, für was Sie die SSH-Verbindung verwenden werden, wenn Sie den SSHD einrichten.
SSH – Der Client
SSH (Secure Shell) ist eins der Client-Programme des openSSH-Pakets. Dieses Programm wird gebraucht um sich in einer Remote Shell anzumelden oder direkt einen Remote-Befehl auszuführen. In diesem Artikel beziehen wir uns auf die SSH-Konfigurationsdateien, obwohl sie auch SFTP und SCP betreffen.
Es gibt 3 Wege SSH zu konfigurieren. Alle haben die gleichen Optionen, welche als Argumente der SSH übermittelt werden.
- Systemweite Konfigurationsdatei: /etc/ssh/ssh_config
- Persönliche Konfigurationsdatei: ~/.ssh/config
- Kommandozeilen-basierte Argumente (CLI)
Wenn Argumente sich widersprechen, wird das zuletzt gegebene Argument verwendet. Somit verwerfen die Kommandozeilen-basierten Argumente beide Konfigurationsdateien und die persönliche Konfiguration verwirft die Systemweite Konfigurationsdatei.
Wenn Sie ein System mit verschiedenen Benutzern am laufen haben, und diese Benutzer haben auch wieder ihre Vorlieben oder benutzen unterschiedliche Remote Hosts, würde eine kluge Einrichtung folgendermaßen aussehen:
- Einige allgemeine Einstellungen in der Systemweiten Konfiguration /etc/ssh/ssh_config. Sie müssen root sein um diese Datei bearbeiten zu können.
- Host-spezifische Verbindungsdetails in der persönlichen Konfigurationsdatei ~/.ssh/config. Irgendein Benutzer kann seine eigene Konfigurationsdatei editieren. Erlauben Sie ihm seinen eigenen Host und die Verbindungsdaten einzurichten, ohne dass er root-Rechte braucht. Verwenden Sie diese Datei um die Konfiguration einzurichten, die Sie für (fast) jede Verbindung brauchen.
- Kommandozeilen-basierte Argumente können verwendet werden um etwas zu überschreiben oder manchmal bestimmte Parameter zu verwenden.
Bitte denken Sie daran, dass das SSH-Protokoll dafür bestimmt ist dieses über ein unsicheres Netzwerk zwischen 2 nicht gesicherten Rechnern zu verwenden. Das bedeutet, dass Sicherheit nicht nur eine Angelegenheit der Serverseite, sondern auch der Clientseite ist. Beispielsweise sollten Sie kein X11-Forwarding erlauben, wenn Sie den Server nicht betreiben. Ein falsch gesehener Admin auf einem manipulierten Server kann Ihre genauen Tastenanschläge (z.B. Passwörter) überwachen, die zum X-Server gesendet werden. Also erlauben Sie nicht einfach alle Kenndaten in den Konfigurationsdateien, sondern erlauben nur das, was Sie brauchen. Das Gute an der oben genannten Einrichtung ist, dass die Benutzer ihre Zuverlässigkeit auf Host-Basis selbst bestimmen können-
Erneutes Laden der Konfiguration
Wann auch immer Sie eine Änderung an der /etc/ssh/sshd_config durchführen, müssen Sie den SSHD neu starten oder seine Konfiguration neu laden lassen:
oder
Sie können das bei einer laufenden SSH-Verbindung durchführen und Sie müssen sich nicht abmelden. Aber die Änderungen treten für jeden Benutzer erst in Kraft, wenn sie sich das nächte Mal versuchen anzumelden.
Eingehende Verbindungen belauschen
Der erste Schritt in der (aktuellen) Konfiguration ist: “ Wohin wird der SSHD hören?” Dafür können wir die folgenden Optionen setzen:
Adresse
Standardmäßig lauscht der SSHD auf allen lokalen Adressen. Wenn Sie einen Computer mit unterschiedlichen Netzwerkverbindungen haben und nur eine oder bestimmte davon verwenden wollen, können Sie das einzeln auflisten. Finden und ändern Sie das Folgende in /etc/ssh/sshd_config als root:
#ListenAddress 0.0.0.0 -zu- ListenAddress * Ihre IP-Adresse *
Wenn Sie nur einen Anschluss oder ein Netzwerk mit DHCP verwenden, ist es klug die Standard-Konfiguration zu behalten. Wenn Sie verschiedene Anschlüsse verwenden wollen, aber nicht alle, können Sie jede einzelne Adresse in einer neuen Zeile mit ListenAdress beginnend auflisten. Jede Zeile muss mit der Option Port anfangen.
Port
Standardmäßig lauscht der SSHD auf Port 22. Sie können wählen das nicht zu verändern. Aber wenn Angreifer nach möglichen Verbindungen schauen, wo sie einbrechen können, würden sie zuerst nach den meist üblichen Ports, wie 22, schauen. Das Ändern der Port-Nummer reduziert die Anzahl der automatisierten Attacken, die durch systematische Angreifer oder Zombie Computern erheblich. Andererseits bringt die Änderung der Port-Nummer mit sich, dass dieser alternative Port auf allen Clients, die sich mit Ihnen verbinden wollen, konfiguriert werden muss. Wir werden in den folgenden Beispielen den Port 2222 als alternativen Port verwenden. Um die hörende Port-Nummer zu verändern, editieren Sie /etc/ssh/sshd_config als root und ändern:
#Port 22 -zu- Port 2222
Einrichtung Ihrer SSH um sich mit dem SSHD zu verbinden
Jetzt müssen Sie SSH (den Client) einrichten um sich mit dem vorher festgelegten Port vom SSHD zu verbinden. Als erstes editieren Sie /etc/ssh/ssh_config. Sie werden die Option Host * sehen. Das steht für alle entfernten Hosts. Alle Optionen, die unter einer “Host”-Zeile festgelegt sind, werden nur diesen einen Host betreffen, bis eine neue Host-Zeile angelegt wird. Das bedeutet, dass alle nachfolgenden Optionen in dieser Datei alle Hosts betreffen. Behalten Sie bei dieser Option die Standardeinstellung. Überprüfen Sie die Option Protocol. Diese darf nicht auskommentiert sein und muss auf 2 gesetzt sein (Protocol 2). Das wird zur Sicherstellung benötigt, damit das alte und jetzt unsichere Protokoll 1 nicht verwendet wird. Speichern und schließen Sie jetzt diese Datei. Wenn keine Verbindungen momentan bestehen, müssen Sie nichts neu starten, damit die Änderungen eingreifen. Änderungen werden das nächste Mal wirksam, wenn Sie einen SSH-Tunnel aufbauen.
Persönliche Konfigurationsdatei
Hier wird erklärt, wie eine persönliche Konfigurationsdatei mit den Daten auf dem Rechner eingerichtet wird. Als erstes überprüfen Sie, ob der Ordner .ssh in Ihrem home-Verzeichnis - mit dem richtigen Besitzer (Sie) und Zugriffsberechtigungen - existiert. Wenn es nicht vorhanden ist, erstellen Sie es als normaler Benutzer.
$ mkdir ~/.ssh $ chmod 700 ~/.ssh
Jetzt erstellen Sie eine neue Text-Datei mit Ihrem bevorzugten Editor und speichern es als ~/.ssh/config. Danach können wir unsere rechnerspezifischen Verbindungen konfigurieren:
Host ssh-server
Hostname 192.168.100.103
Port 2222
Hier verwenden Sie einen einfachen Namen (ssh-server) für die Remote-Host-Adresse 192.168.100.103. Die Option Host kann für einen beliebigen Namen, den Sie wollen, verwendet werden, so lange dieser die Option Hostname beschreibt. Wenn die Option Hostname nicht mit aufgeführt ist, werden Sie die aktuelle IP-Adresse hinter die Option Host schreiben müssen.
Jetzt können wir einen SSH-Tunnel zum vorher konfigurierten SSHD aufbauen (lauschend auf Port 2222 auf der IP-Adresse 192.168.100.103 und angemeldet als ein bestimmter Benutzer):
Um sich mit einem anderen Benutzernamen (user) an dem Remote-System anzumelden, tippen Sie:
Und Sie werden nach einem Passwort gefragt.
Sie können verschiedene Rechner angeben und ihnen ihre eigenen Einstellungen geben:
Host ssh-server
Hostname 192.168.100.103
Port 2222
Host workserver
Hostname ssh.host.org
Port 5041
Compression yes
Die Komprimierung (Compression) wird benötigt, wenn langsame Verbindungen erlaubt sein sollen (z.B. beim Verbindungsaufbau). Werden schnelle Verbindungen erlaubt, wird es Ihre Verbindung nur verlangsamen, konsumierend aus vielen Servern und Clients.
Access Control
Das ist ein wichtiger Teil für die Sicherheit ihres SSHD, der eine Verbindung zu ihrem Computer und sich dann dort anmelden darf. Als erstes verwenden Sie keine einfachen Passwörter. In der Basis-Konfiguration kann sich irgendein Host mit Ihrem Computer verbinden. Wenn ein Angreifer Ihre IP-Adresse und den lauschenden Port (der ganz einfach zu erhalten ist) kennt, könnte er einfach eine Wörterbuch-basierte Attacke gegen Sie starten. Wenn der Angreifer weiß, dass Sie “John Smit” heißen, ist Ihr Benutzername sehr wahrscheinlich john, js, john.smit etc. Wenn Ihr Passwort auch noch der Name Ihres Hundes ist, kann jemand sehr einfach in Ihr System einbrechen. Verwenden Sie auch keine Passwörter, die von dritten Datenbanken benutzt werden, wie Ihre E-Mail-, Foren- und Wiki-Accounts. Jetzt ist höchste Zeit eine strikte Trennung zwischen Passwörtern, die im Internet verwendet werden, und den Computer-Passwörtern zu behalten. Es ist immer sicher per Zufall generierte und nicht großgeschriebene alphanumerische oder nicht-alphanumerische Zeichen in Ihren Passwörtern zu verwenden.
Limit bei den Hosts
Wenn es feste Orte gibt, von wo aus Sie sich zum SSHD verbinden wollen, können sie ein Host-basiertes Access Control einrichten. In /etc/hosts.allow geben Sie die folgenden Zeilen für die Hosts, die Sie ausdrücklich erlauben wollen, ein, z.B.:
sshd : 127.0.0.1 : allow sshd : 192.168. : allow sshd : 130.57.5.70 : allow sshd : 10. : allow
Als nächstes geben Sie alles ein, was in der /etc/hosts.deny verboten werden muss,
sshd : ALL : deny
Wenn Sie sich für ein eher dynamisches Host Access Control interessieren, können Sie auch das Skript DenyHosts verwenden wollen. Dieses wird Ihnen erlauben sich von irgendeinem beliebigen Ort aus einzuloggen, während DenyHosts bösartige Hosts, die auf Regeln wie bei den Log-in-Versuchen basieren, heraus filtert. DenyHosts wird dann wieder diese bösartigen Hosts zu /etc/hosts.deny hinzufügen. Das hat viel schönere Funktionen als das Loggen und die Berichterstattung per E-Mail.
Limit bei den Benutzern
SSHD erlaubt es das Anmelden nur für bestimmte Benutzer und Gruppen einzugrenzen. Wo es möglich ist, benutzen Sie Gruppen um den Zugriff zu erlauben/ verbieten. Dieser Weg ist sehr viel einfacher um die Zugriffsrechte nachträglich zu editieren.
Diese Optionen können in der /etc/ssh/sshd_config eingegeben werden und werden in der folgenden Reihenfolge abgearbeitet,
- PermitRootlogin
- DenyUsers
- AllowUsers
- DenyGroups
- AllowGroups
PermitRootLogin kann auf yes oder no gesetzt werden. Der Standard ist yes. Es ist weise das zu no zu ändern, seitdem jedes *NIX-System den Benutzer Root hat und dieser Benutzer ist mächtig, weshalb es der ideale Benutzer ist um in ein System einzubrechen. Sie können auch Root-Rechte erhalten, indem Sie su oder sudo nach der Anmeldung als normaler Benutzer eingeben. Sie können ebenso die Verwendung von su einschränken wollen.
Die anderen Optionen können mit einer Liste von Benutzer- oder Gruppennamen, mit Leerstellen getrennt, aufgelistet werden. Nur Namen sind gültig; eine nummerische Benutzer- oder Gruppen-ID wird nicht anerkannt. Sie können die /etc/ssh/sshd_config mit Ihrem Lieblings-Editor editieren und die folgende Zeile hinzufügen:
AllowGroups sshlogin
Das wird nur den Benutzern, die Mitglied in der Gruppe sshlogin sind, erlauben sich am Server anzumelden. Jetzt öffnen Sie Yast2 > Sicherheit und Benutzer > Benutzer- und Gruppenverwaltung um die Gruppe sshlogin zu erstellen und die Benutzer hinzuzufügen, die sich auf dem Server anmelden dürfen müssen. Wenn Sie jetzt versuchen sich mit einem Benutzer anzumelden, der nicht in diese Gruppe hinzugefügt ist, oder auch nicht existiert, werden Sie weiterhin nach einem Passwort gefragt und Sie werden weiterhin eine Anzahl an Versuchen haben, aber die ganze Zeit die Fehlermeldung “Incorrect Password” erhalten. Somit werden Angreifer nicht wissen, ob das Passwort oder der Benutzer falsch ist.
Authentifizierung
OpenSSH-Server können Benutzer authentifizieren, indem sie die integrierten Authentifizierungs-Systeme verwenden:
- Keyboard-interactive (Passwörter und Challenge-Response)
- Public-Key-Authentifizierung
- Kerberos/GSSAPI
Keyboard-interactive
Wenn man den SSHD unter openSUSE laufen lässt, ist PAM der übliche Weg für die interaktive Authentifizierung über die Tastatur. PAM wird auch für die lokale Authentifizierung von Benutzern verwendet und verwendet die gleichen Passwörter, die über YaST gesetzt werden. Die folgenden Optionen erlauben für die Authentifizierung die Verwendung von PAM, Account und Test der Sitzung :
ChallengeResponseAuthentication yes UsePAM yes
Das sind Standard-Werte.
Public-Key-Authentifizierung
Public-Key-Authentifizierung erlaubt Ihnen sich auf einem Server ohne Passwort anzumelden oder die Sicherheit zu verbessern. Das Schlüssel-Paar wird auf der Client-Seite erstellt und der private Schlüssel (private key) muss an einem sicheren Platz abgespeichert werden. Der öffentliche Schlüssel (public key) wird zum Server geschickt und in der Datei "authorized_keys" gespeichert. Das bedeutet, dass der Computer (und Benutzer), der den privaten Schlüssel hält, sich am Computer anmelden kann, der den öffentlichen Schlüssel hat.
Schlüssel-Erstellung
Wenn ssh-keygen ohne Argumente verwendet wird, wird ein 2048 bit RSA-Schlüssel erstellt. Der private Schlüssel wird unter ~/.ssh/id_rsa gespeichert und der öffentliche Schlüssel unter ~/.ssh/id_rsa.pub. Sie können basierend auf Ihren Anforderungen vorziehen ein Passwort zu setzen. Werden die Zeilen leer gelassen, wird kein Passwort gesetzt.
$ ssh-keygen
Enter file in which to save the key (/home/your_user/.ssh/id_rsa): <Enter>
Enter passphrase (empty for no passphrase): <Enter>
Enter same passphrase again: <Enter>
Your identification has been saved...\
Hochladen Ihres Schlüssels
Um Ihren erstellten Schlüssel zur Authentifizierung zu verwenden, muss Ihr Public Key hochgeladen werden:
$ ssh-copy-id user@ssh.yourserver.org
Password:
Now try logging into the machine, with "ssh 'user@ssh.yourserver.org'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Wenn Sie mehr über dieses Thema (einschließlich Deaktivierung der Passwort-Authentifizierung um die Sicherheit zu erhöhen und die Verwendung von DSA oder anderer benutzerdefinierter Schlüssel-Einstellungen), lesen Sie den vollständigen Artikel dazu.
Troubleshooting
Public-Key-Authentifizierung funktioniert nicht mehr
Seit openSSH 5.4 sind relative Pfadde in der Konfiguration nicht mehr erlaubt. Wenn Sie auf die Datei authorized_keys zeigen, sorgen Sie dafür, dass Sie %h/ vor dem Pfad zur Datei authorized_keys verwenden. Ältere Versionen können das auch ohne machen. In /etc/ssh/sshd_config ändern Sie:
AuthorizedKeysFile .ssh/authorized_keys -zu- AuthorizedKeysFile %h/.ssh/authorized_keys
Siehe auch
Manpages
$ man hosts_access
$ man ssh
$ man ssh_config
$ man sshd
$ man sshd_config