Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Información general sobre el acceso remoto

Usted (el administrador de red) puede acceder a un enrutador, conmutador o dispositivo de seguridad de forma remota mediante servicios como DHCP, Finger, FTP, rlogin, SSH y servicios Telnet. En este tema se muestra cómo configurar el acceso remoto mediante Telnet, SSH, FTP y servicios Finger.

Descripción general de los servicios del sistema

Por razones de seguridad, el acceso remoto al enrutador está deshabilitado de forma predeterminada. Debe configurar el enrutador explícitamente para que los usuarios de sistemas remotos puedan acceder a él. Los usuarios pueden acceder al enrutador desde un sistema remoto por medio de los servicios DHCP, finger, FTP, rlogin, SSH y Telnet. Además, las aplicaciones cliente del protocolo XML de Junos pueden usar Capa de sockets seguros (SSL) o el servicio de texto sin formato específico del protocolo XML de Junos, entre otros servicios.

Nota:

Para proteger los recursos del sistema, puede limitar el número de conexiones simultáneas que acepta un servicio y el número de procesos propiedad de un solo usuario. Si se supera cualquiera de los límites, los intentos de conexión fallan.

Configurar el servicio Telnet para el acceso remoto a un enrutador o conmutador

Para configurar el enrutador o conmutador para que acepte Telnet como servicio de acceso, incluya la telnet instrucción en el nivel de [edit system services] jerarquía:

De forma predeterminada, el enrutador o conmutador admite un número limitado de sesiones de Telnet e intentos de conexión simultáneos por minuto.

Opcionalmente, puede incluir una o ambas de las siguientes instrucciones para cambiar los valores predeterminados:

  • connection-limit limit: Número máximo de conexiones simultáneas por protocolo (IPV4 e IPv6). El rango es de 1 a 250. El valor predeterminado es 75. Cuando se configura un límite de conexión, el límite se aplica al número de sesiones Telnet por protocolo (IPv4 e IPv6). Por ejemplo, un límite de conexión de 10 permite 10 sesiones de telnet IPv6 y 10 sesiones de telnet IPv4.

  • rate-limit limit: Número máximo de intentos de conexión aceptados por minuto (de 1 a 250). El valor predeterminado es 150. Cuando se configura un límite de velocidad, el límite se aplica al número de intentos de conexión por protocolo (IPv4 e IPv6). Por ejemplo, un límite de velocidad de 10 permite 10 intentos de conexión de sesión telnet IPv6 por minuto y 10 intentos de conexión de sesión telnet IPv4 por minuto.

No puede incluir la telnet instrucción en dispositivos que ejecuten el software Junos-FIPS. Se recomienda no usar Telnet en un entorno de Common Criteria.

Configurar el servicio FTP para el acceso remoto al enrutador o conmutador

Para configurar el dispositivo para que acepte FTP como servicio de acceso, incluya la ftp instrucción en el nivel de [edit system services] jerarquía:

De forma predeterminada, el enrutador o conmutador admite un número limitado de sesiones FTP simultáneas e intentos de conexión por minuto. Puede incluir una o ambas de las siguientes instrucciones para cambiar los valores predeterminados:

  • connection-limit limit: Número máximo de conexiones simultáneas por protocolo (IPV4 e IPv6). El intervalo es un valor comprendido entre 1 y 250. El valor predeterminado es 75. Cuando se configura un límite de conexión, el límite se aplica al número de sesiones por protocolo (IPv4 e IPv6). Por ejemplo, un límite de conexión de 10 permite 10 sesiones FTP IPv6 y 10 sesiones FTP IPv4.

  • rate-limit limit: número máximo de intentos de conexión aceptados por minuto (un valor de 1 a 250). El valor predeterminado es 150. Cuando se configura un límite de velocidad, el límite se aplica al número de intentos de conexión por protocolo (IPv4 e IPv6). Por ejemplo, un límite de velocidad de 10 permite 10 intentos de conexión de sesión FTP IPv6 y 10 intentos de conexión de sesión FTP IPv4.

Puede utilizar FTP pasivo para acceder a dispositivos que solo aceptan servicios FTP pasivos. Todos los comandos e instrucciones que utilizan FTP también aceptan FTP pasivo. Incluya la ftp instrucción en el nivel de [edit system services] jerarquía para utilizar FTP activo o FTP pasivo.

