Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Remote Access – Übersicht

Sie (der Netzwerkadministrator) können über Services wie DHCP, Finger, FTP, rlogin, SSH und Telnet-Services remote auf einen Router, Switch oder ein Sicherheitsgerät zugreifen. In diesem Thema erfahren Sie, wie Sie den Remotezugriff mithilfe von Telnet-, SSH-, FTP- und Finger-Diensten konfigurieren.

Übersicht über Systemservices

Aus Sicherheitsgründen ist der Fernzugriff auf den Router standardmäßig deaktiviert. Sie müssen den Router explizit konfigurieren, damit Benutzer auf Remotesystemen darauf zugreifen können. Benutzer können von einem Remote-System aus über die DHCP-, Finger-, FTP-, rlogin-, SSH- und Telnet-Dienste auf den Router zugreifen. Darüber hinaus können Clientanwendungen des Junos XML-Protokolls unter anderem Secure Sockets Layer (SSL) oder den protokollspezifischen Klartextdienst von Junos XML verwenden.

Hinweis:

Um Systemressourcen zu schützen, können Sie die Anzahl der gleichzeitigen Verbindungen, die ein Service akzeptiert, und die Anzahl der Prozesse, die einem einzelnen Benutzer gehören, begrenzen. Wenn einer der Grenzwerte überschritten wird, schlagen Verbindungsversuche fehl.

Konfigurieren des Telnet-Dienstes für den Remotezugriff auf einen Router oder Switch

Um den Router oder Switch so zu konfigurieren, dass er Telnet als Zugriffsdienst akzeptiert, fügen Sie die telnet Anweisung auf Hierarchieebene [edit system services] ein:

Standardmäßig unterstützt der Router oder Switch eine begrenzte Anzahl gleichzeitiger Telnet-Sitzungen und Verbindungsversuche pro Minute.

Optional können Sie eine oder beide der folgenden Anweisungen einschließen, um die Standardwerte zu ändern:

  • connection-limit limit– Maximale Anzahl gleichzeitiger Verbindungen pro Protokoll (IPV4 und IPv6) Der Bereich reicht von 1 bis 250. Der Standardwert ist 75. Wenn Sie ein Verbindungslimit konfigurieren, gilt das Limit für die Anzahl der Telnet-Sitzungen pro Protokoll (IPv4 und IPv6). Ein Verbindungslimit von 10 erlaubt beispielsweise 10 IPv6-Telnet-Sitzungen und 10 IPv4-Telnet-Sitzungen.

  • rate-limit limit– Maximale Anzahl der akzeptierten Verbindungsversuche pro Minute (von 1 bis 250). Der Standardwert ist 150. Wenn Sie ein Ratenlimit konfigurieren, gilt das Limit für die Anzahl der Verbindungsversuche pro Protokoll (IPv4 und IPv6). Ein Ratenlimit von 10 erlaubt beispielsweise 10 Verbindungsversuche für IPv6-Telnet-Sitzungen pro Minute und 10 Verbindungsversuche für IPv4-Telnet-Sitzungen pro Minute.

Konfigurieren des FTP-Dienstes für den Remote-Zugriff auf den Router oder Switch

Um das Gerät so zu konfigurieren, dass es FTP als Zugriffsdienst akzeptiert, fügen Sie die ftp Anweisung auf Hierarchieebene [edit system services] ein:

Sie können passives FTP verwenden, um auf Geräte zuzugreifen, die nur passive FTP-Dienste akzeptieren. Alle Befehle und Anweisungen, die FTP verwenden, akzeptieren auch passives FTP. Fügen Sie die ftp Anweisung auf der [edit system services] Hierarchieebene ein, um entweder aktives FTP oder passives FTP zu verwenden.

