Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Présentation de l’accès à distance

Vous (l’administrateur réseau) pouvez accéder à un routeur, un commutateur ou un équipement de sécurité à distance en utilisant des services tels que DHCP, Finger, FTP, rlogin, SSH et Telnet. Cette rubrique vous montre comment configurer l’accès à distance à l’aide des services Telnet, SSH, FTP et Finger.

Présentation des services système

Pour des raisons de sécurité, l’accès à distance au routeur est désactivé par défaut. Vous devez configurer le routeur explicitement afin que les utilisateurs sur des systèmes distants puissent y accéder. Les utilisateurs peuvent accéder au routeur à partir d’un système distant au moyen des services DHCP, finger, FTP, rlogin, SSH et Telnet. En outre, les applications clientes du protocole XML Junos peuvent utiliser SSL (Secure Sockets Layer) ou le service de texte clair spécifique au protocole Junos XML, entre autres.

Remarque :

Pour protéger les ressources système, vous pouvez limiter le nombre de connexions simultanées qu’un service accepte et le nombre de processus appartenant à un seul utilisateur. Si l’une des limites est dépassée, les tentatives de connexion échouent.

Configurer le service Telnet pour l’accès à distance à un routeur ou à un commutateur

Pour configurer le routeur ou le commutateur afin qu’il accepte Telnet comme service d’accès, incluez l’instruction telnet au niveau de la [edit system services] hiérarchie :

Par défaut, le routeur ou le commutateur prend en charge un nombre limité de sessions Telnet simultanées et de tentatives de connexion par minute.

Vous pouvez également inclure l’une ou l’autre des instructions suivantes, ou les deux, pour modifier les valeurs par défaut :

  • connection-limit limit: nombre maximal de connexions simultanées par protocole (IPV4 et IPv6). La plage est de 1 à 250. La valeur par défaut est 75. Lorsque vous configurez une limite de connexion, elle s’applique au nombre de sessions Telnet par protocole (IPv4 et IPv6). Par exemple, une limite de connexion de 10 autorise 10 sessions telnet IPv6 et 10 sessions telnet IPv4.

  • rate-limit limit: nombre maximal de tentatives de connexion acceptées par minute (de 1 à 250). La valeur par défaut est 150. Lorsque vous configurez une limite de débit, celle-ci s’applique au nombre de tentatives de connexion par protocole (IPv4 et IPv6). Par exemple, une limite de débit de 10 autorise 10 tentatives de connexion de session Telnet IPv6 par minute et 10 tentatives de connexion de session Telnet IPv4 par minute.

Configurer le service FTP pour l’accès à distance au routeur ou au commutateur

Pour configurer l’appareil afin qu’il accepte FTP comme service d’accès, incluez l’instruction ftp au niveau de la [edit system services] hiérarchie :

Vous pouvez utiliser le FTP passif pour accéder à des périphériques qui acceptent uniquement des services FTP passifs. Toutes les commandes et instructions qui utilisent FTP acceptent également le FTP passif. Incluez l’instruction ftp au niveau de la [edit system services] hiérarchie d’utiliser FTP actif ou FTP passif.

