SSH-Server einrichten und betreiben/ Konfiguration

Zur Konfiguration des OpenSSHD-Servers wird eine Textdatei verwendet (bei unixoiden Systemen unter /etc/ssh/sshd_config zu finden). Die englischsprachige Beschreibung ist bei OpenSSH gelistet. Die Einstellungen werden hier kurz diskutiert, mit Links zu Hintergrundinformationen versehen und Hinweise, wann und wie diese Einstellungen zu ändern ist.

AcceptEnv

Der Client kann dem Server einzelne Umgebungsvariablen übergeben, die in der ausgeführten Kommandozeile dann verfügbar sind. Im einfachsten Fall wird dies der Suchpfad sein, wo auszuführende Programme gesucht werden. Der Server kann für entfernte Nutzer den Suchpfad einschränken. Hier kann der Server versuchen, ungewünschte Umgebungsvariablen zu übertragen.

Gründe, Umgebungsvariablen vom Client zuzulassen

• Nur vertrauenswürde Clients können sich verbinden.
• Schutz des Servers wird durch andere Methoden bewirkt.

Gründe, nur bestimmte Umgebungsvariablen zu akzeptieren

• Zusätzlicher Schutz bei ungewolltem Eindringen

Anweisung

Die Liste an möglichen Umgebungsvariablen wird mit AcceptEnv gesetzt. Auch Wildcards sind möglich:

AcceptEnv *

Akzeptiert alle Umgebungsvariablen vom Client.

AddressFamily

Mit der Anweisung AddressFamily wird der SSH-Dienst angewiesen, entweder den IPv4-Stack, IPv6-Stack oder beiden Stacks zu lauschen.

Gründe, die Adressfamilie auf einen Raum zu begrenzen

• Es wird ein Netzwerk verwendet, in dem nur IPv4 oder IPv6 verwendet wird.

Gründe, die Adressfamilie auf any zu belassen

• Heutzutage gibt es kaum noch Gründe, den SSH-Dienst auf nur ein Addressraum zu begrenzen.
• In einem DHCP verwalteten Netz mit IPv4/IPv6-gemischten Netz wird der Client nicht beide möglichen Adressen testen, um eine Verbindung aufzubauen.
• Fehlerquelle, wenn IP-Adresse fest vorgegeben wird (siehe unten) und aus dem anderen Addressraum verwendet wird.

Anweisung

Die IP-Adressfamilie wird mit der Anweisung AddressFamily angegeben:

AddressFamily any|inet|inet6

Der Schlüsselbegriff inet wird verwendet, um nur IPv4-Verbindungen aufzubauen. Analog wird inet6 verwendet, um ausschließlich IPv6-Verbindungen zu verwenden.

AllowTcpForwarding

Mit dieser Option lässt sich einstellen, ob Portweiterleitung vom Server direkt erlaubt wird, was eine einfache Möglichkeit für eine VPN darstellt.

Gründe, die Portweiterleitung zu erlauben

• Zugriff auf Ports, die nur vom Server zugänglich sind als einfache VPN-Möglichkeit
• Zu Testzwecken, um Dienste zu prüfen
• Das Unterbinden stellt keine wirkliche Sicherheit dar, da Experten dies umgehen können.

Gründe, die Portweiterleitung zu unterbinden

• Provisorischer Schutz vor VPN-Zugriff von normalen Nutzern.

Anweisung

Die Portweiterleitung kann unterbunden (no) werden oder nur lokal (local) erlaubt werden oder komplett (yes oder all) freigegeben werden. AllowTcpForwarding all/local/no

AuthenticationMethods

Der SSH-Server beherrscht direkt die Möglichkeit einer w:Multi-Faktor-Authentisierung. Hiermit wird aber auch die Reihenfolge festgelegt, in der die Authentifizierung erfolgen muss. Jede, der hier vorgeschriebenen Methoden muss separat in der Konfiguration zugelassen werden.

Gründe für Multifaktormethoden

• Zusätzliche Sicherheit für gefährdete Systeme

Gründe auf Multifaktormethoden zu verzichten

• Der zusätzliche Aufwand ist für das System nicht notwendig.

Anweisung

Der Anweisung AthenticationMethods wird eine Reihenfolge zulässiger Authentifizierungsmethoden übergeben, die mit Komma getrennt werden. Zusätzliche Reihenfolgen werden mit Leerzeichen getrennt zugefügt.

AuthenticationMethods publickey,password publickey,keyboard-interactive

Es werden zwei Authentifizierungsketten definiert, von der eine erfolgreich abgeschlossen werden muss. Bei beiden muss sich der Client zuerst mittels einem publickey gegenüber dem Server ausweisen. Anschließend muss ein Passwort übergeben werden (per Kommandozeile) oder es wird interaktiv ein Passwort abgefragt.

Mögliche Authentifizierungsmethoden:

• gssapi-with-mic
• hostbased
• keyboard-interactive
• none
• password
• publickey

AuthorizedKeysFile

Wird die Authentifizierung mit privaten Schlüssel erlaubt, dann müssen die öffentlichen Schlüssel der zugangsberechtigten Clients auf dem Server hinterlegt werden. Dies erfolgt in der hier genannten Datei.

Gründe, die Datei mit den authorisierten Schlüssel festzulegen