Um eine passive FTP-Sitzung zu starten, verwenden Sie pasvftp (anstelle von ftp ) im Standard-FTP-Format (ftp://destination). Zum Beispiel:

Konfigurieren des Fingerdienstes für den Remotezugriff auf den Router

Um den Router so zu konfigurieren, dass er Finger als Zugriffsdienst akzeptiert, fügen Sie die finger Anweisung auf Hierarchieebene [edit system services] ein:

SSH-Dienst für den Remotezugriff auf Router oder Switch konfigurieren

Um den Router oder Switch so zu konfigurieren, dass er SSH als Zugriffsdienst akzeptiert, fügen Sie die ssh Anweisung auf Hierarchieebene [edit system services] ein:

Standardmäßig unterstützt der Router oder Switch eine begrenzte Anzahl gleichzeitiger SSH-Sitzungen und Verbindungsversuche pro Minute. Verwenden Sie die folgenden Anweisungen, um die Standardwerte zu ändern:

  • connection-limit limit– Maximale Anzahl gleichzeitiger Verbindungen pro Protokoll (IPv4 und IPv6) Der Bereich liegt zwischen 1 und 250. Der Standardwert ist 75. Wenn Sie ein Verbindungslimit konfigurieren, gilt das Limit für die Anzahl der SSH-Sitzungen pro Protokoll (IPv4 und IPv6). Ein Verbindungslimit von 10 erlaubt beispielsweise 10 IPv6-SSH-Sitzungen und 10 IPv4-SSH-Sitzungen.

  • max-sessions-per-connection number– Fügen Sie diese Anweisung ein, um die maximale Anzahl von SSH-Sitzungen anzugeben, die pro einzelner SSH-Verbindung zulässig sind. Auf diese Weise können Sie die Anzahl der geklonten Sitzungen begrenzen, die innerhalb einer einzelnen SSH-Verbindung getunnelt werden. Der Standardwert ist 10.

  • rate-limit limit– Maximale Anzahl der pro Minute akzeptierten Verbindungsversuche (ein Wert zwischen 1 und 250). Der Standardwert ist 150. Wenn Sie ein Ratenlimit konfigurieren, gilt das Limit für die Anzahl der Verbindungsversuche pro Protokoll (IPv4 und IPv6). Ein Ratenlimit von 10 erlaubt beispielsweise 10 IPv6-SSH-Sitzungsverbindungsversuche pro Minute und 10 IPv4-SSH-Sitzungsverbindungsversuche pro Minute.

  • data-limit– Datenlimit vor der Neuverhandlung von Sitzungsschlüsseln (Byte)

  • time-limit– Zeitlimit vor der Neuverhandlung von Sitzungsschlüsseln (Minuten)

Standardmäßig kann ein Benutzer über SSH einen SSH-Tunnel über eine CLI-Sitzung zu einem Router erstellen, auf dem Junos OS ausgeführt wird. Diese Art von Tunnel kann verwendet werden, um TCP-Datenverkehr weiterzuleiten, wobei alle Firewall-Filter oder Zugriffskontrolllisten umgangen werden. Durch Umgehen von Firewall-Filtern oder Zugriffskontrolllisten ermöglicht diese Art von Tunnel den Zugriff auf Ressourcen außerhalb des Routers. Verwenden Sie die no-tcp-forwarding Option, um zu verhindern, dass ein Benutzer über SSH einen SSH-Tunnel zu einem Router erstellt.

Juniper Networks verstärkt die Parameter der Finite-Feld-Kryptographie (FFC) in der bestehenden Public-Key-Kryptografie, um das Risiko zu verringern, dass kryptografisch relevante Quantencomputer (CRQCs) Quantenpuffer für das SSH-Protokoll verwenden. Dieser Quantenpuffer-Ansatz erweitert das Zeitfenster und widersteht kryptoanalytischen Angriffen, indem er FFC-Parameter verstärkt. Siehe Der Quantenpuffer.

Informationen zu anderen Konfigurationseinstellungen finden Sie in den folgenden Themen:

Konfigurieren Sie die Root-Anmeldung über SSH

Standardmäßig können sich Benutzer über SSH beim Router oder Switch root anmelden, wenn für die Authentifizierungsmethode kein Kennwort erforderlich ist. Um den Benutzerzugriff über SSH zu steuern, fügen Sie die root-login Anweisung auf Hierarchieebene [edit systems services ssh] ein:

allow– Ermöglicht Benutzern, sich über SSH als Root beim Router oder Switch anzumelden.

deny—Verhindert, dass sich Benutzer über SSH als Root beim Router oder Switch anmelden.

deny-password Ermöglicht Benutzern, sich über SSH als Root beim Router oder Switch anzumelden, wenn für die Authentifizierungsmethode (z. B. RSA) kein Kennwort erforderlich ist.

Der Standardwert ist deny-password.

Konfigurieren eingehender SFTP-Verbindungen

Das SSH File Transfer Protocol (SFTP) ist ein Netzwerkprotokoll, das Dateizugriff, Dateiübertragung und Dateiverwaltung über jeden zuverlässigen Datenstrom ermöglicht. Eingehende SFTP-Verbindungen sind standardmäßig deaktiviert. Falls gewünscht, können Sie eingehende SFTP-Verbindungen global aktivieren, indem Sie die Anweisung sftp-server auf Hierarchieebene [edit system services ssh] konfigurieren.

Hinweis:

Nur die eingehenden SFTP-Verbindungen sind standardmäßig deaktiviert. Bei den Geräten A und B können Sie beispielsweise standardmäßig keine Verbindung über SFTP von B nach A herstellen. Sie können jedoch über SFTP eine Verbindung von Gerät B zu Gerät A herstellen, wenn Sie auf Gerät A konfigurieren sftp-server .

Die eingehenden SFTP-Verbindungen sind standardmäßig deaktiviert. So aktivieren Sie eingehende SFTP-Verbindungen:

  1. Konfigurieren Sie die sftp-server Anweisung auf Hierarchieebene[edit system services ssh]:
  2. Bestätigen Sie die Konfiguration.

    Die sftp-server Anweisung ist jetzt aktiv. Daher werden die eingehenden SFTP-Verbindungen aktiviert.

SSH-Protokollversion konfigurieren

Standardmäßig ist nur Version 2 des SSH-Protokolls aktiviert.

Um den Router oder Switch für die Verwendung von Version 2 des SSH-Protokolls zu konfigurieren, fügen Sie die protocol-version Anweisung hinzu und geben Sie auf Hierarchieebene [edit system services ssh] Folgendes anv2:

Konfigurieren des Client Alive-Mechanismus

Der Client-Alive-Mechanismus ist wertvoll, wenn der Client oder Server darauf angewiesen ist, zu wissen, wann eine Verbindung inaktiv geworden ist. Er unterscheidet sich vom standardmäßigen Keepalive-Mechanismus, da die Client-Alive-Nachrichten über den verschlüsselten Kanal gesendet werden. Der Client-Alive-Mechanismus ist standardmäßig nicht aktiviert. Um es zu aktivieren, konfigurieren Sie die client-alive-count-max and-Anweisungen client-alive-interval . Diese Option gilt nur für SSH-Protokollversion 2.

Im folgenden Beispiel werden nicht reagierende SSH-Clients nach ca. 100 Sekunden (20 x 5) getrennt:

Konfigurieren des SSH-Fingerabdruck-Hash-Algorithmus

Um den Hashalgorithmus zu konfigurieren, der vom SSH-Server verwendet wird, wenn er Schlüsselfingerabdrücke anzeigt, schließen Sie die Anweisung ein und geben md5 Sie an fingerprint-hash oder sha2-256 auf Hierarchieebene[edit system services ssh]:

SSH-Zertifikatbasierte Authentifizierung – Übersicht

Ab Junos OS und Junos OS Evolved Version 22.4R1 können Sie die zertifikatbasierte SSH-Authentifizierung für Benutzer und Hosts konfigurieren. Mit dieser Funktion können Sie einen passwortlosen SSH-Zugriff für Benutzer einrichten und Hosts vertrauen, ohne Schlüssel-Fingerabdrücke zu überprüfen.

Vorteile der zertifikatbasierten SSH-Authentifizierung

  • Bei der zertifikatbasierten SSH-Authentifizierung müssen sich Benutzer keine Passwörter merken und eingeben, wodurch der Anmeldevorgang rationalisiert wird.

  • Im Vergleich zu herkömmlichen passwortbasierten Ansätzen bieten SSH-Zertifikate eine höhere Sicherheit. Sie sind schwieriger zu knacken, da kein Passwort erraten oder geknackt werden muss.

  • SSH-Zertifikate vereinfachen die Verwaltung von Authentifizierungsschlüsseln. Anstatt einzelne Schlüssel für jeden Benutzer und Host zu verwalten, können Administratoren Zertifikate von einer zentralen Zertifizierungsstelle aus ausstellen und widerrufen.

Generieren von Signaturschlüsseln

Signaturschlüssel sind spezielle kryptografische Schlüssel, die in der zertifikatbasierten SSH-Authentifizierung verwendet werden. Der erste Schritt zum Konfigurieren der zertifikatbasierten SSH-Authentifizierung besteht darin, Signaturschlüssel zu generieren. Sie können Signaturschlüssel auf jedem Linux/FreeBSD-System generieren. Führen Sie die folgenden Schritte aus, um Signaturschlüssel für die zertifikatbasierte SSH-Authentifizierung zu generieren:

  1. Führen Sie den folgenden Befehl aus: ssh-keygen -f <filename_ca>. Dadurch werden ein privater Schlüssel mit dem Namen <filename_ca> und ein entsprechender öffentlicher Schlüssel mit dem Namen erstellt <filename_ca.pub>.

  2. Melden Sie sich bei Ihrem Juniper Gerät an und konfigurieren Sie die SSH-Schlüsseldatei der vertrauenswürdigen Benutzerzertifizierungsstelle (CA), indem Sie den folgenden Befehl ausführen: set system services ssh trusted-user-ca-key-file <path-to-public-key> und bestätigen Sie dann die Konfiguration.

  3. Jeder Benutzer kann seine eigenen Benutzerschlüssel mit dem folgenden CLI-Befehl generieren: ssh-keygen -t <rsa|ecdsa|ed25519>.

  4. Kopieren Sie den vom Benutzer erstellten öffentlichen Schlüssel auf den Computer, der die Benutzerzertifikate <filename_ca> und <filename_ca.pub>enthält.

  5. Signieren Sie den öffentlichen Schlüssel des Benutzers in der <filename_ca.pub> Datei.

Konfiguration

Verwenden Sie die folgenden CLI-Konfigurationsanweisungen, um die zertifikatbasierte SSH-Authentifizierung zu konfigurieren:

  • [system services ssh trusted-user-ca-key-file filename]– Konfigurieren Sie die TrustedUserCAKey Datei, die die öffentlichen Schlüssel eines SSH-Zertifikats enthält.

  • [system services ssh host-certificate-file filename]– Konfigurieren Sie die HostCertificate Datei, die das signierte Hostzertifikat enthält.

  • [system services ssh authorized-principals-file filename]– Konfigurieren Sie die AuthorizedPrincipals Datei, die eine Liste von Namen enthält, von denen einer im Zertifikat erscheinen muss, damit sie zur Authentifizierung akzeptiert wird.

  • [system services ssh authorized-principals-command program-path]– Geben Sie ein Programm an, das zum Generieren der Liste der zulässigen Zertifikatsprinzipale in der AuthorizedPrincipals Datei verwendet werden soll.

SSH deaktivieren

Wenn Sie SSH aktiviert haben und deaktivieren möchten, entfernen Sie einfach die ssh Anweisung von der [edit system services] Hierarchieebene.

Wenn Sie nur externes SSH deaktivieren möchten, verwenden Sie die access-disable-external Anweisung auf Hierarchieebene [edit system services ssh] .

Wenn SSH standardmäßig aktiviert ist, können Sie es nicht wie gewohnt über die [edit system services] Hierarchie deaktivieren. Stattdessen können Sie einen Firewall-Filter konfigurieren, um SSH-Zugriff zu verweigern:

Schritt-für-Schritt-Anleitung

Führen Sie die folgenden Schritte aus, um einen Firewall-Filter so zu konfigurieren, dass der SSH-Zugriff verweigert wird:

  1. Definieren Sie den Filterbegriff 1. Dieser Begriff verweigert TCP-Datenverkehr von SSH:

  2. Definieren Sie den Filterbegriff 2. Dieser Begriff erlaubt jeden Datenverkehr, der nicht durch den Filterbegriff 1abgelehnt wird:

Weitere Informationen zur Verwendung von Firewallfiltern zum Deaktivieren von SSH finden Sie unter Beispiel: Konfigurieren eines Filters zum Blockieren von Telnet- und SSH-Zugriff.

Der telnet-Befehl

Sie können den Befehl CLI telnet verwenden, um eine Telnet-Sitzung mit einem Remote-Gerät zu öffnen:

Um die Telnet-Sitzung zu beenden und zur Telnet-Eingabeaufforderung zurückzukehren, drücken Sie Strg-].

