Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Descripción general del acceso remoto

Usted (el administrador de la 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 explica cómo configurar el acceso remoto mediante Telnet, SSH, FTP y los servicios Finger.

Descripción general de los servicios del sistema

Por motivos 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 mediante los servicios DHCP, finger, FTP, rlogin, SSH y Telnet. Además, las aplicaciones cliente del protocolo XML de Junos pueden usar Secure Sockets Layer (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 que posee un solo usuario. Si se supera cualquiera de los límites, se producirá un error en los intentos de conexión.

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 jerárquico [edit system services] :

De forma predeterminada, el enrutador o conmutador admite un número limitado de sesiones Telnet simultáneas 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 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 de 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: 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 frecuencia, 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.

Configure 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:

Puede usar 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 usar 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:

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:

Configure 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 jerárquico [edit system services] :

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 rango 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 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 única. 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 del 1 al 250). El valor predeterminado es 150. Cuando se configura un límite de frecuencia, 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)

De forma predeterminada, un usuario puede crear un túnel SSH a través de una sesión de 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 cualquier filtro de firewall o lista de control de acceso. Al omitir los filtros del 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.

Juniper Networks fortalece los parámetros de criptografía de campo finito (FFC) en la criptografía de clave pública existente para reducir el riesgo de que las computadoras cuánticas criptográficamente relevantes (CRQC) usen Quantum Buffer para el protocolo SSH. Este enfoque de búfer cuántico extiende la ventana de tiempo y resiste los ataques criptoanalíticos al reforzar los parámetros de FFC. Consulte El búfer cuántico.

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

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 mediante SSH.

deny: deshabilita a los usuarios para que no 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 raíz mediante 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. Las conexiones SFTP entrantes están deshabilitadas 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.

Nota:

Solo las conexiones SFTP entrantes están deshabilitadas de forma predeterminada. Por ejemplo, dados los dispositivos A y B, 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 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 de [edit system services ssh] jerarquía:
  2. Confirmar la configuración.

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

Configure 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 nivel jerárquico [edit system services ssh] :

Configurar el mecanismo de activación del cliente

El mecanismo de activación del cliente es valioso cuando el cliente o el servidor dependen de saber cuándo una conexión se ha vuelto inactiva. Difiere del mecanismo estándar de keepalive porque los mensajes de cliente vivo se envían a través del canal cifrado. El mecanismo de activación del cliente 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 al protocolo SSH versión 2.

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

Configure el algoritmo hash de huellas dactilares SSH

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

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 función le permite establecer acceso SSH sin contraseña para usuarios y hosts de confianza sin verificar las huellas digitales de clave.

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 una contraseña para adivinar o descifrar.

  • Los certificados SSH simplifican la administración de claves de autenticación. En lugar de administrar claves individuales para cada usuario y host, los administradores pueden emitir y revocar certificados de 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 <filename_ca> y una clave pública correspondiente denominada <filename_ca.pub>.

  2. Inicie sesión en su dispositivo Juniper y configure el archivo de clave de la autoridad de certificación de usuario de confianza (AC) SSH mediante la ejecución del comando: y, luego, set system services ssh trusted-user-ca-key-file <path-to-public-key> confirme la configuración.

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

  4. Copie la clave pública creada por el usuario en la máquina que tiene los certificados <filename_ca> de usuario y <filename_ca.pub>.

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

Configuración

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

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

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

  • [system services ssh authorized-principals-file filename]: configure el AuthorizedPrincipals archivo, que contiene una lista de nombres, uno de los cuales debe aparecer en el certificado para que se acepte 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 de jerarquía.

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

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 desde SSH:

  2. Defina el término 2de filtro . Este término permite cualquier tráfico que no se deniegue mediante el término 1de filtro:

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

El comando telnet

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

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 la CLI

Opción

Descripción

8bit

Utilice una ruta de datos de 8 bits.

host

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

inet

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

inet6

Forzar la sesión Telnet a un destino IPv6.

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.

El comando ssh

Puede utilizar el comando de la CLI ssh para utilizar el programa Secure Shell (SSH) para abrir una conexión con un dispositivo remoto:

En la tabla 2 se describen las opciones de ssh comando.

Tabla 2: Opciones de comando ssh de la CLI

Opción

Descripción

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 con el nombre de host o la dirección IP especificados.

inet

Forzar la conexión SSH a un destino IPv4.

inet6

Forzar la conexión SSH a un destino IPv6.

interface source-interface

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

routing-instance routing-instance-name

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

logical-system

Utilice el sistema lógico especificado para la conexión SSH.

source address

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

v2

Forzar SSH para usar la versión 2 para la conexión.

Configure claves de host conocidas SSH para una copia segura de datos

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

  • Especifique los hosts conocidos SSH incluyendo 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 del que desea recibir los 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. Al aceptar esta conexión, se almacena automáticamente la información de la clave de host en la base de datos de claves de host local. Al almacenar la información de la clave del host en la jerarquía de configuración, se automatiza el protocolo de apretón de manos seguro y se 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 de 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 (DSA) codificada en Base64 para SSH versión 2.

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

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

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

  • ed25519-keykey—Clave ED25519 codificada en Base64.

  • rsa-key key—Algoritmo de clave pública codificado en 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:

Cuando especifique una URL en una instrucción de Junos OS Evolved con una dirección de host IPv6, debe poner la URL completa entre comillas (" ") y poner la dirección de host IPv6 entre paréntesis ([ ]). Por ejemplo, "scp://username<:password>@[host]<:port>/url-path";

Establecer la archive-sites instrucción para que apunte a una URL de SCP activa la recuperación automática de la clave de host. En este punto, Junos OS evolucionado se conecta al host SCP para obtener la clave pública SSH, muestra el resumen del mensaje de 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 un origen de confianza. Si las huellas dactilares son idénticas, acepte la clave de host ingresando yes en el indicador. La información de la clave del host se almacena en la configuración del motor de enrutamiento y admite transferencias de datos en segundo plano mediante SCP.

Actualización de 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 de 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 siguientes métodos.

Recuperar manualmente la información de la clave del host

Para recuperar manualmente la información de la clave de host pública SSH, configure la fetch-from-server opción en el nivel jerárquico [edit security ssh-known-hosts] . Debe especificar el host desde el 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 archivo known_hosts , incluya la load-key-file opción en el nivel de [edit security ssh-known-hosts] jerarquía. Debe especificar la ruta al archivo desde el que importar la información de la clave de host.

Configure el servicio SSH para que admita criptografía heredada

Puede configurar Junos OS Evolved para que admita cifrados de criptografía y métodos de intercambio de claves heredados.

Junos OS evolucionado 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 el Junos OS evolucionado, los siguientes cifrados no se admiten de forma predeterminada, pero puede configurar el dispositivo para que sean compatibles. Se enumeran de la más segura a la menos segura:

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

Junos OS evolucionado 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 el Junos OS evolucionado, los siguientes métodos de intercambio de claves no se admiten de forma predeterminada, pero puede configurar el dispositivo para que sean compatibles:

  • group-exchange-sha1

  • dh-group1-sha1

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

Nota:

Mediante la configuración de un conjunto ordenado de cifras, 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 de cliente. Los cambios en los valores predeterminados afectan al file copy comando cuando se utiliza el Protocolo de copia segura (SCP).

  1. Agregar 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. Agregar compatibilidad con 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 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 la configuración:

Ver también

Configurar el servicio de SSH de salida

Puede configurar un dispositivo que ejecute Junos OS evolucionado para iniciar una conexión TCP/IP con una aplicación de administración de cliente. Si la aplicación de administración no llega a un dispositivo de Juniper Networks, por ejemplo, si 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 solo se cierra 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 el SSH de salida, el dispositivo comienza a iniciar una conexión SSH de salida basada en la configuración confirmada. El dispositivo intenta repetidamente crear esta conexión hasta que se realiza correctamente. Si se interrumpe la conexión entre el dispositivo y la aplicación de administración del cliente, el dispositivo vuelve a intentar crear una nueva conexión SSH saliente hasta que se realice correctamente. Esta conexión se mantiene hasta que se elimina la estrofa SSH de salida 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 de salida.

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

Cada vez que el enrutador o conmutador establece una conexión SSH de salida, primero envía una secuencia de iniciación 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 jerárquico:

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. Cuando se configura la secret instrucción, el dispositivo pasa su clave SSH pública como parte de la secuencia de inicio de la 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 está recibiendo 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. Luego, 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 por 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 conecte 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 de keepalive para conexiones SSH salientes

Después de que la aplicación cliente tenga 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 Evolved (RSA/DSA, cadena pública o autenticación de contraseña).

Para permitir que el dispositivo envíe mensajes keepalive del 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 de salida

Cuando se desconecta, el dispositivo comienza a iniciar una nueva conexión SSH de salida. Para especificar cómo se vuelve a conectar el dispositivo al servidor después de interrumpir 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 reintentos y establecer la cantidad de tiempo antes de que se detengan los intentos de reconexión. Consulte Configurar mensajes de keepalive para conexiones SSH salientes.

Configure 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:

Configuración de 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 formatos de dirección IPv4 e IPv6.

Configuración de instancias de enrutamiento para clientes SSH salientes

Para utilizar la instancia de enrutamiento de administración, primero habilite la mgmt_junos instancia de enrutamiento mediante 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 de salida mediante la tabla de enrutamiento predeterminada.

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

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

Puede configurar el puerto predeterminado 830 para las conexiones NETCONF a través de SSH, como se especifica en RFC 4742, Uso del protocolo de configuración 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 NETCONF incluso con un puerto de servidor NETCONF configurado. Para deshabilitar el puerto SSH para que no acepte sesiones NETCONF, especifique esto en el script del evento de inicio de sesión.

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

Documentación relacionada