• Authentifizierung mit privatem Schlüssel soll verwendet werden.

Gründe, auf diese Datei zu verzichten

• Auf Authentifizierung mit privatem Schlüssel soll verzichtet werden.

Anweisung

Die Datei wird entweder absolut oder relativ bezogen auf das Nutzerverzeichnis angegeben:

AuthorizedKeysFile .ssh/authorized_keys

Dies ist die Default-Einstellung, so dass für jeden Nutzer die akzeptierten Schlüssel in der Datei authorized_keys im Unterzeichnis .ssh im eigenen Nutzerverzeichnis abgelegt sind.

Banner

Der Begrüßungstext wird gesendet, bevor eine Authentifizierung erwartet wird. Erfolgt eine Abfrage zur Authentifizierung (Passwort oder Token), kann hierüber ein Hinweis gegeben werden, auf welchem Rechner die Anmeldung erfolgt.

Gründe, einen Banner zu setzen

Bei Verwendung einer Passwortabfrage oder mit einem Token kann hier ein Text ausgegeben werden, mit dem der Nutzer einen Hinweis bekommen kann. Dies kann auch die Beschreibung des Servers sein.

Gründe, keinen Banner zu setzen

Ohne Verwendung einer Abfrage ist ein Hinweis auf den Server nicht notwendig. Zur Begrüßung mit einem Hinweis auf aktuelle Auslastung ist ein Banner beim Starten der Shell besser geeignet.

Anweisung

Ein Banner wird mit folgender Anweisung verwendet:

banner none/Filename

Bei none wird der Banner ausgeschaltet (Standard); ansonsten wird der Pfad zu einer Textdatei erwartet.

CASignatureAlgorithms

Spezifiziert, welche Signieralgorithmen akzeptiert werden, mit denen Zertifikate erstellt wurden. Diese Option wird verwendet, wenn unterschriebenen SSH-Schlüssel für die Authentifizierung verwendet werden.

Gründe, die Algorithmen einzuschränken

Vergleichbar zu anderen Optionen bzgl. der Wahl von kryptographischen Algorithmen gilt auch hier: Ist eine Schwachstelle bei einem Algorithmen bekannt oder wird vermutet, kann dieser Algorithmus ausgeschlossen werden.

Gründe, die Standardalgorithmen zu verwenden

Solange keine Schwachstellen in den Algorithmen bekannt sind, muss die Liste nicht eingeschränkt werden.

Anweisung

Die Auswahl an Algorithmen wird mit folgender Anweisung eingeschränkt:

CASignatureAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

Hiermit werden nur Elliptische_Kurve für Schlüssel-Signaturen zugelassen.

ChrootDirectory

Spezifiziert den Pfad für chroot. Nach erfolgreicher Anmeldung wird die gewünschte Anwendung in einer chroot-Sitzung in diesem Pfad ausgeführt.

Gründe, Chroot zu nutzen

Über Chroot ist der Zugriff der angemeldeten Nutzer auf Systemdateien deutlich erschwert.

Gründe, Chroot nicht zu nutzen

• Es erschwert die entfernte Konfiguration des Servers.
• Bei fehlerhafter Konfiguration wird die Sicherheit eher herabgesetzt.

Anweisung

Mit folgender Anweisung wird ein Verzeichnis gesetzt:

ChrootDirectory /path/to/chroot

Ciphers

Zu Beginn einer Verbindung verhandeln Client und Server die Verschlüsselungsmethode aus, welche für die komplette Verbindung verwendet werden soll.

Die Verschlüsselungsmethoden, die ein SSH-Server unterstützt kann mit dem Befehl ssh -Q cipher abgefragt werden.

Gründe, die Liste anzupassen

• Einzelne Verschlüsselungsmethoden sind unsicher geworden und Angriffe, den Inhalt zu dekodieren, sind möglich.
• Sollen große Datenmengen übertragen werden, sollte keine Verschlüsselung gewählt werden, welche eine hohe Last auf dem Server erzeugen.
• Sind mehrere SSH-Verbindungen vorgesehen, steigt mit jeder Verbindung die Last auf dem Server, die abhängig von der Verschlüsselungsmethode ist.

Anweisung

Die Liste wird mit der Anweisung Ciphers angelegt:

Ciphers aes192-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

Ausschließlich die drei gewählten Verschlüsselungsmethoden sind verfügbar.

ClientAliveCountMax