Um die Telnet-Sitzung zu beenden und zur CLI-Eingabeaufforderung zurückzukehren, geben Sie quitein.

Tabelle 1: CLI-Telnet-Befehlsoptionen

Option

Beschreibung

8bit

Verwenden Sie einen 8-Bit-Datenpfad.

host

Öffnen Sie eine Telnet-Sitzung mit dem angegebenen Hostnamen oder der angegebenen IP-Adresse.

inet

Erzwingen Sie die Telnet-Sitzung zu einem IPv4-Ziel.

inet6

Erzwingen Sie die Telnet-Sitzung zu einem IPv6-Ziel.

port port

Geben Sie die Portnummer oder den Dienstnamen auf dem Host an.

routing-instance routing-instance-name

Verwenden Sie die angegebene Routing-Instanz für die Telnet-Sitzung.

Der Befehl ssh

Sie können den Befehl CLI ssh verwenden, um das Secure Shell-Programm (SSH) zu verwenden, um eine Verbindung zu einem Remote-Gerät zu öffnen:

In Tabelle 2 werden die ssh Befehlsoptionen beschrieben.

Tabelle 2: CLI-SSH-Befehlsoptionen

Option

Beschreibung

bypass-routing

Umgehen Sie die Routing-Tabellen und öffnen Sie eine SSH-Verbindung nur zu Hosts auf direkt angeschlossenen Schnittstellen. Befindet sich der Host nicht auf einer direkt angeschlossenen Schnittstelle, wird eine Fehlermeldung zurückgegeben.