Para iniciar una sesión FTP pasiva, utilice pasvftp (en lugar de ftp ) en el formato FTP estándar (ftp://destination). Por ejemplo:

No puede incluir la ftp instrucción en enrutadores o conmutadores que ejecuten el software Junos-FIPS. Se recomienda no utilizar el servicio FTP en un entorno Common Criteria.

Configurar el servicio Finger para el acceso remoto al enrutador

Para configurar el enrutador para que acepte finger como servicio de acceso, incluya la finger instrucción en el nivel de [edit system services] jerarquía:

De forma predeterminada, el enrutador admite un número limitado de sesiones simultáneas con los dedos e intentos de conexión por minuto. Opcionalmente, puede incluir una o ambas de las siguientes instrucciones para cambiar los valores predeterminados:

  • connection-limit limit: Número máximo de conexiones simultáneas por protocolo (IPv4 e IPv6). El intervalo es un valor comprendido entre 1 y 250. El valor predeterminado es 75. Cuando se configura un límite de conexión, el límite se aplica al número de sesiones por protocolo (IPv4 e IPv6). Por ejemplo, un límite de conexión de 10 permite 10 sesiones de servicio de texto sin cifrar IPv6 y 10 sesiones de servicio de texto sin cifrar IPv4

  • rate-limit limit: número máximo de intentos de conexión aceptados por minuto (un valor de 1 a 250). El valor predeterminado es 150. Cuando se configura un límite de velocidad, el límite se aplica al número de intentos de conexión por protocolo (IPv4 e IPv6). Por ejemplo, un límite de velocidad de 10 permite 10 intentos de conexión de sesión IPv6 por minuto y 10 intentos de conexión de sesión IPv4 por minuto.

No puede incluir la finger instrucción en enrutadores que ejecutan el software Junos-FIPS. Le recomendamos que no utilice el servicio finger en un entorno de Common Criteria.

Configurar el servicio SSH para el acceso remoto al enrutador o conmutador

Para configurar el enrutador o conmutador para que acepte SSH como servicio de acceso, incluya la ssh instrucción en el nivel de [edit system services] jerarquía:

De forma predeterminada, el enrutador o conmutador admite un número limitado de sesiones SSH simultáneas e intentos de conexión por minuto. Utilice las instrucciones siguientes para cambiar los valores predeterminados:

  • connection-limit limit: Número máximo de conexiones simultáneas por protocolo (IPv4 e IPv6). El intervalo es un valor comprendido entre 1 y 250. El valor predeterminado es 75. Cuando se configura un límite de conexión, el límite se aplica al número de sesiones SSH por protocolo (IPv4 e IPv6). Por ejemplo, un límite de conexión de 10 permite 10 sesiones SSH IPv6 y 10 sesiones SSH IPv4.

  • max-sessions-per-connection number: incluya esta instrucción para especificar el número máximo de sesiones SSH permitidas por conexión SSH. Esto le permite limitar el número de sesiones clonadas tunelizadas dentro de una sola conexión SSH. El valor predeterminado es 10.

  • rate-limit limit: número máximo de intentos de conexión aceptados por minuto (un valor de 1 a 250). El valor predeterminado es 150. Cuando se configura un límite de velocidad, el límite se aplica al número de intentos de conexión por protocolo (IPv4 e IPv6). Por ejemplo, un límite de velocidad de 10 permite 10 intentos de conexión de sesión SSH IPv6 por minuto y 10 intentos de conexión de sesión SSH IPv4 por minuto.

  • data-limit—Límite de datos antes de renegociar las claves de sesión (bytes)

  • time-limit—Límite de tiempo antes de renegociar las claves de sesión (minutos)

A partir de Junos OS versión 19.4R1 y Junos OS versión 17.4R3, puede deshabilitar la contraseña de inicio de sesión SSH o la autenticación desafío-respuesta mediante las no-password-authentication opciones y no-challenge-response en el nivel de jerarquía [edit system services ssh].

De forma predeterminada, un usuario puede crear un túnel SSH a través de una sesión CLI a un enrutador que ejecute Junos OS a través de SSH. Este tipo de túnel se puede utilizar para reenviar tráfico TCP, sin pasar por los filtros de firewall o las listas de control de acceso. Al omitir los filtros de firewall o las listas de control de acceso, este tipo de túnel permite el acceso a recursos más allá del enrutador. Utilice la no-tcp-forwarding opción para impedir que un usuario cree un túnel SSH a un enrutador a través de SSH.

Para obtener información acerca de otras opciones de configuración, consulte los siguientes temas:

Configurar el inicio de sesión raíz a través de SSH

De forma predeterminada, los usuarios pueden iniciar sesión en el enrutador o conmutador como root a través de SSH cuando el método de autenticación no requiere una contraseña. Para controlar el acceso de los usuarios a través de SSH, incluya la root-login instrucción en el nivel de [edit systems services ssh] jerarquía:

allow: permite a los usuarios iniciar sesión en el enrutador o conmutador como raíz a través de SSH.

deny: impide que los usuarios inicien sesión en el enrutador o conmutador como raíz mediante SSH.

deny-password—Permite a los usuarios iniciar sesión en el enrutador o conmutador como root a través de SSH cuando el método de autenticación (por ejemplo, RSA) no requiere una contraseña.

El valor predeterminado es deny-password.

Configurar conexiones SFTP entrantes

El protocolo de transferencia de archivos SSH (SFTP) es un protocolo de red que proporciona acceso a archivos, transferencia de archivos y administración de archivos a través de cualquier flujo de datos confiable. A partir de Junos OS versión 19.1R1, hemos deshabilitado globalmente las conexiones SFTP entrantes de forma predeterminada. Si lo desea, puede habilitar globalmente las conexiones SFTP entrantes configurando la instrucción sftp-server en el nivel de [edit system services ssh] jerarquía. Antes de Junos OS versión 19.1R1, las conexiones SFTP entrantes se habilitaban globalmente de forma predeterminada.

Nota:

Sólo las conexiones SFTP entrantes están deshabilitadas de forma predeterminada. Por ejemplo, dados los dispositivos A y B (donde el dispositivo A ejecuta 19.1R1), no puede conectarse a través de SFTP de B a A de forma predeterminada. Sin embargo, puede conectarse a través de SFTP desde el dispositivo B al dispositivo A si lo configura sftp-server en el dispositivo A.

Las conexiones SFTP entrantes están deshabilitadas de forma predeterminada. Para habilitar las conexiones SFTP entrantes:

  1. Configure la sftp-server instrucción en el nivel jerárquico [edit system services ssh] :
  2. Confirme la configuración.

    La sftp-server instrucción ya está activa. Por lo tanto, las conexiones SFTP entrantes están habilitadas.

Configurar la versión del protocolo SSH

De forma predeterminada, solo está habilitada la versión 2 del protocolo SSH.

Para configurar el enrutador o conmutador para que utilice la versión 2 del protocolo SSH, incluya la protocol-version instrucción y especifique v2 en el [edit system services ssh] nivel de jerarquía:

Los sistemas en modo FIPS siempre usan la versión v2del protocolo SSH.

Configurar el mecanismo de Client Alive

El mecanismo de cliente vivo es valioso cuando el cliente o servidor depende de saber cuándo una conexión se ha vuelto inactiva. Se diferencia del mecanismo keepalive estándar porque los mensajes vivos del cliente se envían a través del canal cifrado. El mecanismo de cliente activo no está habilitado de forma predeterminada. Para habilitarlo, configure las client-alive-count-max instrucciones y client-alive-interval . Esta opción solo se aplica a la versión 2 del protocolo SSH.

En el ejemplo siguiente, los clientes SSH que no responden se desconectarán después de aproximadamente 100 segundos (20 x 5):

Configurar el algoritmo hash de huella digital SSH

Para configurar el algoritmo hash utilizado por el servidor SSH cuando muestra huellas digitales clave, incluya la fingerprint-hash instrucción y especifique md5 o sha2-256 en el nivel de [edit system services ssh] jerarquía:

El md5 algoritmo hash no está disponible en sistemas en modo FIPS.

Descripción general de la autenticación basada en certificados SSH

A partir de Junos OS y Junos OS Evolved versión 22.4R1, puede configurar la autenticación basada en certificados SSH para usuarios y hosts. Esta característica le permite establecer acceso SSH sin contraseña para usuarios y hosts de confianza sin verificar las huellas digitales de las claves.

Beneficios de la autenticación basada en certificados SSH

  • La autenticación basada en certificados SSH elimina la necesidad de que los usuarios recuerden e ingresen contraseñas, lo que agiliza el proceso de inicio de sesión.

  • En comparación con los enfoques tradicionales basados en contraseñas, los certificados SSH ofrecen una seguridad más sólida. Son más difíciles de violar sin contraseña para adivinar o descifrar.

  • Los certificados SSH simplifican la administración de las claves de autenticación. En lugar de administrar claves individuales para cada usuario y host, los administradores pueden emitir y revocar certificados desde una autoridad de certificación centralizada.

Generación de claves de firma

Las claves de firma son claves criptográficas especializadas que se utilizan en la autenticación basada en certificados SSH. El primer paso para configurar la autenticación basada en certificados SSH es generar claves de firma. Puede generar claves de firma en cualquier sistema Linux/FreeBSD. Siga estos pasos para generar claves de firma para la autenticación basada en certificados SSH:

  1. Ejecute el comando: ssh-keygen -f <filename_ca>. Esto creará una clave privada denominada y <filename_ca> una clave pública correspondiente denominada <filename_ca.pub>.

  2. Inicie sesión en su dispositivo Juniper y configure el archivo de clave de entidad de certificación (CA) de usuario de confianza SSH ejecutando el comando: set system services ssh trusted-user-ca-key-file <path-to-public-key> y, a continuación, confirme la configuración.

  3. Cada usuario puede generar sus propias claves de usuario mediante el siguiente comando de CLI: ssh-keygen -t <rsa|ecdsa|ed25519>.

  4. Copie la clave pública creada por el usuario en el equipo que tenga los certificados <filename_ca> de usuario y <filename_ca.pub>.

  5. Firme la clave pública de usuario en el <filename_ca.pub> archivo.

Configuración

Para configurar la autenticación basada en certificados SSH, use las siguientes instrucciones de configuración de CLI:

  • [system services ssh trusted-user-ca-key-file filename]: configure el TrustedUserCAKey archivo en /etc/ssh/sshd_config, que contiene las claves públicas de un certificado SSH.

  • [system services ssh host-certificate-file filename]: configure el HostCertificate archivo en /etc/ssh/sshd_config, que contiene el certificado de host firmado.

  • [system services ssh authorized-principals-file filename]: configure el AuthorizedPrincipals archivo en /var/etc, que contiene una lista de nombres, uno de los cuales debe aparecer en el certificado para que sea aceptado para la autenticación.

  • [system services ssh authorized-principals-command program-path]: especifique un programa que se utilizará para generar la lista de entidades de certificación permitidas que se encuentran en el AuthorizedPrincipals archivo.

Deshabilitar SSH

Si habilitó SSH y desea deshabilitarlo, simplemente elimine la ssh instrucción del [edit system services] nivel jerárquico.

Si solo desea deshabilitar SSH externo, utilice la access-disable-external instrucción en el nivel de [edit system services ssh] jerarquía.

A partir de Junos OS versión 21.4R1, las plataformas Junos con host VM instalado tienen SSH habilitado de forma predeterminada. Cuando SSH está habilitado de forma predeterminada, no puede deshabilitarlo a través de la [edit system services] jerarquía como de costumbre. En su lugar, puede configurar un filtro de firewall para denegar el acceso SSH:

Procedimiento paso a paso

Siga estos pasos para configurar un filtro de firewall para denegar el acceso SSH:

  1. Defina el término 1de filtro . Este término deniega el tráfico TCP de SSH:

  2. Defina el término 2de filtro . Este término permite cualquier tráfico que no sea negado por el término 1de filtro:

Para obtener más información sobre el uso de filtros de firewall para deshabilitar SSH, consulte Ejemplo: Configure un filtro para bloquear el acceso Telnet y SSH.

El comando telnet

Puede usar el comando de la CLI telnet para abrir una sesión de Telnet en un dispositivo remoto:

Nota:

En los dispositivos SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345 y SRX1500, en la tabla siguiente se indica el número máximo de sesiones simultáneas de Telnet. La compatibilidad de plataforma depende de la versión de Junos OS en su instalación.

SRX100

SRX210SRX220

SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Para salir de la sesión de Telnet y volver al símbolo del sistema de Telnet, presione Ctrl-].

