Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Introducción al acceso remoto

Puede acceder a un enrutador, conmutador o dispositivo de seguridad de forma remota utilizando DHCP, Finger, FTP, rlogin, SSH, y servicios Telnet, etc. Este tema muestra cómo configurar el acceso remoto mediante telnet, SSH, FTP y servicios Finger. Lea este tema para obtener más información.

Introducción a servicios del sistema

Por razones de seguridad, el acceso remoto al enrutador está deshabilitado de forma predeterminada. Debe configurar el enrutador de forma explícita para que los usuarios de los sistemas remotos puedan tener acceso a él. Se puede tener acceso al enrutador desde un sistema remoto a través de los servicios DHCP, Finger, FTP, rlogin, SSH y Telnet. Además, Junos aplicaciones cliente de protocolo XML pueden utilizar la capa de sockets seguros (SSL) o el Junos servicio de texto simple específico del protocolo XML, entre otros servicios.

Nota:

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

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

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

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

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

  • connection-limit limit: número máximo de conexiones simultáneas por protocolo (IPV4 e IPv6). El intervalo va del 1 al 250. El valor predeterminado es 75. Cuando configura un límite de conexiones, 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 Telnet IPv6 y 10 sesiones Telnet IPv4.

  • rate-limit limit: cantidad máxima de intentos de conexión aceptados por minuto (del 1 al 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 los dispositivos que ejecutan el software Junos-FIPS. Recomendamos que no utilice Telnet en un entorno de criterios comunes.

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

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

De forma predeterminada, el enrutador o conmutador admite un número limitado de sesiones FTP simultáneas y de intentos de conexión por minuto. Puede incluir cualquiera de las siguientes instrucciones, o ambas, 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 del 1 al 250. El valor predeterminado es 75. Cuando configura un límite de conexiones, 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 de IPv6 y 10 sesiones FTP IPv4.

  • rate-limit limit: cantidad máxima de intentos de conexión aceptados por minuto (un valor del 1 al 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 FTP a una sesión.

Puede utilizar FTP pasivo para tener acceso a dispositivos que sólo aceptan servicios FTP pasivos. Todos los comandos e instrucciones que utilizan FTP también aceptan FTP pasivo. Incluya la ftp instrucción en el [edit system services] nivel jerárquico para utilizar FTP activo o FTP pasivo.

Para iniciar una sesión FTP pasiva, utilice pasvftp (en vez de ftp ) 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. Recomendamos que no utilice el servicio Finger en un entorno de criterios comunes.

Configuración del servicio Finger para el acceso remoto al enrutador

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

De forma predeterminada, el enrutador admite un número limitado de sesiones de Finger y de intentos de conexión simultáneos por minuto. Opcionalmente, puede incluir cualquiera de las siguientes instrucciones, o ambas, 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 del 1 al 250. El valor predeterminado es 75. Cuando configura un límite de conexiones, 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 las 10 sesiones de servicio de texto sin cifrado de IPv6 y 10 sesiones de servicio de texto sin cifrar de IPv4

  • rate-limit limit: cantidad máxima de intentos de conexión aceptados por minuto (un valor del 1 al 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 los enrutadores que ejecutan el software Junos-FIPS. Recomendamos que no utilice el servicio Finger en un entorno de criterios comunes.

Configuración del servicio SSH para el acceso remoto al enrutador o conmutador

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

De forma predeterminada, el enrutador o conmutador admite un número limitado de sesiones SSH simultáneas y de intentos de conexión por minuto. Utilice 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 del 1 al 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 de SSH de IPv6 y 10 sesiones de SSH de IPv4.

  • max-sessions-per-connection number: incluye esta instrucción para especificar la cantidad máxima de sesiones SSH permitidas por una sola conexión SSH. Esto le permite limitar el número de sesiones clonadas canalizadas en una sola conexión SSH. El valor predeterminado es 10.

  • rate-limit limit: cantidad máxima de intentos de conexión aceptados por minuto (un valor del 1 al 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 de SSH de IPv6 por minuto y 10 intentos de conexión de sesión de SSH de IPv4 por minuto.

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

  • time-limit— Límite de tiempo antes de volver a negociar 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 de respuesta a desafío mediante las opciones y en el nivel de jerarquía no-password-authenticationno-challenge-response [ edit system services ssh ].

De forma predeterminada, un usuario puede crear un túnel SSH a través de CLI sesión a un enrutador que se Junos OS mediante SSH. Este tipo de túnel podría utilizarse para reenviar el tráfico TCP, evitando los filtros de firewall o las listas de control de acceso que permitan tener acceso a recursos más allá del enrutador. Utilice la no-tcp-forwarding opción para evitar que un usuario cree un túnel SSH para un enrutador a través de SSH.

Para obtener más información sobre otras opciones de configuración, consulte los temas siguientes:

Configuración del inicio de sesión raíz a través de SSH

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

allow: permite a los usuarios iniciar sesión en el enrutador o conmutar como raíz mediante SSH.

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

deny- : permite a los usuarios iniciar sesión en el enrutador o conmutar como raíz a través de SSH cuando el método de autenticación password (por ejemplo, RSA) no requiere una contraseña.

El valor predeterminado deny-passwordes.

Configuración de conexiones ENTRANTES DESTP

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 transmisión de datos confiable. A partir Junos OS versión 19.1R1, hemos desactivado globalmente las conexiones DESTP entrantes de forma predeterminada. Si lo desea, puede habilitar globalmente las conexiones DESPC entrantes configurando la instrucción sftp-server en el [edit system services ssh] nivel jerárquico. Antes de Junos OS versión 19.1R1, las conexiones DESTP entrantes se habilitaban globalmente de forma predeterminada.

Nota:

De forma predeterminada, solo se desactivan las conexiones DESTP entrantes. Por ejemplo, dados los dispositivos A y B (en los que el dispositivo A se ejecuta 19.1R1), no puede conectarse a través de STP de B a A de forma predeterminada. Sin embargo, puede conectarse mediante ELSTP desde el dispositivo B al dispositivo A, si configura sftp-server en el dispositivo A.

Las conexiones DESTP entrantes se desactivan de forma predeterminada. Para habilitar las conexiones ENTRANTES DE STP:

  1. Configure la sftp-server instrucción en el nivel de [edit system services ssh] jerarquía:
  2. Confirme la configuración.

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

Configuración de 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 de tal que utilice la versión 2 del protocolo protocol-version SSH, incluya v2 la instrucción [edit system services ssh] y especifique en el nivel de jerarquía:

Los sistemas del modo FIPS siempre utilizan la versión v2del protocolo SSH.

Configuración del mecanismo del cliente activo

El mecanismo de cliente activo es muy útil cuando el cliente o el servidor dependen de si una conexión se ha vuelto inactiva. Difiere del mecanismo de KeepAlive estándar, ya que los mensajes del cliente activo se envían a través del canal cifrado. El mecanismo de cliente activo no está habilitado de forma predeterminada. Para habilitarla, configure client-alive-count-max las client-alive-interval instrucciones and. Esta opción solo se aplica a la versión 2 del protocolo SSH.

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

Configuración del algoritmo de hash de huellas dactilares de SSH

Para configurar el algoritmo hash que utiliza el servidor SSH cuando muestra huellas digitales fingerprint-hash , incluya la 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 los sistemas en el modo FIPS.

El comando telnet

Puede utilizar el comando de telnet CLI para abrir una sesión de Telnet con un dispositivo remoto:

Nota:

En SRX100, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345 y dispositivos de SRX1500, en la tabla siguiente se indica el número máximo de sesiones simultáneas de Telnet. La compatibilidad de la plataforma depende de la versión Junos OS de la 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 de comandos de quitla CLI, escriba.

Tabla 1describe las telnet opciones de comando.

Tabla 1: Opciones de comandos de Telnet de CLI

,

Descripción

8bit

Utilice una ruta de datos de 8 bits.

bypass-routing

Omita las tablas de enrutamiento y abra una sesión de Telnet únicamente para alojar 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 de Telnet con el nombre de host o dirección IP especificados.

inet

Forzar la sesión de Telnet a un destino IPv4.

interface source-interface

Abrir una sesión de Telnet en un host de 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 utilizar el comando de ssh CLI 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 siguiente tabla se indica el número máximo de sesiones SSH simultáneas. La compatibilidad de la plataforma depende de la versión Junos OS de la instalación.

SRX100

SRX210SRX220

SRX240

SRX300SRX320SRX340

SRX345

SRX1500

3

3

5

3

5

5

Tabla 2describe las ssh opciones de comando.

Tabla 2: Opciones de comando SSH de CLI

,

Descripción

bypass-routing

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

host

Abrir una conexión SSH en el nombre de host o dirección IP especificados.

inet

Forzar la conexión SSH a un destino IPv4.

interface source-interface

Abrir una conexión SSH a un host de 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

Obligue a SSH a usar la versión 1 para la conexión.

v2

Obligue a SSH a usar la versión 2 para la conexión.

Configuración de claves de host SSH para la copia segura de datos

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

  • Especifique los hosts conocidos de SSH mediante la inclusión de nombres de host e información de claves de host en la jerarquía de configuración del motor de enrutamiento.

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

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

  • Acepte la conexión segura. Si acepta esta conexión, la información de la clave de host se almacena automáticamente en la base de datos de claves del host local. La información de la clave de host almacenada en la jerarquía de configuración Automatiza el protocolo de enlace seguro y permite la transferencia de datos en segundo plano con SCP.

Tareas para configurar las claves de host SSH para la copia segura de datos son:

Configuración de hosts conocidos de SSH

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

Las claves de host son una de las siguientes:

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

  • ecdsa-sha2-nistp256-key clave: clave codificada ECDSA-SHA2-NIST256 de Base64.

  • ecdsa-sha2-nistp384-key clave: clave codificada ECDSA-SHA2-NIST384 de Base64.

  • ecdsa-sha2-nistp521-key clave: clave codificada ECDSA-SHA2-NIST521 de Base64.

  • ed25519-key clave: clave codificada ED25519 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 base64, el cual admite cifrado y firmas digitales para SSH versión 1.

A partir de Junos OS versión 18.3R1, los algoritmos hostkey y se desuso (en lugar de eliminarse de inmediato) para proporcionar compatibilidad con versiones anteriores y una oportunidad para que su configuración se cumpla con la nueva ssh-dssssh-dsa configuración.

Configuración de la compatibilidad con la transferencia de archivos SCP

Para configurar un host conocido para que admita transferencias de archivos SCP de archive-sites fondo, incluya [edit system archival configuration] la instrucción en el nivel jerárquico.

Nota:

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

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

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

Actualización de la información de clave de host SSH

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

Recuperar información de teclas del host manualmente

Para recuperar manualmente la información de la clave de host público fetch-from-server SSH, utilice set security ssh-known-hosts la opción con el comando. Debe incluir un atributo hostname con el set security ssh-known-hosts fetch-from-server comando para especificar el host desde el que recuperar la clave pública SSH.

Importación de la información de la clave de host desde un archivo

Para importar manualmente la información de la clave del host SSH desde el archivo hosts conocidos que se encuentra /var/tmp/known-hosts en load-key-file el servidor, set security ssh-known-hosts incluya la opción con el comando. Debe incluir la ruta de acceso al known-hosts archivo con el set security ssh-known-hosts load-key-file comando para especificar la ubicación desde la que se va a importar la información de teclas de host.

Configuración del servicio SSH para admitir la criptografía heredada

A partir de la versión 16.1 de Junos OS, el servidor SSH de Junos OS se basa en OpenSSH 7 y de forma predeterminada a un conjunto de cifrados y algoritmos de intercambio de claves más seguro. OpenSSH 7 omite alguna criptografía heredada.

Nota:

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

Nota:

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

La versión Junos OS 16,1 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 versión 16,1, los siguientes cifrados no se admiten de forma predeterminada, pero puede configurar el dispositivo para admitirlos. Se enumeran de la más segura a la menos segura:

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

  • 3des-cbc

  • blowfish-cbc

  • cast128-cbc

  • arcfour256

  • arcfour128

  • arcfour

Junos OS versión 16,1 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 versión 16,1, no se admiten de forma predeterminada los siguientes métodos de intercambio de claves, pero puede configurar el dispositivo para admitirlos:

  • 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 del servidor y del cliente. Los cambios en los valores predeterminados afectan al file copy comando cuando se utiliza el protocolo de copia segura (SCP).

  1. Agregar compatibilidad para ciphers con el set system services ssh ciphers [ cipher 1 cipher 2 ... ] comando. Recomendamos que agregue los cifrados al final de la lista de configuraciones para que se encuentren entre las últimas opciones utilizadas. En el siguiente ejemplo, el 3des-cbc cifrado and blowfish-cbc se agrega al conjunto predeterminado:
  2. Agregar compatibilidad para métodos de intercambio de claves mediante el set system services ssh key-exchange [ method 1 method 2 ... ] comando. Recomendamos que agregue los métodos de intercambio de claves al final de la lista de configuración para que se encuentren 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 la configuración:

Configurando el servicio de SSH saliente

Puede configurar un dispositivo que ejecute el Junos OS para iniciar una conexión TCP/IP con una aplicación de administración de clientes que sería bloqueada si el cliente intentara iniciar la conexión (por ejemplo, si el dispositivo está detrás de un firewall). El outbound-ssh comando indica al dispositivo que cree una conexión TCP/IP con la aplicación de administración de clientes y Reenvíe la identidad del dispositivo. Una vez establecida la conexión, la aplicación de administración actúa como cliente e inicia la secuencia SSH, y el dispositivo actúa como servidor y autentica al cliente.

Nota:

No hay ningún comando de inicio con SSH de salida. Una vez que el SSH saliente se configura y se confirma, 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 tenga éxito. Si se interrumpe la conexión entre el dispositivo y la aplicación de administración del cliente, el dispositivo intenta crear una nueva conexión SSH saliente hasta que tenga éxito. Esta conexión se mantiene hasta que la Stanza de SSH de salida se quite de la configuración.

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

[edit system services outbound-ssh]

En los siguientes temas se describen las tareas para configurar el servicio SSH de salida:

Configuración del identificador de dispositivo para las conexiones SSH salientes

Cada vez que el dispositivo establece una conexión SSH saliente, primero envía una secuencia de inicio al cliente de administración. Esta secuencia identifica el dispositivo en el cliente de administración. Dentro de esta transmisión es el valor device-idde.

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

Secuencia de inicio cuando secret no está configurado:

Envío de la clave pública del host SSH 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 en el 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 device-id la instrucción en [edit system services outbound-ssh client client-id] el nivel de jerarquía:

Secuencia de inicio cuando secret no está configurado:

Durante la inicialización de una conexión SSH, el cliente autentica la identidad del dispositivo con la clave pública SSH del host del dispositivo. Por lo tanto, antes de que el cliente pueda iniciar la secuencia SSH, necesita la clave SSH pública del dispositivo. Cuando configura la secret instrucción, el dispositivo pasa su clave ssh pública como parte de la secuencia de iniciación de conexión SSH de salida.

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

El uso secret de la 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:

La inclusión secret de la instrucción significa que el dispositivo envía su clave pública de host ssh cada vez que establece una conexión con el cliente. Por lo demás, corresponde al cliente decidir qué hacer con la clave de host SSH si ya tiene una para ese dispositivo. Le recomendamos que sustituya la copia del cliente por la nueva clave. Las teclas de host pueden cambiar por varias razones y reemplazar la clave cada vez que se establece una conexión, asegúrese de que el cliente dispone de 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:

Configuración de 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 y puede autenticar el dispositivo mediante su copia de la clave SSH de host público del enrutador o conmutador como parte de esa secuencia. El dispositivo autentica al usuario del cliente a través de los mecanismos admitidos en el Junos OS (autenticación RSA/DSA public string o password).

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

Configuración de una nueva conexión SSH saliente

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

También puede especificar el número de reintentos y establecer la cantidad de tiempo que transcurrir antes de que se detengan los intentos de reconexión. Consulte Configuración de mensajes keepalive para conexiones SSH salientesla.

Configuración del cliente SSH de salida para aceptar NETCONF como servicio disponible

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

Configuración de clientes SSH de salida

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

Nota:

Las conexiones SSH salientes admiten formatos de direcciones IPv4 e IPv6.

Configuración de instancias de enrutamiento para clientes SSH salientes

(Sólo serie SRX y serie MX) A partir de Junos OS versión 19.3 R1, se puede especificar el nombre de la instancia de ruta en la que es necesario establecer la conectividad SSH saliente, incluida routing-instance la instrucción en [edit system services outbound-ssh] el nivel de jerarquía:

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

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

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

Configurando conexiones NETCONF a través de SSH en un puerto TCP especificado

El Junos OS le permite restringir las conexiones NETCONF entrantes a un puerto TCP especificado sin tener que configurar un servidor de seguridad. Para configurar el puerto TCP usado para las conexiones de NETCONF a través de SSH, port incluya la instrucción [edit system services netconf ssh] en el nivel de jerarquía. El puerto configurado solo acepta sesiones NETCONF a través de SSH. Se rechazan las peticiones de sesión SSH normales para este puerto.

Puede configurar el puerto predeterminado 830 para conexiones NETCONF mediante SSH, como se especifica en la RFC 4742, mediante el protocolo de configuración NETCONF sobre shell seguro (SSH)o configurar cualquier puerto del 1 al 65535.

Nota:
  • El puerto SSH predeterminado (22) sigue aceptando sesiones NETCONF incluso con un puerto de servidor NETCONF configurado. Para desactivar el puerto SSH para que acepte sesiones NETCONF, especifique esto en la secuencia de comandos del suceso login.

  • No se recomienda configurar los puertos predeterminados para las conexiones FTP (21) y telnet (23) para la configuración de NETCONF a través de SSH.

Configuración de los límites de reintentos con contraseña para acceso a telnet y SSH

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

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

  • Tras reintentar la segunda contraseña, introduce un retardo en múltiplos de 5 segundos entre los reintentos posteriores de la contraseña.

    Por ejemplo, el dispositivo introduce un retraso de 5 segundos entre el tercero y la cuarta reintento de la contraseña, un retraso de 10 segundos entre el cuarto y quinto reintento de contraseña, etc.

  • Aplica un tiempo de sesión mínimo de 20 segundos durante el cual no puede desconectarse 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 de los reintentos por contraseña e intenten sufrir ataques de fuerza bruta y de diccionario con varios inicios de sesión.

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

  • Antes de desconectar una sesión, permita un máximo de cuatro reintentos de contraseñas consecutivos.

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

  • Exija un tiempo de sesión mínimo de 40 segundos durante el que no puede desconectarse una sesión.

Para configurar los límites de reintentos con contraseña para acceso a telnet y SSH:

  1. Establezca el número máximo de reintentos de contraseñas consecutivos antes de desconectar una sesión telnet o SSH o Telnet. El número predeterminado es 10, pero puede establecer un número de 1 a. 10
  2. Establezca el número límite de reintentos de contraseñas después de los cuales se introduce un retraso entre dos reintentos de contraseña consecutivos. El número predeterminado es 2, pero puede especificar un valor de 1 hasta. 3
  3. Establezca el retardo (en segundos) entre reintentos consecutivos de contraseñas tras el número límite de reintentos de contraseña. El retraso predeterminado es de múltiplos de 5 segundos, pero puede especificar un valor 5 a través 10 de segundos.
  4. Establezca el periodo mínimo de tiempo (en segundos) durante el que no se puede desconectar una sesión de telnet o SSH. El valor predeterminado 20 son los segundos, pero puede especificar un intervalo 20 desde 60 a los segundos.
  5. Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Ejemplo Configurar un filtro para bloquear Telnet y acceso SSH

Aplicables

Dos dispositivos que Junos OS con un vínculo de red compartido. Antes de configurar este ejemplo, no se requiere ninguna 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, etc.). Aunque no es un requisito estricto, se recomienda acceder a la consola del dispositivo R2.

Nota:

Nuestro equipo de pruebas de contenido validó y actualizó este ejemplo.

Descripción general y topología

En este ejemplo, se crea un filtro de firewall IPv4 sin estado 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/24. El filtro se aplica a la interfaz de circuito cerrado para asegurarse de que solo el tráfico destinado al dispositivo local se ve afectado. 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 originaron en una subred o prefijo IP específicos, utilice la condición de coincidencia source-address 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 coincidencia combinada con condiciones de coincidencia IPv4 y aplicadas en la dirección protocol tcpport telnet de port ssh entrada.

Topología de ejemplo

Figura 1 muestra la topología de prueba de este ejemplo. El filtro de firewall se aplica al dispositivo R2, lo que lo hace el dispositivo en pruebas (DUT). Los dispositivos R1 y R2 comparten un vínculo que se asigna una subred de 192.168.1.0/24. Ambos dispositivos tienen direcciones de circuito cerrado asignadas desde el prefijo 192.168.255.0/24 mediante una máscara de subred /32. Las rutas estáticas proporcionan alcanzabilidad entre las direcciones de circuito cerrado como un protocolo de puerta de enlace interior no está configurado en este ejemplo básico.

Figura 1: Topología de ejemploTopología de ejemplo

Automática

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre Cómo desplazarse por la CLI, consulte uso del editor de CLI en el modo de configuración.

PRECAUCIÓN:

Por diseño, el filtro de ejemplo restringe el acceso de 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 cuando configure este ejemplo. Si es necesario, puede usar el dispositivo R1 como host de salto para ejecutar una sesión SSH en R2 después de aplicar el filtro. Alternativamente, considere la posibilidad de modificar el filtro de ejemplo para permitir también la subred IP asignada a la máquina que utiliza para tener acceso 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 el CLI en el [edit] nivel de jerarquía. Asegúrese de emitir un commit modo de configuración from 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 el CLI nivel [edit] de jerarquía. Asegúrese de emitir un commit modo de configuración from para activar los cambios.

Consejo:

Considere la posibilidad commit-confirmed de usar cuando realice cambios que podrían afectar el acceso remoto a su dispositivo. Consulte Activación de una configuración Junos OS pero que requiere confirmación para obtener más informació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 se configuran telnet y acceso SSH:

Verificar y confirmar la configuración en el dispositivo R1

Procedimiento paso a paso

Siga los pasos a continuación para comprobar y confirmar la configuración de su candidato en el dispositivo R1:

  1. Confirme la configuración de la interfaz con el show interfaces comando del 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 que se usa para comunicarse con la dirección de circuito cerrado del dispositivo R2 y que el acceso a SSH y Telnet está habilitado. Utilice los show routing-options comandos y del modo de show system services 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. Cuando esté satisfecho con la configuración en el dispositivo R1, confirme la configuración de su candidato.

Configurar el dispositivo R2

Procedimiento paso a paso

Siga los pasos a continuación para configurar el dispositivo R2. Para comenzar, defina el filtro de firewall sin estado que bloquea de forma voluntaria telnet y acceso SSH:

  1. Posiciones en la edit firewall family inet filter jerarquía local_acl jerarquía:

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

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

    Consejo:

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

  4. Defina el término de filtro término predeterminado. Este término acepta el resto del tráfico. Recuerde que Junos OS filtros sin estado tienen un término de denegación implícito al final. El término predeterminado reemplaza este comportamiento terminando el filtro con una acción de aceptación explícita. Esto da como resultado que el filer acepte el resto del tráfico.

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

  6. 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

Siga los pasos a continuación para comprobar y confirmar la configuración de su candidato en el dispositivo R2:

  1. Confirme la configuración del filtro de firewall sin estado con el show firewall comando de 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 la aplicación de filtro con el show interfaces comando de 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 comunicarse con la dirección de circuito cerrado del dispositivo R1 y que el acceso a Telnet y SSH está habilitado. Utilice los show routing-options comandos y del modo de show system services configuración. 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 de su candidato.

    Consejo:

    Considere la posibilidad commit-confirmed de usar cuando realice cambios que podrían afectar el acceso remoto a su dispositivo. Consulte Activación de una configuración Junos OS pero que requiere confirmación para obtener más información.

Verificar el filtro de firewall sin estado

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

Verificar paquetes aceptados

Purpose

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

Intervenció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/24, utilice un comando para comprobar que puede iniciar sesión en el dispositivo mediante SSH desde una dirección de origen ssh 192.168.255.2 permitida. Este paquete se debe aceptar y la información del encabezado del paquete para este paquete no se debe registrar en el búfer de registro del filtro de firewall en la 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 como usuario entre estos dispositivos.

    Nota:

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

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

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

  5. Cierre sesión fuera de la CLI para cerrar la sesión de Telnet al dispositivo R2.

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

Verificar paquetes registrados y rechazadas

Purpose

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

Intervenció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/24. Utilice 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 se debe rechazar y la información del encabezado del paquete se debe registrar en el búfer de registro del filtro de firewall.

    El resultado muestra que se rechaza la conexión SSH. Esto 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 permitido.

  3. Genere el tráfico de 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/24. Utilice el telnet 192.168.255.2 source 192.168.255.1 comando para comprobar que no puede iniciar sesión en el dispositivo con Telnet desde esta dirección de origen. Este paquete debe ser rechazado, y la información de encabezado del paquete para este paquete debe registrarse en el búfer del registro del filtro de firewall, en el PFE.

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

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

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

Tabla de historial de versiones
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 de respuesta a desafío mediante las opciones y en el nivel de jerarquía no-password-authenticationno-challenge-response [ edit system services ssh ].
19.1R1
A partir Junos OS versión 19.1R1, hemos desactivado globalmente las conexiones DESTP entrantes de forma predeterminada. Si lo desea, puede habilitar globalmente las conexiones DESTP entrantes mediante la configuración de la instrucción sftp-server en el [edit system services ssh] nivel jerárquico
18.3R1
A partir de Junos OS versión 18.3R1, los algoritmos hostkey y se desuso (en lugar de eliminarse de inmediato) para proporcionar compatibilidad con versiones anteriores y una oportunidad para que su configuración se cumpla con la nueva ssh-dssssh-dsa configuración.