Pour démarrer une session FTP passive, utilisez pasvftp (au lieu de ftp ) au format FTP standard (ftp://destination). Par exemple :

Configurer le service Finger pour l’accès à distance au routeur

Pour configurer le routeur afin d’accepter finger comme service d’accès, incluez l’instruction finger au niveau de la [edit system services] hiérarchie :

Configurer le service SSH pour l’accès à distance au routeur ou au commutateur

Pour configurer le routeur ou le commutateur afin qu’il accepte SSH comme service d’accès, incluez l’instruction ssh au niveau de la [edit system services] hiérarchie :

Par défaut, le routeur ou le commutateur prend en charge un nombre limité de sessions SSH simultanées et de tentatives de connexion par minute. Utilisez les instructions suivantes pour modifier les valeurs par défaut :

  • connection-limit limit: nombre maximal de connexions simultanées par protocole (IPv4 et IPv6). La plage est une valeur comprise entre 1 et 250. La valeur par défaut est 75. Lorsque vous configurez une limite de connexion, celle-ci s’applique au nombre de sessions SSH par protocole (IPv4 et IPv6). Par exemple, une limite de connexion de 10 autorise 10 sessions SSH IPv6 et 10 sessions SSH IPv4.

  • max-sessions-per-connection number: incluez cette instruction pour spécifier le nombre maximal de sessions SSH autorisées par connexion SSH unique. Cela vous permet de limiter le nombre de sessions clonées tunnelisées dans une seule connexion SSH. La valeur par défaut est 10.

  • rate-limit limit: nombre maximal de tentatives de connexion acceptées par minute (valeur comprise entre 1 et 250). La valeur par défaut est 150. Lorsque vous configurez une limite de débit, celle-ci s’applique au nombre de tentatives de connexion par protocole (IPv4 et IPv6). Par exemple, une limite de débit de 10 autorise 10 tentatives de connexion de session SSH IPv6 par minute et 10 tentatives de connexion de session SSH IPv4 par minute.

  • data-limit: limite de données avant la renégociation des clés de session (octets)

  • time-limit: délai avant de renégocier les clés de session (minutes)

Par défaut, un utilisateur peut créer un tunnel SSH via une session CLI vers un routeur exécutant Junos OS via SSH. Ce type de tunnel peut être utilisé pour transférer le trafic TCP, en contournant les filtres de pare-feu ou les listes de contrôle d’accès. En contournant les filtres de pare-feu ou les listes de contrôle d’accès, ce type de tunnel permet d’accéder à des ressources situées au-delà du routeur. Utilisez l’option no-tcp-forwarding permettant d’empêcher un utilisateur de créer un tunnel SSH vers un routeur via SSH.

Juniper Networks renforce les paramètres de chiffrement en champ fini (FFC) dans la cryptographie à clé publique existante afin de réduire le risque lié aux ordinateurs quantiques cryptographiquement pertinents (CRQC) qui utilisent la mémoire tampon quantique pour le protocole SSH. Cette approche de tampon quantique prolonge la fenêtre de temps et résiste aux attaques cryptanalytiques en renforçant les paramètres FFC. Voir Le tampon quantique.

Pour plus d’informations sur les autres paramètres de configuration, consultez les rubriques suivantes :

Configurer la connexion racine via SSH

Par défaut, les utilisateurs sont autorisés à se connecter au routeur ou au commutateur via root SSH lorsque la méthode d’authentification ne nécessite pas de mot de passe. Pour contrôler l’accès des utilisateurs via SSH, incluez l’instruction root-login au niveau de la [edit systems services ssh] hiérarchie :

allow: permet aux utilisateurs de se connecter au routeur ou au commutateur en tant qu’utilisateur root via SSH.

deny: empêche les utilisateurs de se connecter au routeur ou au commutateur en tant qu’utilisateur root via SSH.

deny-password—Permet aux utilisateurs de se connecter au routeur ou au commutateur en tant qu’utilisateur root via SSH lorsque la méthode d’authentification (par exemple, RSA) ne nécessite pas de mot de passe.

La valeur par défaut est deny-password.

Configurer les connexions SFTP entrantes

Le protocole de transfert de fichiers SSH (SFTP) est un protocole réseau qui fournit l’accès aux fichiers, le transfert de fichiers et la gestion des fichiers sur n’importe quel flux de données fiable. Les connexions SFTP entrantes sont désactivées par défaut. Si vous le souhaitez, vous pouvez activer globalement les connexions SFTP entrantes en configurant l’instruction sftp-server au niveau de la [edit system services ssh] hiérarchie.

Remarque :

Seules les connexions SFTP entrantes sont désactivées par défaut. Par exemple, pour les périphériques A et B donnés, vous ne pouvez pas vous connecter via SFTP de B à A par défaut. Toutefois, vous pouvez vous connecter via SFTP de l’appareil B à l’équipement A si vous configurez sftp-server sur l’équipement A.

Les connexions SFTP entrantes sont désactivées par défaut. Pour activer les connexions SFTP entrantes :

  1. Configurez l’instruction sftp-server au niveau de la [edit system services ssh] hiérarchie :
  2. Validez la configuration.

    L’instruction sftp-server est maintenant active. Par conséquent, les connexions SFTP entrantes sont activées.

Configurer la version du protocole SSH

Par défaut, seule la version 2 du protocole SSH est activée.

Pour configurer le routeur ou le commutateur afin qu’il utilise la version 2 du protocole SSH, incluez l’instruction protocol-version et spécifiez v2 au niveau de la [edit system services ssh] hiérarchie :

Configurer le mécanisme Client Alive

Le mécanisme d’activation du client est utile lorsque le client ou le serveur dépend de savoir quand une connexion est devenue inactive. Il diffère du mécanisme keepalive standard car les messages de connexion du client sont envoyés via le canal chiffré. Le mécanisme client actif n’est pas activé par défaut. Pour l’activer, configurez les client-alive-count-max instructions and client-alive-interval . Cette option s’applique uniquement au protocole SSH version 2.

Dans l’exemple suivant, les clients SSH qui ne répondent pas seront déconnectés après environ 100 secondes (20 x 5) :

Configurer l’algorithme de hachage d’empreintes SSH

Pour configurer l’algorithme de hachage utilisé par le serveur SSH lorsqu’il affiche des empreintes de clé, incluez l’instruction et md5 specify fingerprint-hash ou sha2-256 au niveau de la [edit system services ssh] hiérarchie :

Présentation de l’authentification basée sur les certificats SSH

À partir de Junos OS et de Junos OS Evolved version 22.4R1, vous pouvez configurer l’authentification SSH basée sur des certificats pour les utilisateurs et les hôtes. Cette fonctionnalité vous permet d’établir un accès SSH sans mot de passe pour les utilisateurs et les hôtes de confiance sans vérifier les empreintes des clés.

Avantages de l’authentification SSH basée sur les certificats

  • L’authentification par certificat SSH élimine le besoin pour les utilisateurs de mémoriser et de saisir des mots de passe, ce qui simplifie le processus de connexion.

  • Par rapport aux approches traditionnelles basées sur des mots de passe, les certificats SSH offrent une sécurité renforcée. Ils sont plus difficiles à violer sans mot de passe à deviner ou à craquer.

  • Les certificats SSH simplifient la gestion des clés d’authentification. Au lieu de gérer des clés individuelles pour chaque utilisateur et hôte, les administrateurs peuvent émettre et révoquer des certificats auprès d’une autorité de certification centralisée.

Génération de clés de signature

Les clés de signature sont des clés cryptographiques spécialisées utilisées dans l’authentification SSH basée sur les certificats. La première étape de configuration de l’authentification SSH basée sur les certificats consiste à générer des clés de signature. Vous pouvez générer des clés de signature sur n’importe quel système Linux/FreeBSD. Procédez comme suit pour générer des clés de signature pour l’authentification basée sur les certificats SSH :

  1. Exécutez la commande : ssh-keygen -f <filename_ca>. Cela créera une clé privée nommée <filename_ca> et une clé publique correspondante nommée <filename_ca.pub>.

  2. Connectez-vous à votre appareil Juniper et configurez le fichier de clés SSH de l’autorité de certification (AC) en exécutant la commande : puis set system services ssh trusted-user-ca-key-file <path-to-public-key> validez la configuration.

  3. Chaque utilisateur peut générer ses propres clés utilisateur à l’aide de la commande CLI suivante : ssh-keygen -t <rsa|ecdsa|ed25519>.

  4. Copiez la clé publique créée par l’utilisateur sur l’ordinateur contenant les certificats <filename_ca> utilisateur et <filename_ca.pub>.

  5. Signez la clé publique de l’utilisateur dans le <filename_ca.pub> fichier.

La configuration

Pour configurer l’authentification SSH basée sur des certificats, utilisez les instructions de configuration CLI suivantes :

  • [system services ssh trusted-user-ca-key-file filename]: configure le TrustedUserCAKey fichier qui contient les clés publiques d’un certificat SSH.

  • [system services ssh host-certificate-file filename]: configure le HostCertificate fichier qui contient le certificat d’hôte signé.

  • [system services ssh authorized-principals-file filename]: configure le AuthorizedPrincipals fichier, qui contient une liste de noms, dont l’un doit apparaître dans le certificat pour qu’il soit accepté pour l’authentification.

  • [system services ssh authorized-principals-command program-path]: spécifie un programme à utiliser pour générer la liste des principaux de certificat autorisés trouvés dans le AuthorizedPrincipals fichier.

Désactivation de SSH

Si vous avez activé SSH et que vous souhaitez le désactiver, supprimez simplement l’instruction ssh du niveau hiérarchique [edit system services] .

Si vous souhaitez uniquement désactiver SSH externe, utilisez l’instruction access-disable-external au niveau de la [edit system services ssh] hiérarchie.

Lorsque SSH est activé par défaut, vous ne pouvez pas le désactiver via la hiérarchie comme d' [edit system services] habitude. À la place, vous pouvez configurer un filtre de pare-feu pour refuser l’accès SSH :

Procédure étape par étape

Procédez comme suit pour configurer un filtre de pare-feu afin de refuser l’accès SSH :

  1. Définissez le terme 1de filtre . Ce terme refuse le trafic TCP de SSH :

  2. Définissez le terme 2de filtre . Ce terme autorise tout trafic qui n'est pas refusé par le terme 1de filtre :

Pour plus d’informations sur l’utilisation de filtres de pare-feu pour désactiver SSH, consultez Exemple : configurer un filtre pour bloquer l’accès Telnet et SSH.

La commande telnet

Vous pouvez utiliser la commande CLI telnet pour ouvrir une session Telnet sur un équipement distant :

Pour quitter la session Telnet et revenir à l’invite de commande Telnet, appuyez sur Ctrl-].