Para salir de la sesión de Telnet y volver al símbolo del sistema de la CLI, escriba quit.

Tabla 1: Opciones de comando telnet de CLI

La opción

Description

8bit

Utilice una ruta de datos de 8 bits.

bypass-routing

Omita las tablas de enrutamiento y abra una sesión de Telnet solo para hosts en interfaces conectadas directamente. Si el host no está en una interfaz conectada directamente, se devuelve un mensaje de error.

host

Abra una sesión Telnet con el nombre de host o la dirección IP especificados.

inet

Forzar la sesión Telnet a un destino IPv4.

interface source-interface

Abra una sesión de Telnet en un host en la interfaz especificada. Si no incluye esta opción, se utilizan todas las interfaces.

no-resolve

Suprimir la visualización de nombres simbólicos.

port port

Especifique el número de puerto o el nombre del servicio en el host.

routing-instance routing-instance-name

Utilice la instancia de enrutamiento especificada para la sesión de Telnet.

source address

Utilice la dirección de origen especificada para la sesión de Telnet.

El comando ssh

Puede usar el comando CLI ssh para usar el programa Secure Shell (SSH) para abrir una conexión a un dispositivo remoto:

Nota:

En los dispositivos SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345 y SRX1500, en la tabla siguiente se indica el número máximo de sesiones SSH simultáneas. La compatibilidad de plataforma depende de la versión de Junos OS en su instalación.

SRX100

SRX210SRX220

SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Tabla 2 Describe las opciones de ssh comando.

Tabla 2: Opciones de comando ssh de CLI

La opción

Description

bypass-routing