host

Öffnen Sie eine SSH-Verbindung mit dem angegebenen Hostnamen oder der angegebenen IP-Adresse.

inet

Erzwingen Sie die SSH-Verbindung zu einem IPv4-Ziel.

inet6

Erzwingen Sie die SSH-Verbindung zu einem IPv6-Ziel.

interface source-interface

Öffnen Sie eine SSH-Verbindung zu einem Host auf der angegebenen Schnittstelle. Wenn Sie diese Option nicht einschließen, werden alle Schnittstellen verwendet.

routing-instance routing-instance-name

Verwenden Sie die angegebene Routing-Instanz für die SSH-Verbindung.

logical-system

Verwenden Sie das angegebene logische System für die SSH-Verbindung.

source address

Verwenden Sie die angegebene Quelladresse für die SSH-Verbindung.

v2

Erzwingen Sie, dass SSH Version 2 für die Verbindung verwendet.

Konfigurieren Sie bekannte SSH-Hostschlüssel für sicheres Kopieren von Daten

Secure Shell (SSH) verwendet Verschlüsselungsalgorithmen , um ein Host-, Server- und Sitzungsschlüsselsystem zu generieren, das eine sichere Datenübertragung gewährleistet. Sie können SSH-Hostschlüssel so konfigurieren, dass sie Secure Copy (SCP) als Alternative zu FTP für die Hintergrundübertragung von Daten wie Konfigurationsarchiven und Ereignisprotokollen unterstützen. Um die SSH-Unterstützung für SCP zu konfigurieren, müssen Sie die folgenden Aufgaben ausführen:

  • Geben Sie bekannte SSH-Hosts an, indem Sie Hostnamen und Hostschlüsselinformationen in die Konfigurationshierarchie der Routing-Engine aufnehmen.

  • Legen Sie eine SCP-URL fest, um den Host anzugeben, von dem Daten empfangen werden sollen. Wenn Sie dieses Attribut festlegen, werden automatisch SSH-Hostschlüsselinformationen vom SCP-Server abgerufen.

  • Stellen Sie sicher, dass der Hostschlüssel authentisch ist.

  • Akzeptieren Sie die sichere Verbindung. Wenn Sie diese Verbindung akzeptieren, werden Hostschlüsselinformationen automatisch in der lokalen Hostschlüsseldatenbank gespeichert. Durch das Speichern von Hostschlüsselinformationen in der Konfigurationshierarchie wird der sichere Handshake automatisiert und die Datenübertragung im Hintergrund mithilfe von SCP ermöglicht.