Pour quitter la session Telnet et revenir à l’invite de commande de la CLI, entrez quit.

Tableau 1 : options de commande telnet de la CLI

En option

Descriptif

8bit

Utilisez un chemin de données de 8 bits.

host

Ouvrez une session Telnet sur le nom d’hôte ou l’adresse IP spécifié.

inet

Forcer la session Telnet vers une destination IPv4.

inet6

Forcer la session Telnet vers une destination IPv6.

port port

Spécifiez le numéro de port ou le nom du service sur l’hôte.

routing-instance routing-instance-name

Utilisez l’instance de routage spécifiée pour la session Telnet.

La commande ssh

Vous pouvez utiliser la commande CLI pour utiliser le programme Secure Shell ssh (SSH) afin d’ouvrir une connexion à un périphérique distant :

Le Tableau 2 décrit les options de ssh commande.

Tableau 2 : options de commande SSH de la CLI

En option

Descriptif

bypass-routing

Contournez les tables de routage et ouvrez une connexion SSH uniquement aux hôtes des interfaces directement connectées. Si l’hôte n’est pas sur une interface directement connectée, un message d’erreur est renvoyé.

host

Ouvrez une connexion SSH au nom d’hôte ou à l’adresse IP spécifié.

inet

Forcer la connexion SSH à une destination IPv4.

inet6

Forcer la connexion SSH à une destination IPv6.

interface source-interface

Ouvrez une connexion SSH à un hôte sur l’interface spécifiée. Si vous n’incluez pas cette option, toutes les interfaces sont utilisées.

routing-instance routing-instance-name

Utilisez l’instance de routage spécifiée pour la connexion SSH.

logical-system

Utilisez le système logique spécifié pour la connexion SSH.

source address

Utilisez l’adresse source spécifiée pour la connexion SSH.

v2

Forcer SSH à utiliser la version 2 pour la connexion.

Configurer les clés d’hôte connues SSH pour la copie sécurisée des données

Secure Shell (SSH) utilise des algorithmes de chiffrement pour générer un système de clés d’hôte, de serveur et de session qui garantit un transfert sécurisé des données. Vous pouvez configurer les clés d’hôte SSH pour prendre en charge la copie sécurisée (SCP) au lieu de FTP pour le transfert en arrière-plan de données telles que les archives de configuration et les journaux d’événements. Pour configurer la prise en charge SSH pour SCP, vous devez effectuer les tâches suivantes :

  • Spécifiez les hôtes connus SSH en incluant les noms d’hôte et les informations de clé d’hôte dans la hiérarchie de configuration du moteur de routage.

  • Définissez une URL SCP pour spécifier l’hôte à partir duquel recevoir les données. La définition de cet attribut récupère automatiquement les informations de clé de l’hôte SSH à partir du serveur SCP.

  • Vérifiez que la clé d’hôte est authentique.

  • Acceptez la connexion sécurisée. L’acceptation de cette connexion stocke automatiquement les informations de clé d’hôte dans la base de données de clés d’hôte locale. Le stockage des informations de clé de l’hôte dans la hiérarchie de configuration automatise l’établissement de liaison sécurisé et permet le transfert de données en arrière-plan à l’aide de SCP.

Les tâches permettant de configurer les clés d’hôte SSH pour la copie sécurisée des données sont les suivantes :

Configurer les hôtes connus SSH

Pour configurer des hôtes connus SSH, incluez l’instruction et spécifiez les host options de nom d’hôte et de clé d’hôte pour les serveurs approuvés au niveau de la [edit security ssh-known-hosts] hiérarchie :

Les clés d’hôte sont l’une des suivantes :

  • dsa-key key—Clé DSA (Digital Signature Algorithm) codée en Base64 pour SSH version 2.

  • ecdsa-sha2-nistp256-keykey—Clé ECDSA-SHA2-NIST256 codée en Base64.

  • ecdsa-sha2-nistp384-keykey—Clé ECDSA-SHA2-NIST384 codée en Base64.

  • ecdsa-sha2-nistp521-keykey—Clé ECDSA-SHA2-NIST521 codée en Base64.

  • ed25519-keykey—Clé ED25519 encodée en Base64.

  • rsa-key key—Algorithme de clé publique codé en Base64 qui prend en charge le chiffrement et les signatures numériques pour SSH version 1 et SSH version 2.

  • rsa1-key key—Algorithme de clé publique RSA codé en Base64, qui prend en charge le chiffrement et les signatures numériques pour SSH version 1.

Configurer la prise en charge du transfert de fichiers SCP

Pour configurer un hôte connu afin de prendre en charge les transferts de fichiers SCP en arrière-plan, incluez l’instruction archive-sites au niveau de la [edit system archival configuration] hiérarchie.

Remarque :

Lorsque vous spécifiez une URL dans une instruction Junos OS Evolved utilisant une adresse hôte IPv6, vous devez placer l’URL entière entre guillemets ( » « ) et placer l’adresse hôte IPv6 entre crochets ([ ]). Par exemple, « scp://username< :password>@[host]< :port>/url-path » ;

La définition de l’instruction pour qu’elle pointe vers une URL SCP déclenche la récupération automatique de la archive-sites clé d’hôte. À ce stade, Junos OS Evolved se connecte à l’hôte SCP pour récupérer la clé publique SSH, affiche le résumé du message de la clé hôte ou l’empreinte digitale en sortie à la console et met fin à la connexion au serveur.

Pour vérifier l’authenticité de la clé d’hôte, comparez cette empreinte avec une empreinte que vous obtenez du même hôte à l’aide d’une source approuvée. Si les empreintes sont identiques, acceptez la clé de l’hôte en entrant yes à l’invite. Les informations de clé de l’hôte sont ensuite stockées dans la configuration du moteur de routage et prennent en charge les transferts de données en arrière-plan à l’aide de SCP.

Mettre à jour les informations de clé de l’hôte SSH

En règle générale, les informations de clé d’hôte SSH sont automatiquement récupérées lorsque vous définissez un attribut d’URL pour SCP à l’aide de l’instruction archival configuration archive-sites au niveau de la [edit system] hiérarchie. Toutefois, si vous devez mettre à jour manuellement la base de données de clés d’hôte, utilisez l’une des méthodes suivantes.

Récupération manuelle des informations de clé de l’hôte

Pour récupérer manuellement les informations de clé d’hôte public SSH, configurez l’option fetch-from-server au niveau de la [edit security ssh-known-hosts] hiérarchie. Vous devez spécifier l’hôte à partir duquel récupérer la clé publique SSH.

Importation des informations de clé d’hôte à partir d’un fichier

Pour importer manuellement les informations de clé d’hôte SSH à partir d’un fichier known_hosts , incluez l’option load-key-file au niveau de la [edit security ssh-known-hosts] hiérarchie. Vous devez spécifier le chemin d’accès au fichier à partir duquel importer les informations de clé d’hôte.

Configurer le service SSH pour prendre en charge la cryptographie héritée

Vous pouvez configurer Junos OS Evolved pour prendre en charge la cryptographie, les chiffrements et les méthodes d’échange de clés hérités.

Par défaut, Junos OS Evolved prend en charge l’ensemble de chiffrements suivant :

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

Dans Junos OS Evolved, les chiffrements suivants ne sont pas pris en charge par défaut, mais vous pouvez configurer votre équipement pour les prendre en charge. Ils sont répertoriés du plus sécurisé au moins sécurisé :

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

Par défaut, Junos OS Evolved prend en charge les méthodes d’échange de clés suivantes :

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

Dans Junos OS Evolved, les méthodes d’échange de clés suivantes ne sont pas prises en charge par défaut, mais vous pouvez configurer votre équipement pour les prendre en charge :

  • group-exchange-sha1

  • dh-group1-sha1

Pour configurer le service SSH afin qu’il prenne en charge la cryptographie héritée :

Remarque :

En configurant un ensemble ordonné de chiffrements, de méthodes d’échange de clés ou de codes d’authentification de message (MAC), le nouvel ensemble défini est appliqué aux commandes serveur et client. Les modifications apportées aux valeurs par défaut affectent la commande lorsque vous utilisez le file copy protocole SCP (Secure Copy Protocol).

  1. Ajout de la prise en charge des chiffrements à l’aide de la set system services ssh ciphers [ cipher 1 cipher 2 ... ] commande. Nous vous recommandons d’ajouter les chiffrements à la fin de la liste de configuration afin qu’ils figurent parmi les dernières options utilisées. Dans l’exemple suivant, les arcfour chiffrements et blowfish-cbc sont ajoutés à l’ensemble par défaut :
  2. Ajoutez la prise en charge des méthodes d’échange de clés à l’aide de la set system services ssh key-exchange [ method 1 method 2 ... ] commande. Nous vous recommandons d’ajouter les méthodes d’échange de clés à la fin de la liste de configuration afin qu’elles figurent parmi les dernières options utilisées. Dans l’exemple suivant, la dh-group1-sha1 méthode key-exchange est ajoutée à l’ensemble par défaut :
  3. Validez la configuration :

Voir aussi

Configurer le service SSH sortant

Vous pouvez configurer un équipement exécutant Junos OS Evolved pour initier une connexion TCP/IP avec une application de gestion cliente. Si l’application de gestion n’atteint pas un appareil de Juniper Networks, par exemple, s’il s’agit d’un pare-feu. Dans ce cas, outbound-ssh peut être configuré sur l’appareil Juniper Networks. Une outbound-ssh configuration initie une connexion SSH inverse du serveur au client jusqu’à l’application de gestion. Cette connexion SSH sortante n’est fermée qu’une fois la configuration supprimée de l’appareil.

Remarque :

Il n’y a pas de commande d’initiation avec SSH sortant. Une fois que vous avez configuré et validé SSH sortant, l’appareil commence à initier une connexion SSH sortante en fonction de la configuration validée. L’appareil tente à plusieurs reprises d’établir cette connexion jusqu’à ce qu’il réussisse. Si la connexion entre l’appareil et l’application de gestion des clients est interrompue, l’appareil tente à nouveau de créer une nouvelle connexion SSH sortante jusqu’à ce qu’il réussisse. Cette connexion est maintenue jusqu’à ce que la strophe SSH sortante soit supprimée de la configuration.

Pour configurer l’appareil pour les connexions SSH sortantes, incluez l’instruction outbound-ssh au niveau de la [edit system services] hiérarchie :

[edit system services outbound-ssh]

Les rubriques suivantes décrivent les tâches de configuration du service SSH sortant.

Envoyez la clé d’hôte SSH publique au client SSH sortant

Chaque fois que le routeur ou le commutateur établit une connexion SSH sortante, il envoie d’abord une séquence d’initiation au client de gestion. Cette séquence identifie le routeur ou le commutateur au client de gestion. Dans cette transmission se trouve la valeur de device-id.

Pour configurer l’identifiant d’appareil du routeur ou du commutateur, incluez l’instruction device-id au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

La séquence de lancement n’est secret pas configurée :

Lors de l’initialisation d’une connexion SSH, le client authentifie l’identité de l’appareil à l’aide de la clé d’hôte SSH publique de l’appareil. Par conséquent, avant de pouvoir lancer la séquence SSH, le client a besoin de la clé SSH publique de l’appareil. Lorsque vous configurez l’instruction secret , l’appareil transmet sa clé SSH publique dans le cadre de la séquence d’initiation de la connexion SSH sortante.

Lorsque l’instruction secret est définie et que l’appareil établit une connexion SSH sortante, l’appareil communique son ID d’appareil, sa clé SSH publique et un hachage SHA1 dérivé en partie de l’instruction secret . La valeur de l’instruction secret est partagée entre l’appareil et le client de gestion. Le client utilise le secret partagé pour authentifier la clé d’hôte SSH publique qu’il reçoit afin de déterminer si la clé publique provient de l’appareil identifié par l’instruction device-id .

L’utilisation de l’instruction secret pour transporter la clé d’hôte SSH publique est facultative. Vous pouvez transporter et installer manuellement la clé publique sur le système client.

Remarque :

L’inclusion de l’instruction secret signifie que l’appareil envoie sa clé d’hôte SSH publique chaque fois qu’il établit une connexion au client. C’est ensuite au client de décider quoi faire avec la clé d’hôte SSH s’il dispose déjà d’une clé SSH pour cet appareil. Nous vous recommandons de remplacer la copie de la clé d’hôte SSH du client par la nouvelle clé. Les clés d’hôte peuvent changer pour diverses raisons. En remplaçant la clé chaque fois qu’une connexion est établie, vous vous assurez que le client dispose de la dernière clé.

Pour envoyer la clé d’hôte SSH publique du routeur ou du commutateur lorsque l’appareil se connecte au client, incluez l’instruction secret au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Le message suivant est envoyé par l’appareil lorsque l’attribut secret est configuré :

Configurer les messages keepalive pour les connexions SSH sortantes

Une fois que l’application cliente dispose de la clé d’hôte SSH publique du routeur ou du commutateur, elle peut lancer la séquence SSH comme si elle avait créé la connexion TCP/IP. Le client peut ensuite authentifier l’appareil à l’aide de sa copie de la clé SSH de l’hôte public du routeur ou du commutateur dans le cadre de cette séquence. L’équipement authentifie l’utilisateur client via les mécanismes pris en charge dans Junos OS Evolved (authentification par chaîne publique ou mot de passe RSA/DSA).

Pour permettre à l’appareil d’envoyer des messages keepalive de protocole SSH à l’application cliente, configurez l’instruction keep-alive au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Configurer une nouvelle connexion SSH sortante

Lorsqu’il est déconnecté, l’appareil commence à initier une nouvelle connexion SSH sortante. Pour spécifier comment l’appareil se reconnecte au serveur après l’interruption d’une connexion, incluez l’instruction reconnect-strategy au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Vous pouvez également spécifier le nombre de nouvelles tentatives et définir le délai avant l’arrêt des tentatives de reconnexion. Voir Configurer les messages keepalive pour les connexions SSH sortantes.

Configurer le client SSH sortant pour accepter NETCONF en tant que service disponible

Pour configurer l’application afin d’accepter NETCONF comme service disponible, incluez l’instruction services netconf au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Configurer les clients SSH sortants

Pour configurer les clients disponibles pour cette connexion SSH sortante, répertoriez chaque client avec une instruction d’adresse distincte au niveau de la [edit system services outbound-ssh client client-id] hiérarchie :

Remarque :

Les connexions SSH sortantes prennent en charge les formats d’adresses IPv4 et IPv6.

Configurer les instances de routage pour les clients SSH sortants

Pour utiliser l’instance de routage de gestion, activez-la d’abord à l’aide de mgmt_junos la set system management-instance commande.

Pour utiliser une autre instance de routage, configurez d’abord l’instance de routage au niveau de la [edit routing-instances] hiérarchie.

Si vous ne spécifiez pas d’instance de routage, votre appareil établira la connexion SSH sortante à l’aide de la table de routage par défaut.

Configurer des connexions NETCONF-over-SSH sur un port TCP spécifié

Junos OS Evolved vous permet de restreindre les connexions NETCONF entrantes à un port TCP spécifié sans configurer de pare-feu. Pour configurer le port TCP utilisé pour les connexions NETCONF-over-SSH, incluez l’instruction port au niveau de la [edit system services netconf ssh] hiérarchie. Le port configuré accepte uniquement les sessions NETCONF sur SSH. Les demandes de session SSH régulières pour ce port sont rejetées.

Vous pouvez configurer le port par défaut 830 pour les connexions NETCONF sur SSH, comme spécifié dans RFC 4742, à l’aide du protocole de configuration NETCONF sur Secure Shell (SSH), ou configurer n’importe quel port compris entre 1 et 65535.

Remarque :

  • Le port SSH par défaut (22) continue d’accepter les sessions NETCONF même avec un port de serveur NETCONF configuré. Pour désactiver l’acceptation des sessions NETCONF par le port SSH, spécifiez-le dans le script d’événement de connexion.

  • Il est déconseillé de configurer les ports par défaut des services FTP (21) et Telnet (23) pour configurer les connexions NETCONF sur SSH.

Documentation connexe