Omita las tablas de enrutamiento y abra una conexión SSH solo a hosts en interfaces conectadas directamente. Si el host no está en una interfaz conectada directamente, se devuelve un mensaje de error.

host

Abra una conexión SSH al nombre de host o dirección IP especificados.

inet

Forzar la conexión SSH a un destino IPv4.

interface source-interface

Abra una conexión SSH a un host en la interfaz especificada. Si no incluye esta opción, se utilizan todas las interfaces.

routing-instance routing-instance-name

Utilice la instancia de enrutamiento especificada para la conexión SSH.

source address

Utilice la dirección de origen especificada para la conexión SSH.

v1

Forzar que SSH utilice la versión 1 para la conexión.

v2

Forzar a SSH a utilizar la versión 2 para la conexión.

Configurar claves de host conocidas SSH para la copia segura de datos

Secure Shell (SSH) utiliza algoritmos de cifrado para generar un sistema de claves de host, servidor y sesión que garantiza una transferencia de datos segura. Puede configurar las claves de host SSH para que admitan la copia segura (SCP) como alternativa a FTP para la transferencia en segundo plano de datos, como archivos de configuración y registros de eventos. Para configurar la compatibilidad con SSH para SCP, debe completar las siguientes tareas:

  • Especifique hosts conocidos SSH incluyendo nombres de host e información de clave de host en la jerarquía de configuración de motor de enrutamiento.

  • Establezca una URL SCP para especificar el host del que recibir datos. Al establecer este atributo, se recupera automáticamente la información de la clave de host SSH del servidor SCP.

  • Compruebe que la clave de host es auténtica.

  • Acepte la conexión segura. La aceptación de esta conexión almacena automáticamente la información de la clave de host en la base de datos de claves de host local. El almacenamiento de la información de la clave de host en la jerarquía de configuración automatiza el protocolo de enlace seguro y permite la transferencia de datos en segundo plano mediante SCP.

Las tareas para configurar claves de host SSH para la copia segura de datos son:

Configurar hosts conocidos SSH

Para configurar hosts conocidos SSH, incluya la instrucción y especifique las opciones de host nombre de host y clave de host para servidores de confianza en el nivel jerárquico [edit security ssh-known-hosts] :

Las claves de host son una de las siguientes:

  • dsa-key key—Clave del algoritmo de firma digital codificado (DSA) Base64 para SSH versión 2.

  • ecdsa-sha2-nistp256-key key—Clave ECDSA-SHA2-NIST256 codificada en Base64.

  • ecdsa-sha2-nistp384-key key—Clave ECDSA-SHA2-NIST384 codificada en Base64.

  • ecdsa-sha2-nistp521-key key—Clave ECDSA-SHA2-NIST521 codificada en Base64.

  • ed25519-key key—Clave ED25519 codificada en Base64.

  • rsa-key key—Algoritmo de clave pública codificado Base64 que admite cifrado y firmas digitales para SSH versión 1 y SSH versión 2.

  • rsa1-key key—Algoritmo de clave pública RSA codificado en Base64, que admite cifrado y firmas digitales para SSH versión 1.

Configurar la compatibilidad con la transferencia de archivos SCP

Para configurar un host conocido para que admita transferencias de archivos SCP en segundo plano, incluya la archive-sites instrucción en el nivel de [edit system archival configuration] jerarquía.

Nota:

Al especificar una dirección URL en una Junos OS instrucción mediante una dirección de host IPv6, debe poner la dirección URL completa entre comillas (" ") y la dirección de host IPv6 entre corchetes ([ ]). Por ejemplo “scp://username<:password>@[host]<:port>/url-path”;

Si se establece la instrucción para que apunte a una URL SCP, se activa la archive-sites recuperación automática de claves de host. En este punto, Junos OS se conecta al host SCP para obtener la clave pública SSH, muestra la síntesis del mensaje de la clave de host o la huella digital como salida a la consola y finaliza la conexión con el servidor.

Para comprobar que la clave de host es auténtica, compare esta huella digital con una huella digital que obtenga del mismo host mediante una fuente de confianza. Si las huellas digitales son idénticas, escriba la clave de host en yes el indicador. A continuación, la información de la clave de host se almacena en la configuración del motor de enrutamiento y admite transferencias de datos en segundo plano mediante SCP.

Actualizar la información de la clave de host SSH

Normalmente, la información de la clave de host SSH se recupera automáticamente cuando se establece un atributo URL para SCP utilizando la archival configuration archive-sites instrucción en el nivel de [edit system] jerarquía. Sin embargo, si necesita actualizar manualmente la base de datos de claves de host, utilice uno de los métodos siguientes.

Recuperar la información de la clave de host manualmente

Para recuperar manualmente la información de la clave de host público SSH, configure la fetch-from-server opción en el nivel de [edit security ssh-known-hosts] jerarquía. Debe especificar el host del que desea recuperar la clave pública SSH.

Importar información de clave de host desde un archivo

Para importar manualmente información de clave de host SSH desde un known_hosts archivo, incluya la load-key-file opción en el nivel de [edit security ssh-known-hosts] jerarquía. Debe especificar la ruta de acceso al archivo desde el que desea importar la información de la clave de host.

Configurar el servicio SSH para admitir criptografía heredada

El servidor SSH se basa en Junos OS OpenSSH 7 y utiliza de forma predeterminada un conjunto más seguro de cifrados y algoritmos de intercambio de claves. OpenSSH 7 omite algunas criptografías heredadas.

Nota:

La falta de compatibilidad con la criptografía heredada en los dispositivos provoca un error en la detección de dispositivos de Junos Space. Para evitar este problema, configure el dispositivo para admitir el 3des-cbc cifrado o blowfish-cbc , o ambos, y el dh-group1-sha1 método de intercambio de claves. Este problema no afecta a los dispositivos que ejecutan Junos OS con FreeBSD actualizado.

Nota:

Consulte la documentación de OpenSSH 7 en https://www.openssh.com/ para obtener más información sobre estas extensiones.

Junos OS Admite el siguiente conjunto de cifrados de forma predeterminada:

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

En Junos OS, los siguientes cifrados no son compatibles de forma predeterminada, pero puede configurar el dispositivo para que los admita. Se enumeran de los más seguros a los menos seguros:

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

  • 3des-cbc