Der SSH-Server kann nach einem fest gelegten Intervall vom Client ein Lebenszeichen anfragen (siehe Option ClientAliveInterval. Wenn hintereinander eine bestimmte Anzahl an Lebenszeichen vom Client nicht beantwortet wird, wird die Verbindung beendet. Ist die Anfrage von Lebenszeichen aktiviert, wird als Standard die Verbindung nach 3 hintereinander nicht beantworteten Lebenszeichen beendet.

Gründe, die Anzahl anzupassen

• Ist der SSH-Client mobil und durchfährt eine Zone schlechter Verbindung (Tunnel), kann die Verbindung für einen bestimmten Zeitraum unterbrochen sein. Mit dieser Anzahl können solche Lücken überwunden werden.

Anweisung

Mit der Anweisung ClientAliveCountMax wird die Anzahl gesetzt:

ClientAliveCountMax 5

Nach 5 erfolglosen Lebenszeichen wird die Verbindung beendet. Beträgt das Intervall 5 Sekunden, wird die Verbindung nach 25s ohne Antwort beendet.

ClientAliveInterval: Zeitdauer für ein Lebenszeichen

Wenn über eine SSH-Verbindung nach einer gewissen Zeit keine Daten übertragen wurden, prüft der Server, ob der Client noch reagiert, vergleichbar mit einem Heartbeat. Dieses Intervall legt fest, nach welcher Zeitdauer ein Lebenszeichen vom Client angefragt wird. Sind ausreichend Lebenszeichen hintereinander nicht beantwortet, schließt der Server die Verbindung (siehe Option ClientAliveCountMax).

Ist dieses Intervall nicht explizit gesetzt (Standardwert 0), dann wird kein Lebenszeichen angefragt.

Gründe, ein Intervall zu setzen

• Ist bei Servern damit zu rechnen, dass viele Verbindungen benötigt werden und aus verschiedenen Gründen einzelne Verbindungen unterbrochen werden, belegen diese Verbindungen Ressourcen auf dem Server.
• Ist die Anzahl an gleichzeitigen SSH-Verbindungen begrenzt, dann sollten nicht reagierende Verbindungen zeitnah beendet werden.

Anweisung

Mit der Anweisung ClientAliveInterval wird eine Zeitdauer in Sekunden gesetzt:

ClientAliveInterval 5

Wenn keine Daten übertragen werden, fragt der Server alle 5 Sekunden nach einem Lebenszeichen des Client.

Compression

Mit dieser Option kann die Komprimierung der übertragenen Daten eingeschaltet werden. Im Normalfall ist die Komprimierung eingeschaltet.

Gründe, die Komprimierung einzuschalten

• Bei Datenübertragung über langsame Verbindung (z.B. über Mobilfunk) wird die Übertragung beschleunigt.
• Bei Datenübertragung gut komprimierbarer Daten (Textdateien) wird die Übertragung beschleunigt.

Gründe, die Komprimierung auszuschalten

• Es sollen überwiegend schlecht komprimierbare Daten übertragen werden (z.B. gezippte Archive)
• Die Komprimierung benötigt zu viel Rechenleistung auf dem Server und reduziert hierdurch die Übertragungsrate.

Anweisung

Mit der Anweisung Compression wird die Datenkomprimierung gesteuert:

Compression yes/delayed/no

Das Argument delayed wird aus Kompatibilitätsgründen beibehalten und ist identisch mit yes.

DenyGroups

Die Option DenyGroups wird zusammen mit DenyUsers, AllowUsers und AllowGroups verwendet, um den Zugang per SSH feiner einzuteilen.

In der Regel werden Systemnutzer, welche vom Betriebssystem eingerichtet werden so konfiguriert, dass ein Zugang unterbunden wird. Dennoch macht es Sinn, auch über die SSH-Konfiguration den Zugang nur echten Nutzern zuzulassen.

Auf anderen Systemen können Nutzer angelegt werden, welche Zugang zu anderen Diensten gewährt werden sollen (Datenbanken, Web-Zugang etc.), die aber keinen Zugang zu einer SSH-Konsole haben dürfen.

Gründe, die Liste an Nutzern nicht einzuschränken

• System ist in einem ausreichend gesicherten Netzwerk, so dass dieser zusätzliche Schutz nicht notwendig ist.
• Sollen später zusätzliche Nutzer eingerichtet werden, welche einen SSH-Zugang benötigen, kann diese Liste vergessen werden, so dass zunächst dieser neue Nutzer keinen Zugriff erhält.
• Andere Methoden zum Zugangsschutz sind ausreichend.

Gründe, die Liste an Nutzern einzuschränken

• Schutz vor unbekannten Sicherheitslücken / versehentlichen Fehlkonfigurationen, welche den Zugang von Systemnutzern ermöglichen würden.
• Es lassen sich auch Einschränkungen bzgl. Rechner zulassen, so dass ein Nutzer nur von einem zugelassenen Rechner sich einloggen kann. Sollte ein Konto ‚admin‘ existieren, so kann der Zugang auf dedizierte Rechner beschränkt werden.

Anweisung

Die Liste wird durch Leerzeichen getrennt angegeben. Einträge können mit einer Host-Angabe ergänzt werden, um Zugriff nur von ausgewählten Rechnern zuzulassen: user@host

Mit den 4 Anweisungen lassen sich Regeln definieren, welche Nutzer/Gruppen von dedizierten Rechnern Zugriff haben dürfen. Die Anweisungen werden in der Reihenfolge DenyUsers, AllowUsers, DenyGroups und AllowGroups durchlaufen. Die erste zutreffende Regel wird angewendet. Wird keine Anweisung in der Konfiguration erwähnt, haben alle Nutzer Zugang zum SSH-Dienst.

Beispiele: DenyUsers root@* admin@!host1

Allen root-Nutzer von allen Rechnern wird der Zugang verweigert.

Dem Nutzer admin wird der Zugang von allen Rechnern ausser vom Rechner host1 verweigert.

AllowUsers user1 user2@host1

Von allen Nutzern, die nicht von DenyUsers verweigert wurden, wird der Zugang für user1 von allen Rechner erlaubt. Der user2 darf sich nur von Rechner host1 anmelden.

DenyGroups www-data

Die Nutzer dürfen nicht zur Gruppe www-data gehören.

AllowGroups ssh admin@host1

Nur Nutzer, die zur Gruppe ssh gehören, dürfen sich anmelden, oder Nutzer der Gruppe admin, wenn sie sich vom Rechner host1 anmelden.

DenyUsers

siehe #DenyGroups

DisableForwarding

SSH bietet die Möglichkeit, einzelne Ports vom Server an den Client weiterzuleiten. Dies ist zu Testzwecken sinnvoll bzw. kann als vereinfachte VPN-Lösung dienen. Für SSH gibt es eine Reihe an Optionen zur Konfiguration von Portweiterleitungen. Ist diese Option auf no gesetzt, werden alle anderen Anweisungen bezüglich Port-Weiterleitung ignoriert. Ist die Anweisung auf yes gesetzt, können die spezifischen Weiterleitungen individuell gesetzt werden.

Gründe, Portweiterleitung zu unterbinden

Je nach Einsatzzweck des Servers kann eine Portweiterleitung eine Gefahr des Netzes darstellen.

Anweisung

Mit folgender Anweisung wird zentral die Portweiterleitung gesteuert:

DisableForwarding yes/no

ExposeAuthInfo

Es wird eine temporäre Datei geschrieben, in der Authentifizierungsinformationen gespeichert werden. Standardmäßig wird keine temporäre Datei geschrieben.

Gründe, Informationen über Authentifizierung temporär zu schreiben

Zu Entwicklungstätigkeiten bzw. zur Fehlersuche.

Gründe, keine Informationen über Authentifizierung temporär zu schreiben

Je weniger Information in einer Shell über die Authentifizierung zugänglich sind, umso sicherer ist der Zugang.

Anweisung

Mit folgender Anweisung wird das Schreiben der temporären Authentifizierungsinformationen gesteuert:

ExposeAuthInfo [no]/yes

FingerprintHash

Bei der Anmeldung mit Public Key wird der Hash-Wert des verwendeten öffentlichen Schlüssels in der Logdatei vermerkt. Standardmäßig wird sha256 verwendet.

Gründe, den FingerprintHash zu ändern

• Einzelne der verfügbaren Hash-Algorithmen werden als unsicher angesehen.

Anweisung

Mit folgender Anweisung wird der FingerprintHash gesetzt:

FinterprintHash [sha256]/md5

Wird der Fingerprint-Hash nicht manuell gesetzt, wird standardmäßig sha256 verwendet.

ForceCommand

Bei einer normalen SSH-Verbindung wird nach Authentifizierung eine Shell gestartet, mit welcher der Nutzer interagieren kann. In verschiedenen Szenarien ist es sinnvoll, stattdessen ein spezielles Programm auszuführen. So kann bei Anmeldung eines Dienst-Nutzers ein Dienst ausgeführt und die Antwort zurückgesendet werden.

Sinnvoll ist dies innerhalb eines Match-Blockes.

Gründe, ein Programm vorzuschreiben

• Für FTP-Verbindungen wird ein SFTP-Programm vorgeschrieben.
• Für automatisierte Verbindungen ist dies sinnvoll, um auf dem Server bestimmte Dienste von außen anzustoßen oder Berichte einzufordern.

Anweisung

Mit folgender Anweisung wird ein Programm nach Anmeldung erzwungen:

ForceCommand [none]|/path/to/executable

Standardmäßig wird kein Programm erzwungen (none).

GatewayPorts

SSH kann zum Tunneln verwendet werden. Mit GatewayPorts wird festgelegt, ob vom SSH-Server eine Tunnelverbindung zum lokalen Rechner ermöglicht werden soll. Bei einer SSH-Verbindung von einem lokalen Gerät zu einem SSH-Server kann ein Programm auf dem Server über diesen remote tunnel auf einen Dienst des lokalen Gerätes zuzugreifen, z.B. lokalen Web-Server.

Im Normalfall ist diese Weiterleitung nicht erlaubt.

Als Option sind möglich:

no

(Normal) Die Weiterleitung ist ausgeschaltet.

yes

Die Weiterleitung wird ermöglicht.

clientspecified

In der Verbindung können Einschränkungen erfolgen, von welchen entfernten IP-Adressen dieses Gateway genutzt werden darf.

Gründe, Portweiterleitung zu erlauben

Es besteht hier die Möglichkeit, ein VPN mittels SSH-Tunnel aufzubauen, welcher in zwei Richtungen funktioniert.

Für Entwicklungen bzw. Wartungsarbeiten an einem Server kann mit diesem Tunnel der Zugriff auf lokale Dienste ermöglicht werden.

Gründe, Portweiterleitung zu verbienten (normal)

Diese Weiterleitung soll nur verwendet werden, wenn dies tatsächlich notwendig ist. Im schlimmsten Fall kann ein Angreifer vom Server aus einfacher auf die lokalen Dienste zugreifen.

Anweisung

GatewayPorts [no]|yes|clientspecified

HostbasedAcceptedAlgorithms

Für die Verwendung der Host based Authentifizierung (siehe unten) wird die Auswahl an Algorithmen eingegrenzt, die verwendet werden dürfen. Die verfügbare Liste kann mit ssh -Q HostbasedAcceptedAlgorithms angezeigt werden.

Gründe, Algorithmen einzugrenzen

• Einzelne Algorithmen werden als unsicher angesehen.
• Einzelne Algorithmen sind komplezer und können z.B. bei Dateitransfer die Last bei der Kopie hochtreiben.

Anweisung

HostbasedAcceptedAlgorithms ssh-ed25519

Es wird ausschließlich ssh-ed25519 als Algorithmus akzeptiert.

HostbasedAcceptedAlgorithms - rsa-sha

Von der Standardliste wird der Algorithmus rsa-sha entfernt.

HostbasedAcceptedAlgorithms + rsa-sha2-512

Der Liste an akzeptierten Algorithmen wird rsa-sha2-512 zugefügt.

HostbasedAuthentication

Eine Möglichkeit, sich gegenüber dem Server auszuweisen, ist der Weg, den eigenen Client als sicher zu markieren. Jeder Nutzer auf dem Client, der auch auf dem Server einen Account besitzt, kann dann direkt eine Verbindung zum Server aufbauen, ohne dass eine weitere Authentifizierung notwendig ist.

Gründe, Rechner basierte Authentifizierung zu erlauben

• In einem abgesicherten Netzwerk sollen verschiedene Nutzer / Dienste auf andere Rechner zugreifen.

Gründe, Rechner basierte Authentifizierung nicht einzurichten

• Jeder Nutzer eines Rechners erhält zunächst Zugriff auf einen entsprechenden Server.

Anweisung

HostbasedAuthentication [no]/yes

Im Normalfall ist die Host based Authentifizierung ausgeschaltet (no).

HostbasedUsesNameFromPacketOnly

Meldet sich ein Nutzer an mit Host based Authentifizierung, versucht der Server anhand der IP-Adresse den tatsächlichen Namen zu ermitteln und in der eigenen Liste die Berechtigung zu prüfen. Mit dieser Option kann diese Prüfung ausgeschaltet werden. Ob die Hostbased Authentifizierung erlaubt wird, ist dann nur noch anhand der Paket-Daten zu prüfen.

Gründe, Name ausschließlich aus der Anfrage zu verwenden

• In einem internen Netzwerk ist eine saubere Liste der Rechnernamen nicht vorhanden.

Anweisung

HostbasedUsesNameFromPacketOnly [no]/yes

Normal ist die Überprüfung ausschließlich anhand der Paketdaten ausgeschlossen.

HostCertificate

Datei mit einem SSH-Zertifikat für den Host-Key. Damit wird ein Host-Key durch eine übergeordnete Instanz beglaubigt. Das Zertifikat muss zu einem bereits vorhandenen öffentlichen Schlüssel passen, den der SSH-Server verwendet.

Gründe, Zertifikate für den Host-Key zu nutzen

• Die Arbeit mit Zertifikaten kann die Arbeit mit mehreren SSH-Systemen erleichtern.

Gründe, keine Zertifikate für den Host-Key zu nutzen

• Eine hierzu notwendige PKI ist zu aufwendig.

Anweisung

HostCertificate /path/to/file

HostKey

Mit dem HostKey weist sich der Server gegenüber dem Client aus. Bei der erstmaligen Anmeldung muss der Client den vom Server präsentierten Host-Key akzeptieren. Verwendet der Server danach einen anderen Host-Key wird die Verbindung abgelehnt.

Aktuell unterstützt SSH drei verschiedene Schlüsselsysteme:

• Elliptische Kurven (ECDSA)
• spezielle elliptische Kurve ED25519
• RSA-Methode

Für jede Methode, welche der SSH-Server anbieten soll, muss der Server einen eigenen privaten Schlüssel vorhalten.

Dies ist eine Basisfunktion des Servers, die zum Funktionieren verwendet werden muss. Bei der erstmaligen Installation werden bereits drei Schlüssel für obige Methoden erzeugt und im Konfigurationsverzeichnis abgelegt.

Nur wenn die Schlüssel an einem anderen Ort gespeichert werden sollen, muss dies in der Konfiguration explizit angegeben werden.

Anweisung

HostKey /etc/ssh/ssh_host_ed25519_key

Weist den Server an, einen Schlüssel in dieser Datei zu suchen. Der hierzu passende öffentliche Schlüssel wird mit der Endung .pub vermutet.

HostKeyAlgorithms

Für den Host Key wird die Auswahl an Algorithmen eingegrenzt, die verwendet werden dürfen. Die verfügbare Liste kann mit ssh -Q HostKeyAlgorithms angezeigt werden.

Gründe, Algorithmen einzugrenzen

• Einzelne Algorithmen werden als unsicher angesehen.
• Einzelne Algorithmen sind komplezer und können z.B. bei Dateitransfer die Last bei der Kopie hochtreiben.

Anweisung

HostKeyAlgorithms ssh-ed25519

Es wird ausschließlich ssh-ed25519 als Algorithmus akzeptiert.

HostKeyAlgorithms - rsa-sha

Von der Standardliste wird der Algorithmus rsa-sha entfernt.

HostKeyAlgorithms + rsa-sha2-512

Der Liste an akzeptierten Algorithmen wird rsa-sha2-512 zugefügt.

HostbasedAuthentication

ListenAddress

Im Standard lauscht der SSH-Server auf allen Netzwerkkarten auf eingehende Verbindungen. Gerade wenn mehrere Netzwerke auf dem Rechner verfügbar sind, macht es Sinn, den SSH-Dienst nur auf einzelnen Netzwerkbereichen zuzulassen.

Gründe, die Netzwerkadresse fest vorzugeben

• Der Rechner hat mehrere physikalische Netzwerke mit getrennten Nutzerkreisen und/oder verwendet unterschiedliche Adressen auf einer Netzwerkkarte. Der Zugriff zu dem SSH-Dienst soll nur auf einem bestimmten Nutzerkreis möglich sein. Beispiel: Router mit separatem Gastnetz, aus dem kein SSH-Zugriff möglich sein soll.
• Der Rechner soll unter mehreren IP-Adressen verschiedene Dienste anbieten, den SSH-Dienst aber nur unter einer definierten IP-Adresse.

Gründe, die Netzwerkadresse offen zu lassen

• Der Rechner ist in einem DHCP-verwalteten Netzwerk und kann prinzipiell bei jedem Start eine andere Adresse erhalten.
• IPv6-Adressen sind nicht so leicht zu merken.

Anweisung

Die Adresse wird über die Anweisung ListenAddress eingestellt und prinzipiell kann zusätzlich die Port-Nummer mit angegeben werden (Konfliktgefahr mit Anweisung Port). Folgende Formen sind möglich:

ListenAddress host|IPv4_addr|IPv6_addr
ListenAddress host|IPv4_addr:port
ListenAddress [host|IPv6_addr]:port

Beispiele:

ListenAddress 192.168.4.5
ListenAddress 192.168.4.5:22
ListenAddress [fe80::3958:601e:d848:fffa]:22

Bei Verwendung einer IPv6-Adresse ist diese in eckigen Klammern zu setzen.

LoginGraceTime

Dem Client kann eine Wartezeit gewährt werden, in der die Authentifizierung erfolgen kann. Nach Ablauf dieser Frist wird die Verbindung beendet.

Gründe für die Wahl der Wartezeit

• Komplexe Passwörter benötigen eine gewisse Zeit bis diese eingegeben ist, so dass bei Authentifizierung mit Passwörtern die Wartezeit mind. ein paar Sekunden betragen sollte.
• Je komplexer die Passwörter sind, muss der Nutzer das Passwort zunächst aus einem Password-Safe holen, was zusätzlich Zeit kostet.
• Es muss berücksichtigt werden, dass Nutzer evtl. mehrere Versuche benötigen, für einen dedizierten Server das richtige Passwort zu erinnern.

Anweisung

Mit folgender Anweisung wird die Wartezeit von 60 Sekunden eingestellt:

LoginGraceTime 60

MACs

Mit der Zeit können für einzelne Hash-Algorithmen Sicherheitslücken auftreten, welche die Integrität einer Verbindung stören können. Um solche Hash-Algorithmen von der Nutzung auszuschließen, kann die Liste eingeschränkt werden.

Gründe für die Auswahl an Hash-Algorithmen

• Bekannte Sicherheitslücken schließen die Nutzung einzelner Methoden aus.
• Das Vertrauen in die Methode liegt nicht vor, da Schwachstellen vermutet werden.

Anweisung

Zur Verfügung stehende Hash-Algorithmen können über ssh -Q mac eingesehen werden. Diese können mit folgender Anweisung zu einer Liste erlaubter Hash-Algorithmen zusammengesetzt werden:

MACs hmac-sha2-512,umac-128-etm@openssh.com

MaxAuthTries

Wird die Authentifizierung mittels Passwörter verwendet, fragt der Dienst bei Fehlangabe maximal n-mal nach einem Passwort, bevor die Verbindung abgebrochen wird. Zu einem erneuten Versuch muss eine neue Verbindung aufgebaut werden. Im Standard kann ein Nutzer das Passwort 6-mal falsch eingeben, bis die Verbindung abgebrochen wird.

Dieser Parameter wirkt sich nur aus, wenn eine Authentifizierung mit Passwörtern eingeschaltet ist.

Gründe, die maximale Anzahl an Anmeldeversuchen zu modifizieren

• Eine hohe Anzahl mag sinnvoll sein, wenn das Passwort so gewählt ist, dass der Nutzer eine hohe Fehlerrate haben kann bei der Eingabe.
• Eine niedrige Anzahl an Versuchen reduziert den Erfolg von Brute-Force-Angriffen, da pro Verbindungsversuche nur n Passwörter probiert werden können.

Anweisung

Mit folgender Anweisung wird die maximale Anzahl an Versuchen auf 3 gesetzt: MaxAuthTries 3

MaxSessions

In der Regel kann ein Nutzer beliebig viele parallele Sitzungen mit einem Server aufbauen. Jede Sitzung belegt auf dem Server Ressourcen. Sollte einem Angreifer eine Zugangsmöglichkeit zufallen, kann der Angreifer die Nutzbarkeit des Servers durch Öffnen beliebig vieler Sitzungen reduzieren (Denial-of-Service Angriff).

Eine Sitzung beginnt erst mit der erfolgreichen Authentifizierung.

Gründe, die maximale Anzahl an parallelen Sitzungen einzuschränken

• Vermeidung von Überlastung des Servers durch zu viele parallele Sitzungen, z.B. durch automatisierte Skripte, die nicht sauber beendet werden.

Anweisung

Mit folgender Anweisung wird die Anzahl der parallelen Sitzungen reduziert:

MaxSessions 3

MaxStartups

Beim Aufbau einer SSH-Sitzung wird zwischen Client und Server zunächst die Parameter ausgehandelt und die Authentifizierung durchgeführt. Vor der Authentifizierung lässt sich mit diesem Parameter die Anzahl an geöffneten und noch nicht authentifizierten Verbindungen begrenzen.

Gründe, die Anzahl der noch nicht authentifizierten Sitzungen zu begrenzen

• Jede geöffnete Verbindung bindet Ressourcen.
• Jede neue Sitzung erzeugt einen neuen Prozess. Bei zu vielen Prozessen kann die Nutzbarkeit des Servers eingeschränkt werden (Denial-of-Service).

Anweisung

Mit folgendem Parameter sind maximal 3 noch nicht authentifizierte Verbindungen möglich:

MaxStartups 3

Als Alternative beherrscht SSH eine zufällige Abweisung, wenn die Anzahl der offenen Verbindungen in einem Bereich liegt. Diese Anweisung wird durch drei mit Doppelpunkt getrennten Zahlen angegeben:

MaxStartups 10:30:60

Die erste Zahl (10) gibt die Anzahl an offenen Verbindungen an, bei der die zufällige Abweisung beginnt. Die anfängliche Wahrscheinlichkeit wird mit der zweiten Zahl (30%) angegeben: 30% der startenden Verbindungen wird direkt abgewiesen. Diese Wahrscheinlichkeit steigt linear bis 100%, wenn die Anzahl der offenen Verbindungen die dritte Zahl (60) erreicht.

PasswordAuthentication

Die bekannte Methode, sich an einem Rechner anzumelden besteht aus der Kombination aus Benutzernamen und Passwort. Über Brute-Force-Angriffen kann dies ausgehebelt werden. SSH bietet mit Public Keys eine Methode, sich ohne Passwörter dem SSH-Server gegenüber auszuweisen, so dass eigentlich auf die Nutzung von Passwörter verzichtet werden kann.

Gründe für die Authentifizierung mittels Passwörter

• Bekanntes und vertrautes System
• Benutzt bereits Authentifizierung für Anmeldung vor Ort
• Nutzbar, wenn andere Authentifizierungsmethoden nicht möglich sind

Gründe gegen die Authentifizierung mittels Passwörter

• Benutzername und Passwort müssen als Kombination sicher sein.
• Angriff mittels Brute-Force ist automatisiert.
• Passwort sollte nirgends niedergeschrieben werden.
• Passwort sollte nicht mit anderen Nutzern geteilt werden.

Anweisung

Die Authentifizierung mittels Passwörter wird über folgende Zeile aus-/eingeschaltet: PasswordAuthentication

In der Einrichtungsphase wird der Zugang in der Regel über Passwordauthentifizierung erfolgen, sollte aber sobald als möglich deaktiviert werden. Zunächst sollte aber die alternative Authentifizierung geprüft werden.

PermitEmptyPassword

Keine gute Idee, für einen Zugang, der über das Netzwerk zugänglich ist, kein Passwort vorzusehen.

Gründe für das Erlauben von leeren Passwörtern

• Automatisierung in einem geschlossenen Netzwerk
• Datenübertragung soll verschlüsselt sein, aber Zugriff auf Dienst muss nicht explizit gesichert sein.

Gründe für das Verbieten von leeren Passwörtern

• Jeder hat Zugang zu dem Dienst und kann nach weiteren Schwachstellen suchen.
• Ist es tatsächlich notwendig, bei einem Dienst leere Passwörter zuzulassen, ist auf Eigenschutz eine detailierte Gefährdungsbeurteilung durchzuführen. Zumindest muss der Dienst über zusätzliche Wege abgesichert werden.

Anweisung

Über folgende Anweisung wird das Verhalten bzgl. leerer Passwörter gesteuert: PermitEmptyPassword yes/no

Der Standard muss ’no‘ lauten.

PermitRootLogin: Root Login verbieten

Generell sollte dem Hauptadministrator root kein SSH-Zugang gewährt werden. Es gibt kaum Szenarien, in denen heutzutage noch Root ein SSH-Zugang gewährt werden muss. Im Gegenteil: Bei automatisierten Angriffen im Internet werden Brute-Force-Angriffe gegen verschiedene Benutzernamen geführt, angeführt vom Benutzer Root.

Gründe, um Root das Einloggen zu erlauben

• Bequemlichkeit beispielsweise bei OpenWRT-Router, um keinen zusätzlichen Nutzer anzulegen; aber Bequemlichkeit ist niemals ein Grund, eine Schwächung des Systems zu akzeptieren.
• Verwaltung von Servern, wo noch Skripte von Root ausgeführt werden müssen.

Gründe, um Root das Einloggen zu verbieten

• Automatisierte Brute-Force-Angriffe im Internet haben den Nutzer Root ganz oben in ihrer Liste von Nutzernamen.
• Administrationsaufgaben sollten grundsätzlich von separaten Administratoren ausgeführt werden, welchen die entsprechende Rechte zugewiesen werden.

Anweisung

Über die Anweisung PermitRootLogin kann dies eingestellt werden: PermitRootLogin no/prohibit-password/forced-commands-only/yes

Auch wenn dem SSH-Dienst eine separate Liste von Nutzern erstellt werden kann, welche SSH nutzen dürfen, ist dies eine zusätzliche Einstellung, die standardmäßig auf ’no‘ gestellt werden sollte. Ist es tatsächlich notwendig, Root den Zugriff zu gewähren, dann lassen sich zusätzliche Sicherungen vornehmen:

• Root darf nur mit Public-Key zugreifen, nicht mittels Passwörter, die erraten werden können (Option prohibit-password).
• Es dürfen nur explizit zugelassene Anwendungen ausgeführt werden (Rechte-Reduzierung mit Option forced-commands-only).

Port

Für SSH ist von der IANA der Port 22 für TCP und UDP vorgesehen und als Standard eingestellt.

Gründe, den Port zu ändern

• Es wird ein zusätzlicher SSH-Dienst auf einen anderen Port benötigt.
• Port 22 ist in der Netzwerk-Firewall gesperrt.

Gründe, den Port auf 22 zu belassen

• Bringt kein Sicherheitsgewinn, da automatisierte Scans einen SSH-Dienst auch auf einem anderen Port finden.
• Bei Nutzung muss immer an den entsprechenden Port gedacht werden.

Anweisung

Der Port wird in der Konfigurationsdatei eingestellt über:

Port 2022

Dies weist den SSH-Dienst an, auf dem Port 2022 auf eingehende Verbindungen zu lauschen.

Protocol

Aktuell liegen von SSH zwei Protokollversionen vor: Version 1 und 2

Bei der Version 1 sind Schwachstellen bekannt, mit denen die Inhalte einer Verbindung ausgespäht werden können. Von daher sollte nur noch Protokollversion 2 verwendet werden.

Gründe, die veraltete Version 1 noch zuzulassen

Im Netzwerk sind Clients vorhanden, welche nur Version 1 beherrschen und ein Upgrade nicht möglich oder nicht gewünscht ist.

Da es sich bei diesem Client um ein veraltetes System handelt, sollte dieses System soweit wie möglich, separat abgesichert werden.

Gründe, nur aktuelle Version 2 ausschließlich zuzulassen

Version 1 ist geschwächt und sollte einem Client nicht angeboten werden.

Anweisung

Die Version wird mit der Anweisung Protocol festgeschrieben: Protocol 2

PubkeyAuthentication

Alternativ zur Passwordauthentifizierung kann die Anmeldung über SSH-Schlüssel erfolgen. SSH-Schlüssel sind mit PGP-Schlüsseln verwandt: Es wird primär ein privater Schlüssel zufällig generiert. Aus diesem wird der öffentliche Schlüssel berechnet. Allerdings kann aus dem öffentlichen Schlüssel der private Schlüssel nur mit einem deutlich höheren Aufwand berechnet werden (asymmetrische Schlüssel). Somit darf der öffentliche Schlüssel verteilt werden; der private Schlüssel muss dagegen privat bleiben.

Der öffentliche Schlüssel wird im entsprechenden Benutzerkonto auf dem SSH-Server hinterlegt, so dass sich per SSH nur diejenigen als ein bestimmter Benutzer anmelden können, welche Zugang zu einem passenden privaten Schlüssel haben.

Gründe für die Authentifizierung mittels Public Key

• SSH-Dienst kann gegen Brute-Force-Angriffe gesichert werden.
• Keine Notwendigkeit, sich für jeden Dienst ein eigenes Passwort merken zu müssen.

Gründe, die gegen Authentifizierung mittels Public Key sprechen

• Keine Möglichkeit, den privaten Schlüssel zu allen Zeiten wirklich sicher zu halten.
• Notwendigkeit, auf den SSH-Dienst zugreifen zu müssen von Geräten, auf denen man den eigenen privaten Schlüssel nicht hinterlegen möchten.

Anweisung

Die Authentifizierung wird über folgende Anweisung eingeschaltet: PubkeyAuthentication yes

Standardmäßig wird im Nutzerverzeichnis das versteckte Unterverzeichnis ‚.ssh‘ angelegt, in der die nutzerabhängigen Einstellungen gespeichert werden. Dort wird in der Regel der private und öffentliche SSH-Schlüssel abgelegt, welche für die Authentifizierung benötigt werden.

UsePAM

Bei Verwendung einer Authentifizierung mittels Passwörtern, wird zur Prüfung des Passwortes ein installiertes PAM verwendet. Wird für den lokalen Zugang bereits PAM eingesetzt, lassen sie hierüber die dort hinterlegten Regeln nutzen.

Gründe, PAM zu nutzen

• Lokale Nutzerverwaltung setzt bereits PAM ein.

Gründe, PAM nicht zu nutzen

• Mit PAM muss der SSH-Dienst unter dem Nutzer Root laufen.

Anweisung

Mit folgender Anweisung wird die Nutzung von PAM kontrolliert: UsePAM yes/no