Aufgaben zum Konfigurieren von SSH-Hostschlüsseln für das sichere Kopieren von Daten sind:

Konfigurieren bekannter SSH-Hosts

Um bekannte SSH-Hosts zu konfigurieren, schließen Sie die host Anweisung ein und geben Sie Hostname- und Hostschlüsseloptionen für vertrauenswürdige Server auf Hierarchieebene [edit security ssh-known-hosts] an:

Hostschlüssel sind einer der folgenden:

  • dsa-key key– Base64-codierter DSA-Schlüssel (Digital Signature Algorithm) für SSH Version 2.

  • ecdsa-sha2-nistp256-keykey– Base64-kodierter ECDSA-SHA2-NIST256-Schlüssel.

  • ecdsa-sha2-nistp384-keykey– Base64-kodierter ECDSA-SHA2-NIST384-Schlüssel.

  • ecdsa-sha2-nistp521-keykey– Base64-kodierter ECDSA-SHA2-NIST521-Schlüssel.

  • ed25519-keykey– Base64-kodierter ED25519 Schlüssel.

  • rsa-key key– Base64-codierter Public-Key-Algorithmus, der Verschlüsselung und digitale Signaturen für SSH Version 1 und SSH Version 2 unterstützt.

  • rsa1-key key– Base64-codierter RSA-Public-Key-Algorithmus, der Verschlüsselung und digitale Signaturen für SSH Version 1 unterstützt.

Konfigurieren der Unterstützung für SCP-Dateiübertragung

Um einen bekannten Host für die Unterstützung von SCP-Dateiübertragungen im Hintergrund zu konfigurieren, schließen Sie die archive-sites Anweisung auf Hierarchieebene [edit system archival configuration] ein.

Hinweis:

Wenn Sie eine URL in einer Junos OS Evolved-Anweisung mit einer IPv6-Hostadresse angeben, müssen Sie die gesamte URL in Anführungszeichen (" ") und die IPv6-Hostadresse in Klammern ([ ]) einschließen. Zum Beispiel "scp://username<:password>@[host]<:port>/url-path";

Wenn die Anweisung so festgelegt wird, dass sie archive-sites auf eine SCP-URL verweist, wird der automatische Abruf des Hostschlüssels ausgelöst. An diesem Punkt stellt Junos OS Evolved eine Verbindung zum SCP-Host her, um den öffentlichen SSH-Schlüssel abzurufen, zeigt den Host Key Message Digest oder den Fingerabdruck als Ausgabe an die Konsole an und beendet die Verbindung zum Server.

Um die Authentizität des Hostschlüssels zu überprüfen, vergleichen Sie diesen Fingerabdruck mit einem Fingerabdruck, den Sie vom selben Host über eine vertrauenswürdige Quelle erhalten. Wenn die Fingerabdrücke identisch sind, akzeptieren Sie den Hostschlüssel, indem Sie ihn an der Eingabeaufforderung eingeben yes . Die Schlüsselinformationen des Hosts werden dann in der Konfiguration der Routing-Engine gespeichert und unterstützen Hintergrunddatenübertragungen mit SCP.

SSH-Host-Schlüsselinformationen aktualisieren

In der Regel werden SSH-Hostschlüsselinformationen automatisch abgerufen, wenn Sie ein URL-Attribut für SCP mit der archival configuration archive-sites Anweisung auf Hierarchieebene [edit system] festlegen. Wenn Sie die Hostschlüsseldatenbank jedoch manuell aktualisieren müssen, verwenden Sie eine der folgenden Methoden.

Host-Schlüsselinformationen manuell abrufen

Um die Schlüsselinformationen des öffentlichen SSH-Hosts manuell abzurufen, konfigurieren Sie die fetch-from-server Option auf Hierarchieebene [edit security ssh-known-hosts] . Sie müssen den Host angeben, von dem der öffentliche SSH-Schlüssel abgerufen werden soll.

Importieren von Hostschlüsselinformationen aus einer Datei

Um SSH-Hostschlüsselinformationen manuell aus einer known_hosts Datei zu importieren, schließen Sie die load-key-file Option auf Hierarchieebene [edit security ssh-known-hosts] ein. Sie müssen den Pfad zu der Datei angeben, aus der Hostschlüsselinformationen importiert werden sollen.

SSH-Dienst für die Unterstützung von Legacy-Kryptografie konfigurieren

Sie können Junos OS Evolved so konfigurieren, dass es Legacy-Kryptografie, Chiffren und Schlüsselaustauschmethoden unterstützt.

Junos OS Evolved unterstützt standardmäßig die folgenden Chiffrensätze:

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

In Junos OS Evolved werden die folgenden Verschlüsselungen standardmäßig nicht unterstützt, aber Sie können Ihr Gerät so konfigurieren, dass sie unterstützt werden. Sie sind von den sichersten bis zu den am wenigsten sicheren aufgelistet:

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

Junos OS Evolved unterstützt standardmäßig die folgenden Schlüsselaustauschmethoden:

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

In Junos OS Evolved werden die folgenden Schlüsselaustauschmethoden standardmäßig nicht unterstützt, aber Sie können Ihr Gerät so konfigurieren, dass sie unterstützt werden:

  • group-exchange-sha1

  • dh-group1-sha1

So konfigurieren Sie den SSH-Dienst für die Unterstützung von Legacy-Kryptografie:

Hinweis:

Durch Konfigurieren eines geordneten Satzes von Verschlüsselungsverfahren, Schlüsselaustauschmethoden oder MACs (Message Authentifizierung Codes) wird der neu definierte Satz sowohl auf Server- als auch auf Clientbefehle angewendet. Änderungen an den Standardeinstellungen wirken sich auf den file copy Befehl aus, wenn Sie Secure Copy Protocol (SCP) verwenden.

  1. Fügen Sie mithilfe des set system services ssh ciphers [ cipher 1 cipher 2 ... ] Befehls Unterstützung für Chiffren hinzu. Es wird empfohlen, die Verschlüsselungen am Ende der Konfigurationsliste hinzuzufügen, damit sie zu den zuletzt verwendeten Optionen gehören. Im folgenden Beispiel werden die arcfour blowfish-cbc und Chiffren zum Standardsatz hinzugefügt:
  2. Fügen Sie mithilfe des set system services ssh key-exchange [ method 1 method 2 ... ] Befehls Unterstützung für Schlüsselaustauschmethoden hinzu. Es wird empfohlen, die Schlüsselaustauschmethoden am Ende der Konfigurationsliste hinzuzufügen, damit sie zu den zuletzt verwendeten Optionen gehören. Im folgenden Beispiel wird die dh-group1-sha1 Schlüsselaustauschmethode dem Standardsatz hinzugefügt:
  3. Bestätigen Sie die Konfiguration:

Siehe auch

Konfigurieren des ausgehenden SSH-Diensts

Sie können ein Gerät mit Junos OS Evolved so konfigurieren, dass eine TCP/IP-Verbindung mit einer Client-Verwaltungsanwendung initiiert wird. Wenn die Verwaltungsanwendung ein Gerät von Juniper Networks nicht erreicht, z. B. wenn es sich bei dem Gerät um eine Firewall handelt. Kann in solchen Fällen outbound-ssh auf dem Gerät von Juniper Networks konfiguriert werden. Eine outbound-ssh Konfiguration initiiert eine umgekehrte SSH-Verbindung vom Server zum Client zur Verwaltungsanwendung. Diese ausgehende SSH-Verbindung wird erst geschlossen, nachdem die Konfiguration vom Gerät entfernt wurde.

Hinweis:

Es gibt keinen Initiierungsbefehl mit ausgehendem SSH. Nachdem Sie ausgehende SSH konfiguriert und festgeschrieben haben, beginnt das Gerät, eine ausgehende SSH-Verbindung basierend auf der festgeschriebenen Konfiguration zu initiieren. Das Gerät versucht wiederholt, diese Verbindung herzustellen, bis dies erfolgreich ist. Wenn die Verbindung zwischen dem Gerät und der Clientverwaltungsanwendung unterbrochen wird, versucht das Gerät erneut, eine neue ausgehende SSH-Verbindung zu erstellen, bis dies erfolgreich ist. Diese Verbindung wird aufrechterhalten, bis die ausgehende SSH-Zeilengruppe aus der Konfiguration entfernt wird.

Um das Gerät für ausgehende SSH-Verbindungen zu konfigurieren, fügen Sie die outbound-ssh Anweisung auf Hierarchieebene [edit system services] ein:

[edit system services outbound-ssh]

In den folgenden Themen werden die Aufgaben zum Konfigurieren des ausgehenden SSH-Diensts beschrieben.

Senden des öffentlichen SSH-Hostschlüssels an den ausgehenden SSH-Client

Jedes Mal, wenn der Router oder Switch eine ausgehende SSH-Verbindung aufbaut, sendet er zunächst eine Initiierungssequenz an den Management-Client. Diese Sequenz identifiziert den Router oder Switch zum Management-Client. Innerhalb dieser Übertragung ist der Wert von device-id.

Um die Gerätekennung des Routers oder Switches zu konfigurieren, fügen Sie die device-id Anweisung auf Hierarchieebene [edit system services outbound-ssh client client-id] ein:

Die Initiierungssequenz, wenn secret nicht konfiguriert ist:

Während der Initialisierung einer SSH-Verbindung authentifiziert der Client die Identität des Geräts mithilfe des öffentlichen SSH-Hostschlüssels des Geräts. Bevor der Client die SSH-Sequenz initiieren kann, benötigt der Client daher den öffentlichen SSH-Schlüssel des Geräts. Wenn Sie die secret Anweisung konfigurieren, übergibt das Gerät seinen öffentlichen SSH-Schlüssel als Teil der ausgehenden Initiierungssequenz der SSH-Verbindung.

Wenn die secret Anweisung festgelegt ist und das Gerät eine ausgehende SSH-Verbindung aufbaut, übermittelt das Gerät seine Geräte-ID, seinen öffentlichen SSH-Schlüssel und einen SHA1-Hash, der teilweise von der secret Anweisung abgeleitet ist. Der Wert der secret Anweisung wird zwischen dem Gerät und dem Verwaltungsclient gemeinsam genutzt. Der Client verwendet den gemeinsamen geheimen Schlüssel, um den empfangenen öffentlichen SSH-Hostschlüssel zu authentifizieren, um festzustellen, ob der öffentliche Schlüssel von dem durch die device-id Anweisung identifizierten Gerät stammt.

Die Verwendung der secret Anweisung zum Transportieren des öffentlichen SSH-Hostschlüssels ist optional. Sie können den öffentlichen Schlüssel manuell transportieren und auf dem Client-System installieren.

Hinweis:

Das Einbeziehen der secret Anweisung bedeutet, dass das Gerät jedes Mal, wenn es eine Verbindung zum Client aufbaut, seinen öffentlichen SSH-Hostschlüssel sendet. Es liegt dann am Client, zu entscheiden, was mit dem SSH-Hostschlüssel geschehen soll, wenn der Client bereits über einen SSH-Schlüssel für dieses Gerät verfügt. Es wird empfohlen, die Kopie des SSH-Hostschlüssels des Clients durch den neuen Schlüssel zu ersetzen. Hostschlüssel können sich aus verschiedenen Gründen ändern. Indem Sie den Schlüssel bei jedem Verbindungsaufbau ersetzen, stellen Sie sicher, dass der Client über den neuesten Schlüssel verfügt.

Um den öffentlichen SSH-Hostschlüssel des Routers oder Switches zu senden, wenn das Gerät eine Verbindung zum Client herstellt, fügen Sie die secret Anweisung auf Hierarchieebene [edit system services outbound-ssh client client-id] ein:

Die folgende Meldung wird vom Gerät gesendet, wenn das secret Attribut konfiguriert ist:

Konfigurieren von Keepalive-Nachrichten für ausgehende SSH-Verbindungen

Nachdem die Clientanwendung über den öffentlichen SSH-Hostschlüssel des Routers oder Switches verfügt, kann sie die SSH-Sequenz so initiieren, als hätte sie die TCP/IP-Verbindung erstellt. Der Client kann das Gerät dann mit seiner Kopie des öffentlichen Host-SSH-Schlüssels des Routers oder Switches als Teil dieser Sequenz authentifizieren. Das Gerät authentifiziert den Clientbenutzer über die in Junos OS Evolved unterstützten Mechanismen (RSA/DSA, öffentliche Zeichenfolgen- oder Kennwort-Authentifizierung).

Damit das Gerät SSH-Protokoll-Keepalive-Nachrichten an die Clientanwendung senden kann, konfigurieren Sie die keep-alive Anweisung auf der [edit system services outbound-ssh client client-id] Hierarchieebene:

Konfigurieren einer neuen ausgehenden SSH-Verbindung

Wenn die Verbindung getrennt wird, beginnt das Gerät, eine neue ausgehende SSH-Verbindung zu initiieren. Um anzugeben, wie sich das Gerät nach dem Trennen einer Verbindung wieder mit dem Server verbindet, fügen Sie die reconnect-strategy folgende Anweisung auf Hierarchieebene [edit system services outbound-ssh client client-id] ein:

Sie können auch die Anzahl der Wiederholungsversuche angeben und festlegen, wie lange es dauert, bis die Wiederverbindungsversuche beendet werden. Siehe Konfigurieren von Keepalive-Nachrichten für ausgehende SSH-Verbindungen.

Konfigurieren Sie den ausgehenden SSH-Client so, dass NETCONF als verfügbarer Dienst akzeptiert wird.

Um die Anwendung so zu konfigurieren, dass NETCONF als verfügbarer Dienst akzeptiert wird, schließen Sie die services netconf Anweisung auf Hierarchieebene [edit system services outbound-ssh client client-id] ein:

Konfigurieren ausgehender SSH-Clients

Um die Clients zu konfigurieren, die für diese ausgehende SSH-Verbindung verfügbar sind, listen Sie jeden Client mit einer separaten Adressanweisung auf Hierarchieebene [edit system services outbound-ssh client client-id] auf:

Hinweis:

Ausgehende SSH-Verbindungen unterstützen IPv4- und IPv6-Adressformate.

Konfigurieren von Routinginstanzen für ausgehende SSH-Clients

Um die Verwaltungsrouting-Instanz zu verwenden, aktivieren Sie zuerst die mgmt_junos Routing-Instanz mit dem set system management-instance Befehl.

Um eine andere Routinginstanz zu verwenden, konfigurieren Sie zuerst die Routinginstanz in der [edit routing-instances] Hierarchie.

Wenn Sie keine Routing-Instance angeben, stellt Ihr Gerät die ausgehende SSH-Verbindung mithilfe der Standard-Routing-Tabelle her.

Konfigurieren von NETCONF-over-SSH-Verbindungen auf einem angegebenen TCP-Port

Mit Junos OS Evolved können Sie eingehende NETCONF-Verbindungen auf einen bestimmten TCP-Port beschränken, ohne eine Firewall konfigurieren zu müssen. Um den TCP-Port zu konfigurieren, der für NETCONF-over-SSH-Verbindungen verwendet wird, schließen Sie die port Anweisung auf Hierarchieebene [edit system services netconf ssh] ein. Der konfigurierte Port akzeptiert nur NETCONF-over-SSH-Sitzungen. Reguläre SSH-Sitzungsanfragen für diesen Port werden abgelehnt.

Sie können entweder den Standardport 830 für NETCONF-Verbindungen über SSH konfigurieren, wie in RFC 4742 angegeben, mithilfe des NETCONF-Konfigurationsprotokolls über Secure Shell (SSH) oder einen beliebigen Port von 1 bis 65535 konfigurieren.

Hinweis:

  • Der Standard-SSH-Port (22) akzeptiert weiterhin NETCONF-Sitzungen auch mit einem konfigurierten NETCONF-Serverport. Um zu deaktivieren, dass der SSH-Port NETCONF-Sitzungen akzeptiert, geben Sie dies im Anmeldeereignisskript an.

  • Es wird nicht empfohlen, die Standardports für FTP- (21) und Telnet-Dienste (23) für die Konfiguration von NETCONF-over-SSH-Verbindungen zu konfigurieren.

Zugehörige Dokumentation