Junos OS Admite el siguiente conjunto de métodos de intercambio de claves de forma predeterminada:

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

En Junos OS, los siguientes métodos de intercambio de claves no son compatibles de forma predeterminada, pero puede configurar el dispositivo para que los admita:

  • group-exchange-sha1

  • dh-group1-sha1

Para configurar el servicio SSH para que admita la criptografía heredada:

Nota:

Mediante la configuración de un conjunto ordenado de cifrados, métodos de intercambio de claves o códigos de autenticación de mensajes (MAC), el conjunto recién definido se aplica a los comandos de servidor y cliente. Los cambios en los valores predeterminados afectan al comando cuando se utiliza el file copy Protocolo de copia segura (SCP).

  1. Agregue compatibilidad con cifrados mediante el set system services ssh ciphers [ cipher 1 cipher 2 ... ] comando. Le recomendamos que agregue los cifrados al final de la lista de configuración para que estén entre las últimas opciones utilizadas. En el ejemplo siguiente, los arcfour cifrados y blowfish-cbc se agregan al conjunto predeterminado:
  2. Agregue compatibilidad con métodos de intercambio de claves mediante el set system services ssh key-exchange [ method 1 method 2 ... ] comando. Se recomienda agregar los métodos de intercambio de claves al final de la lista de configuración para que estén entre las últimas opciones utilizadas. En el ejemplo siguiente, el dh-group1-sha1 método de intercambio de claves se agrega al conjunto predeterminado:
  3. Confirme su configuración:

Consulte también

Configurar el servicio SSH saliente

Puede configurar un dispositivo en ejecución Junos OS para iniciar una conexión TCP/IP con una aplicación de administración de clientes. Si la aplicación de administración no llega a un dispositivo de Juniper Networks, por ejemplo, el dispositivo es un firewall. En tales casos, outbound-ssh se puede configurar en el dispositivo de Juniper Networks. Una outbound-ssh configuración inicia una conexión SSH inversa del servidor al cliente y a la aplicación de administración. Esta conexión SSH saliente se cierra solo después de quitar la configuración del dispositivo.

Nota:

No hay ningún comando de iniciación con SSH saliente. Después de configurar y confirmar SSH saliente, el dispositivo comienza a iniciar una conexión SSH saliente basada en la configuración confirmada. El dispositivo intenta crear esta conexión repetidamente hasta que se realiza correctamente. Si se interrumpe la conexión entre el dispositivo y la aplicación de administración de clientes, el dispositivo vuelve a intentar crear una nueva conexión SSH saliente hasta que se realice correctamente. Esta conexión se mantiene hasta que la estrofa SSH saliente se elimina de la configuración.

Para configurar el dispositivo para conexiones SSH salientes, incluya la outbound-ssh instrucción en el nivel de [edit system services] jerarquía:

[edit system services outbound-ssh]

En los temas siguientes se describen las tareas para configurar el servicio SSH saliente.

Enviar la clave de host SSH pública al cliente SSH saliente

Cada vez que el enrutador o conmutador establece una conexión SSH saliente, primero envía una secuencia de inicio al cliente de administración. Esta secuencia identifica el enrutador o conmutador al cliente de administración. Dentro de esta transmisión está el valor de device-id.

Para configurar el identificador de dispositivo del enrutador o conmutador, incluya la device-id instrucción en el [edit system services outbound-ssh client client-id] nivel de jerarquía:

La secuencia de inicio cuando secret no está configurada:

Durante la inicialización de una conexión SSH, el cliente autentica la identidad del dispositivo mediante la clave de host SSH pública del dispositivo. Por lo tanto, antes de que el cliente pueda iniciar la secuencia SSH, el cliente necesita la clave SSH pública del dispositivo. Al configurar la secret instrucción, el dispositivo pasa su clave SSH pública como parte de la secuencia de inicio de conexión SSH saliente.

Cuando se establece la secret instrucción y el dispositivo establece una conexión SSH saliente, el dispositivo comunica su ID de dispositivo, su clave SSH pública y un hash SHA1 derivado en parte de la secret instrucción. El valor de la secret instrucción se comparte entre el dispositivo y el cliente de administración. El cliente usa el secreto compartido para autenticar la clave de host SSH pública que recibe para determinar si la clave pública proviene del dispositivo identificado por la device-id instrucción.

El uso de la secret instrucción para transportar la clave de host SSH pública es opcional. Puede transportar e instalar manualmente la clave pública en el sistema cliente.

Nota:

Incluir la secret instrucción significa que el dispositivo envía su clave de host SSH pública cada vez que establece una conexión con el cliente. A continuación, depende del cliente decidir qué hacer con la clave de host SSH si el cliente ya tiene una clave SSH para ese dispositivo. Le recomendamos que reemplace la copia del cliente de la clave de host SSH con la nueva clave. Las claves de host pueden cambiar por varios motivos. Al reemplazar la clave cada vez que se establece una conexión, se asegura de que el cliente tenga la clave más reciente.

Para enviar la clave de host SSH pública del enrutador o conmutador cuando el dispositivo se conecta al cliente, incluya la secret instrucción en el nivel de [edit system services outbound-ssh client client-id] jerarquía:

El dispositivo envía el siguiente mensaje cuando se configura el secret atributo:

Configurar mensajes Keepalive para conexiones SSH salientes

Una vez que la aplicación cliente tiene la clave de host SSH pública del enrutador o conmutador, puede iniciar la secuencia SSH como si hubiera creado la conexión TCP/IP. Luego, el cliente puede autenticar el dispositivo utilizando su copia de la clave SSH del host público del enrutador o conmutador como parte de esa secuencia. El dispositivo autentica al usuario cliente a través de los mecanismos admitidos en Junos OS (cadena pública RSA/DSA o autenticación de contraseña).

Para permitir que el dispositivo envíe mensajes keepalive de protocolo SSH a la aplicación cliente, configure la keep-alive instrucción en el nivel de [edit system services outbound-ssh client client-id] jerarquía:

Configurar una nueva conexión SSH saliente

Cuando se desconecta, el dispositivo comienza a iniciar una nueva conexión SSH saliente. Para especificar cómo se vuelve a conectar el dispositivo al servidor después de que se interrumpa una conexión, incluya la reconnect-strategy instrucción en el nivel de [edit system services outbound-ssh client client-id] jerarquía:

También puede especificar el número de intentos de reintento y establecer la cantidad de tiempo antes de que se detengan los intentos de reconexión. Consulte Configurar mensajes Keepalive para conexiones SSH salientes.

Configurar el cliente SSH saliente para aceptar NETCONF como un servicio disponible

Para configurar la aplicación para que acepte NETCONF como un servicio disponible, incluya la services netconf instrucción en el nivel de [edit system services outbound-ssh client client-id] jerarquía:

Configurar clientes SSH salientes

Para configurar los clientes disponibles para esta conexión SSH saliente, enumere cada cliente con una instrucción de dirección independiente en el nivel de [edit system services outbound-ssh client client-id] jerarquía:

Nota:

Las conexiones SSH salientes admiten los formatos de dirección IPv4 e IPv6.

Configurar instancias de enrutamiento para clientes SSH salientes

Para usar la instancia de enrutamiento de administración, habilite primero la instancia de mgmt_junos enrutamiento con el set system management-instance comando.

Para utilizar cualquier otra instancia de enrutamiento, configure primero la instancia de enrutamiento en la [edit routing-instances] jerarquía.

Si no especifica una instancia de enrutamiento, el dispositivo establecerá la conexión SSH saliente utilizando la tabla de enrutamiento predeterminada.

Configurar conexiones NETCONF-over-SSH en un puerto TCP especificado

Junos OS permite restringir las conexiones NETCONF entrantes a un puerto TCP especificado sin configurar un firewall. Para configurar el puerto TCP utilizado para las conexiones NETCONF a través de SSH, incluya la port instrucción en el nivel de [edit system services netconf ssh] jerarquía. El puerto configurado sólo acepta sesiones NETCONF-over-SSH. Se rechazan las solicitudes de sesión SSH regulares para este puerto.

Puede configurar el puerto predeterminado 830 para conexiones NETCONF a través de SSH, como se especifica en RFC 4742, Uso del protocolo de configuración de NETCONF a través de Secure Shell (SSH), o configurar cualquier puerto del 1 al 65535.

Nota:

  • El puerto SSH predeterminado (22) sigue aceptando sesiones de NETCONF incluso con un puerto de servidor NETCONF configurado. Para deshabilitar el puerto SSH para que no acepte sesiones NETCONF, especifíquelo en el script de eventos de inicio de sesión.

  • No se recomienda configurar los puertos predeterminados para los servicios FTP (21) y Telnet (23) para configurar conexiones NETCONF-over-SSH.

Configurar límites de reintento de contraseña para acceso Telnet y SSH

Para evitar ataques de fuerza bruta y de diccionario, un dispositivo realiza las siguientes acciones para sesiones Telnet o SSH de forma predeterminada:

  • Desconecta una sesión después de un máximo de 10 reintentos consecutivos de contraseña.

  • Después del segundo reintento de contraseña, introduce un retraso en múltiplos de 5 segundos entre reintentos posteriores de contraseña.

    Por ejemplo, el dispositivo introduce un retraso de 5 segundos entre el tercer y cuarto reintento de contraseña, un retraso de 10 segundos entre el cuarto y quinto reintento de contraseña, y así sucesivamente.

  • Exige un tiempo de sesión mínimo de 20 segundos, durante el cual no se puede desconectar una sesión. La configuración del tiempo mínimo de sesión impide que usuarios malintencionados desconecten las sesiones antes de que entre en vigor el retraso del reintento de contraseña. La configuración del tiempo mínimo de sesión también les impide intentar ataques de fuerza bruta y de diccionario con múltiples inicios de sesión.

Puede configurar los límites de reintento de contraseña para el acceso Telnet y SSH. En este ejemplo, configurará el dispositivo para que realice las siguientes acciones para las sesiones Telnet y SSH:

  • Permita un máximo de cuatro reintentos consecutivos de contraseña antes de desconectar una sesión.

  • Introduzca un retraso en múltiplos de 5 segundos entre los reintentos de contraseña que se producen después del segundo reintento de contraseña.

  • Aplique un tiempo de sesión mínimo de 40 segundos, durante el cual no se puede desconectar una sesión.

Para configurar los límites de reintento de contraseña para el acceso Telnet y SSH:

  1. Establezca el número máximo de reintentos consecutivos de contraseña antes de desconectar una sesión Telnet, SSH o telnet. El número predeterminado es 10, pero puede definir un número desde 1 .10
  2. Establezca el número de umbral de reintentos de contraseña después de los cuales se introduce un retraso entre dos reintentos consecutivos de contraseña. El número predeterminado es 2, pero puede especificar un valor de 1 a .3
  3. Establezca el retraso (en segundos) entre reintentos consecutivos de contraseña después del número de umbral de reintentos de contraseña. El retraso predeterminado es en múltiplos de segundos, pero puede especificar un valor de a partir de 55 segundos 10 .
  4. Establezca el período mínimo de tiempo (en segundos) durante el cual no se puede desconectar una sesión Telnet o SSH. El valor predeterminado es 20 segundos, pero puede especificar un intervalo de 20 segundos 60 .
  5. Después de configurar el dispositivo, ingrese commit al modo de configuración.

Ejemplo: Configurar un filtro para bloquear el acceso Telnet y SSH

Requisitos

Necesita dos dispositivos que se ejecuten Junos OS con un vínculo de red compartido. No hay configuración especial más allá de la inicialización básica del dispositivo (interfaz de administración, acceso remoto, cuentas de inicio de sesión de usuario, etcetera). es necesario antes de configurar este ejemplo. Aunque no es un requisito estricto, se recomienda el acceso de la consola al dispositivo R2.

Nota:

Nuestro equipo de pruebas de contenido ha validado y actualizado este ejemplo.

Descripción general y topología

En este ejemplo, se crea un filtro de firewall sin estado IPv4 que registra y rechaza los paquetes Telnet o SSH enviados al motor de enrutamiento local, a menos que el paquete se origine en la subred 192.168.1.0/30 . El filtro se aplica a la interfaz de circuito cerrado para garantizar que solo se vea afectado el tráfico destinado al dispositivo local. El filtro se aplica en la dirección de entrada. No se utiliza un filtro de salida. Como resultado, se permite todo el tráfico generado localmente.

  • Para hacer coincidir paquetes que se originan en una subred o prefijo IP específico, utilice la source-address condición de coincidencia IPv4 aplicada en la dirección de entrada.

  • Para hacer coincidir los paquetes destinados al puerto Telnet y a los puertos SSH, utilice la condición de protocol tcp coincidencia combinada con condiciones de coincidencia a port telnet e port ssh IPv4 aplicadas en la dirección de entrada.

Ejemplo de topología

Figura 1 muestra la topología de prueba de este ejemplo. El filtro de firewall se aplica al dispositivo R2, convirtiéndolo en el dispositivo bajo prueba (DUT). Los dispositivos R1 y R2 comparten un vínculo que tiene asignada una subred de 192.168.1.0/30. Ambos dispositivos tienen direcciones de circuito cerrado asignadas desde el prefijo 192.168.255.0/30 mediante una máscara de subred /32. Las rutas estáticas proporcionan accesibilidad entre direcciones de circuito cerrado porque en este ejemplo básico no se configura un protocolo de puerta de enlace interior.

Figura 1: Ejemplo de topologíaEjemplo de topología

Configuración

En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.

Precaución:

Por diseño, el filtro de ejemplo restringe el acceso Telnet y SSH a R2 a menos que se origine en la subred compartida en R1. Si utiliza SSH o Telnet para acceder directamente al dispositivo R2, perderá conectividad cuando se aplique el filtro. Se recomienda tener acceso a la consola al configurar este ejemplo. Si es necesario, puede utilizar el dispositivo R1 como host de salto para iniciar una sesión SSH a R2 después de aplicar el filtro. Como alternativa, considere la posibilidad de modificar el filtro de ejemplo para permitir también la subred IP asignada a la máquina que utiliza para acceder al dispositivo R2.

Realice las siguientes tareas para configurar este ejemplo:

Configuración rápida de CLI

Configuración rápida para el dispositivo R1

Para configurar rápidamente el dispositivo R1, edite los siguientes comandos según sea necesario y péguelos en la CLI en el nivel de [edit] jerarquía. Asegúrese de emitir un commiten modo de configuración para activar los cambios.

Configuración rápida para el dispositivo R2

Para configurar rápidamente el dispositivo R2, edite los siguientes comandos según sea necesario y péguelos en la CLI en el nivel de [edit] jerarquía. Asegúrese de emitir un commit en modo de configuración para activar los cambios.

Consejo:

Considere usarlo commit-confirmed cuando realice cambios que puedan afectar el acceso remoto a su dispositivo. Activar una configuración de Junos OS pero requerir confirmación

Configurar el dispositivo R1

Procedimiento paso a paso

Siga estos pasos para configurar el dispositivo R1:

  1. Configure las interfaces:

  2. Configure el nombre de host y la ruta estática a la dirección de circuito cerrado del dispositivo R2. También puede configurar el acceso Telnet y SSH:

Verificar y confirmar la configuración en el dispositivo R1

Procedimiento paso a paso

Complete los siguientes pasos para verificar y confirmar su configuración candidata en el dispositivo R1:

  1. Confirme la configuración de la interfaz con el comando de show interfaces modo de configuración. Si el resultado del comando no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

  2. Compruebe la ruta estática utilizada para llegar a la dirección de circuito cerrado del dispositivo R2 y que el acceso SSH y Telnet estén habilitados. Utilice los comandos de show routing-options modo de configuración y show system services . Si el resultado del comando no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

  3. Cuando esté satisfecho con la configuración del dispositivo R1, confirme la configuración candidata.

Configurar el dispositivo R2

Procedimiento paso a paso

Complete los pasos siguientes para configurar el dispositivo R2. Para empezar, defina el filtro de firewall sin estado que bloquea selectivamente el acceso Telnet y SSH:

  1. Colóquese en la edit firewall family inet filter local_acl jerarquía:

  2. Defina el término terminal_accessde filtro . Este término permite Telnet y SSH desde los prefijos de origen especificados:

  3. Defina el término terminal_access_deniedde filtro . Este término rechaza SSH y Telnet de todas las demás direcciones de origen. Este término está configurado para registrar coincidencias con el término y generar una respuesta inaccesible de destino explícito del Protocolo de mensajes de control de Internet (ICMP) al origen del paquete. Consulte Acciones de registro de filtros de firewall para obtener más información sobre las opciones de registro de filtros.

    Consejo:

    Puede utilizar la acción para suprimir la discard generación de mensajes de error ICMP de vuelta al origen. Consulte Acciones de terminación del filtro de firewall para obtener más información.
  4. Opcional.

    Defina el término tcp-estabde filtro . Este término permite el acceso saliente a Internet para admitir conexiones a la nube de Juniper Mist (tcp-established es una condición de coincidencia de campo de bits, tcp-flags "(ack | rst)", que indica una sesión TCP establecida, pero no el primer paquete de una conexión TCP):

  5. Defina el término default-termde filtro . Este término acepta el resto del tráfico. Recuerde que Junos OS los filtros sin estado tienen un término de negación implícito en su extremo. El default-term anula este comportamiento al terminar el filtro con una acción de aceptación explícita. La finalización del filtro da como resultado que el archivador acepte el resto del tráfico.

    Nota:

    Para este ejemplo, estamos permitiendo todo el resto del tráfico, pero para su red es posible que desee proteger el motor de enrutamiento. Consulte Protección del motor de enrutamiento para obtener más información.

  6. Configure la interfaz de circuito cerrado y aplique el filtro en la dirección de entrada:

  7. Configure el nombre de host, la interfaz ge-0/0/0, la ruta estática a la dirección de circuito cerrado del dispositivo R1 y habilite el acceso remoto a través de SSH y Telnet:

Verificar y confirmar la configuración en el dispositivo R2

Procedimiento paso a paso

Complete los siguientes pasos para verificar y confirmar su configuración candidata en el dispositivo R2:

  1. Confirme la configuración del filtro de firewall sin estado con el comando de show firewall modo de configuración. Si el resultado del comando no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

  2. Confirme la configuración de la interfaz y filtre la aplicación con el comando de show interfaces modo de configuración. Si el resultado del comando no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

  3. Compruebe la ruta estática utilizada para llegar a la dirección de circuito cerrado del dispositivo R1 y compruebe que el acceso Telnet y SSH estén habilitados. Utilice los comandos de show routing-options modo de configuración y show system services . Si el resultado del comando no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

  4. Cuando esté satisfecho con la configuración en el dispositivo R2, confirme la configuración candidata.

    Consejo:

    Considere usarlo commit-confirmed cuando realice cambios que puedan afectar el acceso remoto a su dispositivo.

Comprobar el filtro de firewall sin estado

Confirme que el filtro de firewall para limitar el acceso Telnet y SSH funciona correctamente.

Verificar paquetes aceptados

Propósito

Compruebe que el filtro de firewall permite correctamente SSH y Telnet cuando el tráfico proviene de la subred 192.168.1.0/30 .

Acción

  1. Borre el registro del firewall en su enrutador o conmutador.

  2. Desde un host en una dirección IP dentro de la subred 192.168.1.0/30 , use un ssh 192.168.255.2 comando para comprobar que puede iniciar sesión en el dispositivo mediante SSH desde una dirección de origen permitida. Este paquete debe aceptarse, pero la información del encabezado del paquete para este paquete no debe registrarse en el búfer de registro del filtro de firewall en el motor de reenvío de paquetes. Se le pedirá que guarde la clave de host SSH si este es el primer inicio de sesión SSH entre user estos dispositivos.

    Nota:

    De forma predeterminada, el dispositivo R1 obtendrá el tráfico SSH de la interfaz de salida utilizada para llegar al destino. Como resultado, este tráfico proviene de la dirección 192.168.1.1 asignada a la interfaz ge-0/0/0 del dispositivo R1.

  3. Cierre sesión en la CLI en el dispositivo R2 para cerrar la sesión SSH.

  4. Desde un host en una dirección IP de la subred 192.168.1.0/30 , utilice el telnet 192.168.255.2 comando para comprobar que puede iniciar sesión en el enrutador o conmutador mediante Telnet desde una dirección de origen permitida. Este paquete debe aceptarse, pero la información del encabezado del paquete para este paquete no debe registrarse en el búfer de registro del filtro de firewall en el motor de reenvío de paquetes.

  5. Cierre sesión en la CLI para cerrar la sesión de Telnet en el dispositivo R2.

  6. Utilice el show firewall log comando para comprobar que el búfer de registro del firewall en el motor de reenvío de paquetes (PFE) del dispositivo R2 no contiene ninguna entrada con una dirección de origen en la subred 192.168.1.0/30 .

Verificar paquetes registrados y rechazados

Propósito

Compruebe que el filtro del firewall rechaza correctamente el tráfico SSH y Telnet que no se origina en la subred 192.168.1.0/30 .

Acción

  1. Borre el registro del firewall en su enrutador o conmutador.

  2. Genere tráfico SSH procedente de la dirección de circuito cerrado del dispositivo R1. La dirección de origen de este tráfico está fuera de la subred permitida 192.168.1.0/30 . Use el ssh 192.168.255.2 source 192.168.255.1 comando para comprobar que no puede iniciar sesión en el dispositivo con SSH desde esta dirección de origen. Este paquete debe rechazarse y la información del encabezado del paquete debe registrarse en el búfer de registro del filtro del firewall.

    El resultado muestra que se ha rechazado la conexión SSH. Este resultado confirma que el filtro está generando un mensaje de error ICMP y que bloquea correctamente el tráfico SSH cuando se envía desde una dirección de origen no permitida.

  3. Genere tráfico Telnet procedente de la dirección de circuito cerrado del dispositivo R1. La dirección de origen de este tráfico está fuera de la subred permitida 192.168.1.0/30 . Utilice el telnet 192.168.255.2 source 192.168.255.1 comando para comprobar que no puede iniciar sesión en el dispositivo mediante Telnet desde esta dirección de origen. Este paquete debe rechazarse y la información del encabezado del paquete para este paquete debe registrarse en el búfer de registro del filtro de firewall en el PFE.

    El resultado muestra que se rechaza la conexión Telnet. Este resultado confirma que el filtro está generando un mensaje de error ICMP y que bloquea correctamente el tráfico Telnet cuando se envía desde una dirección de origen no permitida.

  4. Utilice el show firewall log comando para comprobar que el búfer de registro del firewall en el dispositivo R2 contiene entradas que muestran que se rechazaron los paquetes con una dirección de origen 192.168.255.1.

    La salida confirma que el tráfico de la dirección de origen 192.168.255.1 coincidía con el término del terminal_access_denied filtro. La Action columna muestra un R para indicar que estos paquetes fueron rechazados. También se enumeran la interfaz, el protocolo de transporte y las direcciones de origen y destino. Estos resultados confirman que el filtro de firewall funciona correctamente para este ejemplo.

Temas relacionados

Tabla de historial de cambios

La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.

Liberación
Descripción
19.4R1
A partir de Junos OS versión 19.4R1 y Junos OS versión 17.4R3, puede deshabilitar la contraseña de inicio de sesión SSH o la autenticación desafío-respuesta mediante las no-password-authentication opciones y no-challenge-response en el nivel de jerarquía [edit system services ssh].
19.1R1
A partir de Junos OS versión 19.1R1, hemos deshabilitado globalmente las conexiones SFTP entrantes de forma predeterminada. Si lo desea, puede habilitar globalmente las conexiones SFTP entrantes configurando la instrucción sftp-server en el nivel de [edit system services ssh] jerarquía
18.3R1
A partir de la versión 18.3R1 de Junos OS, los ssh-dss algoritmos hostkey y ssh-dsa están en desuso (en lugar de eliminarse inmediatamente) para proporcionar compatibilidad con versiones anteriores y la oportunidad de que su configuración sea compatible con la nueva configuración.
18.3R1
(Solo series SRX y MX) A partir de Junos OS versión 19.3R1, puede especificar el nombre de la instancia de enrutamiento en la que se debe establecer la conectividad SSH saliente incluyendo la routing-instance instrucción en el nivel de [edit system services outbound-ssh] jerarquía: