EN ESTA PÁGINA
Configurar el servicio Telnet para el acceso remoto a un enrutador o conmutador
Configurar el servicio FTP para el acceso remoto al enrutador o conmutador
Configurar el servicio Finger para el acceso remoto al enrutador
Configurar el servicio SSH para el acceso remoto al enrutador o conmutador
Configure las claves de host conocidas de SSH para la copia segura de datos
Configurar el servicio SSH para admitir criptografía heredada
Configurar conexiones NETCONF-over-SSH en un puerto TCP especificado
Descripción general del 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 los servicios de Telnet. En este tema, se muestra cómo configurar el acceso remoto mediante los servicios Telnet, SSH, FTP y Finger.
Descripción general de 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, dedo, FTP, rlogin, SSH y Telnet. Además, las aplicaciones cliente de protocolo JUnos XML pueden usar capa de sockets seguros (SSL) o el servicio de texto sin formato específico del protocolo XML de Junos, entre otros servicios.
Para proteger los recursos del sistema, puede limitar la cantidad de conexiones simultáneas que acepta un servicio y la cantidad de procesos propiedad de un solo usuario. Si se supera cualquiera de los límites, se produce 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 [edit system services]
nivel de jerarquía:
[edit system services] telnet { connection-limit limit; rate-limit limit; }
De forma predeterminada, el enrutador o conmutador admite un número limitado de sesiones e intentos de conexión simultáneos de Telnet por minuto.
De forma opcional, puede incluir una 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 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 IPv6 telnet y 10 sesiones IPv4 telnet. -
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 configure 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.
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 [edit system services]
nivel jerárquico:
[edit system services] ftp;
Puede usar FTP pasivo para acceder a dispositivos que solo acepten 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 de jerarquía para usar FTP activo o FTP pasivo.
Para iniciar una sesión FTP pasiva, use pasvftp
(en lugar de ftp
) en el formato FTP estándar (ftp://destination). Por ejemplo:
request system software add pasvftp://name.com/jinstall.tgz
Configurar el servicio Finger para el acceso remoto al enrutador
Para configurar el enrutador para que acepte el dedo como servicio de acceso, incluya la finger
instrucción en el [edit system services]
nivel jerárquico:
[edit system services] finger;
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 [edit system services]
nivel jerárquico:
[edit system services] ssh { authentication-order [method 1 method2...]; authorized-keys-command authorized-keys-command; authorized-keys-command-user authorized-keys-command-user; authorized-principals-file filename authorized-principals-command program-path ciphers [ cipher-1 cipher-2 cipher-3 ...]; client-alive-count-max number; client-alive-interval seconds; connection-limit limit; fingerprint-hash (md5 | sha2-256); host-certificate-file filename hostkey-algorithm (algorithm | no-algorithm); key-exchange [algorithm1 algorithm2...]; log-key-changes log-key-changes; macs [algorithm1 algorithm2...]; max-pre-authentication-packets number; max-sessions-per-connection number; no-challenge-response; no-password-authentication; no-passwords; no-public-keys; no-tcp-forwarding; port port-number; protocol-version [v2]; rate-limit number; rekey { data-limit bytes; time-limit minutes; } root-login (allow | deny | deny-password); sftp-server; tcp-forwarding; trusted-user-ca-key-file filename }
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 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 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 una sola conexión SSH. Esto le permite limitar la cantidad 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 (valor de 1 a 250). El valor predeterminado es 150. Cuando configure 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
—Plazo antes de la renegociación de 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 ejecuta Junos OS a través de SSH. Este tipo de túnel se puede utilizar para reenviar tráfico TCP, pasando por alto cualquier filtro de firewall o listas de control de acceso. Al pasar por alto 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 evitar que un usuario cree un túnel SSH a un enrutador mediante SSH.
Para obtener más información acerca de otras opciones de configuración, consulte los temas siguientes:
- Configure el inicio de sesión raíz a través de SSH
- Configurar conexiones SFTP entrantes
- Configurar la versión del protocolo SSH
- Configurar el mecanismo de vida del cliente
- Configurar el algoritmo hash de huellas digitales SSH
- Configurar la autenticación basada en certificados SSH
Configure 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 cambiar como root
mediante 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 [edit systems services ssh]
nivel jerárquico:
[edit system services ssh] root-login (allow | deny | deny-password);
allow
— Permite a los usuarios iniciar sesión en el enrutador o cambiar como raíz a través de SSH.
deny
: permite que los usuarios inicien sesión en el enrutador o cambien como raíz a través de SSH.
deny
-password
—Permite a los usuarios iniciar sesión en el enrutador o cambiar como raíz 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 sobre 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 mediante la configuración de la instrucción sftp-server
en el [edit system services ssh]
nivel de jerarquía.
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 del 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 conexiones SFTP entrantes:
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 usar 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:
[edit system services ssh] protocol-version [ v2 ];
Configurar el mecanismo de vida del cliente
El mecanismo activo del cliente es valioso cuando el cliente o el servidor dependen de saber cuándo una conexión se ha inactivo. Difiere del mecanismo estándar de guarda porque los mensajes vivos del cliente se envían a través del canal cifrado. El mecanismo de vida 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 siguiente ejemplo, los clientes SSH que no responden se desconectarán después de aproximadamente 100 segundos (20 x 5):
[edit system services ssh] client-alive-count-max 5; client-alive-interval 20;
Configurar el algoritmo hash de huellas digitales SSH
Para configurar el algoritmo hash utilizado por el servidor SSH cuando muestra las huellas digitales de la clave, incluya la fingerprint-hash
instrucción y especifique md5
o sha2-256
en el [edit system services ssh]
nivel de jerarquía:
[edit system services ssh] fingerprint-hash (md5 | sha2-256);
Configurar 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 configurar el acceso SSH a un dispositivo con inicio de sesión sin contraseña para los usuarios y ofrece la capacidad de confiar en los hosts sin la necesidad de verificar las huellas digitales de la clave.
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 elTrustedUserCAKey
archivo en /etc/ssh/sshd_config, que contiene las claves públicas de un certificado SSH. -
[system services ssh host-certificate-file filename]
— Configure elHostCertificate
archivo en /etc/ssh/sshd_config, que contiene el certificado de host firmado. -
[system services ssh authorized-principals-file filename]
— Configure elAuthorizedPrincipals
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 seguridad de certificado permitidas que se encuentran en elAuthorizedPrincipals
archivo.
El comando telnet
Puede usar el comando de cli telnet
para abrir una sesión Telnet en un dispositivo remoto:
user@host> telnet host <8bit> <inet> <inet6> <port port> <routing-instance routing-instance-name>
Para salir de la sesión telnet y volver al símbolo del sistema telnet, presione Ctrl-].
Para salir de la sesión telnet y volver al símbolo del sistema de cli, escriba quit
.
Opción |
Descripción |
---|---|
|
Utilice una ruta de datos de 8 bits. |
|
Abra una sesión Telnet en el nombre de host o dirección IP especificados. |
|
Forzar la sesión de Telnet a un destino IPv4. |
|
Fuerza la sesión de Telnet a un destino IPv6. |
|
Especifique el número de puerto o el nombre de servicio en el host. |
|
Utilice la instancia de enrutamiento especificada para la sesión de Telnet. |
El comando ssh
Puede usar el comando de CLI ssh
para usar el programa secure shell (SSH) para abrir una conexión a un dispositivo remoto:
user@host> ssh host <bypass-routing> <inet> <inet6> <interface interface-name> <logical-system> <routing-instance routing-instance-name> <source address> <v2>
En la tabla 2 se describen las opciones de ssh
comando.
Opción |
Descripción |
---|---|
|
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 directamente adjunta, se devuelve un mensaje de error. |
|
Abra una conexión SSH al nombre de host o dirección IP especificados. |
|
Forzar la conexión SSH a un destino IPv4. |
|
Forzar la conexión SSH a un destino IPv6. |
|
Abra una conexión SSH a un host en la interfaz especificada. Si no incluye esta opción, se usarán todas las interfaces. |
|
Utilice la instancia de enrutamiento especificada para la conexión SSH. |
|
Utilice el sistema lógico especificado para la conexión SSH. |
|
Utilice la dirección de origen especificada para la conexión SSH. |
|
Obligue a SSH a usar la versión 2 para la conexión. |
Configure las claves de host conocidas de SSH para la copia segura de datos
El Shell seguro (SSH) utiliza algoritmos de cifrado para generar un sistema de clave de host, servidor y sesión que garantiza una transferencia de datos segura. Puede configurar claves de host SSH para admitir la 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 de 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 del motor de enrutamiento.
-
Establezca una URL DE SCP para especificar el host desde el cual se recibirán 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. Almacenar información de clave de host en la jerarquía de configuración automatiza el apretón de manos seguro y permite la transferencia de datos en segundo plano mediante SCP.
Las tareas para configurar las claves de host SSH para la copia segura de datos son:
- Configurar hosts conocidos de SSH
- Configurar la compatibilidad para la transferencia de archivos SCP
- Actualizar la información de la clave de host SSH
Configurar hosts conocidos de SSH
Para configurar hosts conocidos ssh, incluya la instrucción y especifique las host
opciones de nombre de host y clave de host para servidores de confianza en el [edit security ssh-known-hosts]
nivel jerárquico:
[edit security ssh-known-hosts] host corporate-archive-server { dsa-key key; } host archive-server-url { rsa-key key; } host server-with-ssh-version-1 { rsa1-key key; }
Las claves de host son una de las siguientes:
-
dsa-key key
—Clave de algoritmo de firma digital (DSA) codificada 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 codificada 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 para 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 [edit system archival configuration]
nivel de jerarquía.
[edit system archival configuration] archive-sites { scp://username<:password>@host<:port>/url-path; }
Cuando especifique una URL en una instrucción Junos OS Evolved mediante una dirección de host IPv6, debe adjuntar la URL completa entre comillas (" ") y adjuntar la dirección de host IPv6 entre corchetes ([ ]). Por ejemplo, "scp://username<:password>@[host]<:port>/url-path";
Establecer la archive-sites
instrucción para que apunte a una URL SCP activa la recuperación automática de claves de host. En este punto, Junos OS Evolved se conecta al host SCP para buscar la clave pública SSH, muestra el resumen del mensaje de la clave de host o la huella digital como salida a la consola y termina la conexión con el servidor.
user@host# set system archival configuration archive-sites “<scp-url-path>” The authenticity of host <my-archive-server (<server-ip-address>)> can’t be established. RSA key fingerprint is <ascii-text key>. Are you sure you want to continue connecting (yes/no)?
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 digitales 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.
Actualizar la información de la clave de host SSH
Por lo general, la información de la clave de host SSH se recupera automáticamente cuando se establece un atributo URL para SCP mediante la archival configuration archive-sites
instrucción en el [edit system]
nivel de jerarquía. Sin embargo, si necesita actualizar manualmente la base de datos de claves de host, utilice uno de los métodos siguientes.
- Recuperar información de clave de host manualmente
- Importar información de clave de host desde un archivo
Recuperar información de clave de host manualmente
Para recuperar manualmente información de clave de host público SSH, configure la fetch-from-server
opción en el [edit security ssh-known-hosts]
nivel jerárquico. Debe especificar el host desde el que recuperar la clave pública SSH.
user@host# set security ssh-known-hosts fetch-from-server <hostname>
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 [edit security ssh-known-hosts]
nivel de jerarquía. Debe especificar la ruta al archivo desde el que importar información de clave de host.
user@host# set security ssh-known-hosts load-key-file /var/tmp/known-hosts
Configurar el servicio SSH para admitir criptografía heredada
El servidor SSH de Junos OS Evolved está basado en OpenSSH 7 y por defecto se basa en un conjunto más seguro de cifrados y algoritmos de intercambio de claves. OpenSSH 7 omite alguna criptografía heredada.
Consulte la documentación de OpenSSH 7 en https://www.openssh.com/ para obtener más información acerca de estas extensiones.
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 Junos OS Evolucionado, no se admiten los siguientes cifrados de forma predeterminada, pero puede configurar el dispositivo para que los admitan. Se enumeran desde los más seguros hasta los menos seguros:
-
aes256-cbc
-
aes192-cbc
-
aes128-cbc
-
blowfish-cbc
-
cast128-cbc
-
arcfour256
-
arcfour128
-
arcfour
Junos OS Evolved 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 Evolucionado, no se admiten los siguientes métodos de intercambio de claves de forma predeterminada, pero puede configurar el dispositivo para que los admitan:
-
group-exchange-sha1
-
dh-group1-sha1
Para configurar el servicio SSH para que admita la criptografía heredada:
Al configurar 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 file copy
comando cuando se utiliza Secure Copy Protocol (SCP).
Ver también
Configurar el servicio SSH saliente
Puede configurar un dispositivo que ejecuta 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, el dispositivo es un firewall. En estos casos, outbound-ssh
se puede configurar en el dispositivo Juniper Networks. Una outbound-ssh
configuración inicia una conexión SSH inversa del servidor al cliente a la aplicación de administración. Esta conexión SSH saliente solo se cierra después de quitar la configuración del dispositivo.
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 según la configuración confirmada. El dispositivo intenta crear esta conexión repetidamente hasta que se éxito. Si se pierde 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 produzca 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 [edit system services]
nivel jerárquico:
[edit system services outbound-ssh
]
En los siguientes temas se describen las tareas para configurar el servicio SSH saliente.
- Envíe la clave de host SSH pública al cliente SSH saliente
- Configurar mensajes keepalive para conexiones SSH salientes
- Configurar una nueva conexión SSH saliente
- Configure el cliente SSH saliente para aceptar NETCONF como servicio disponible
- Configurar clientes SSH salientes
- Configurar instancias de enrutamiento para clientes SSH salientes
Envíe 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 iniciación al cliente de administración. Esta secuencia identifica el enrutador o el cambio al cliente de administración. Dentro de esta transmisión se encuentra 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:
[edit system services outbound-ssh client client-id] device-id device-id;
La secuencia de iniciación cuando secret
no está configurada:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n
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 configure la secret
instrucción, el dispositivo pasa su clave SSH pública como parte de la secuencia de iniciación 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 es 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.
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, es el cliente el que decide qué hacer con la clave de host SSH si el cliente ya tiene una clave SSH para ese dispositivo. Recomendamos que reemplace la copia del cliente de la clave de host SSH por la nueva clave. Las claves de host pueden cambiar por varias razones. 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 [edit system services outbound-ssh client client-id]
nivel de jerarquía:
[edit system services outbound-ssh client client-id] secret password;
El dispositivo envía el siguiente mensaje cuando se configura el secret
atributo:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n HOST-KEY: <public-host-key>\r\n HMAC:<HMAC(pub-SSH-host-key, <secret>>)>\r\n
Configurar mensajes keepalive para conexiones SSH salientes
Después de que la aplicación cliente tenga la clave de host SSH pública del enrutador o del conmutador, puede iniciar la secuencia SSH como si hubiera creado la conexión TCP/IP. Luego, el cliente puede autenticar el dispositivo mediante su copia de la clave SSH de host público del enrutador o del conmutador como parte de esa secuencia. El dispositivo autentica al usuario cliente mediante los mecanismos admitidos en Junos OS Evolved (autenticación de contraseña o cadena pública RSA/DSA).
Para permitir que el dispositivo envíe mensajes de mantener el protocolo SSH a la aplicación cliente, configure la keep-alive
instrucción en el [edit system services outbound-ssh client client-id]
nivel jerárquico:
[edit system services outbound-ssh client client-id] keep-alive { retry number; timeout seconds; }
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 cae una conexión, incluya la reconnect-strategy
instrucción en el [edit system services outbound-ssh client client-id]
nivel jerárquico:
[edit system services outbound-ssh client-id] reconnect-strategy (sticky | in-order);
También puede especificar el número de intentos de reintentos y establecer la cantidad de tiempo antes de que se detengan los intentos de reconexión. Consulte Configurar mensajes keepalive para conexiones SSH salientes.
Configure el cliente SSH saliente para aceptar NETCONF como servicio disponible
Para configurar la aplicación para que acepte NETCONF como servicio disponible, incluya la services netconf
instrucción en el [edit system services outbound-ssh client client-id]
nivel jerárquico:
[edit system services outbound-ssh client client-id] services { netconf; }
Configurar clientes SSH salientes
Para configurar los clientes disponibles para esta conexión SSH saliente, enumre cada cliente con una instrucción de dirección independiente en el [edit system services outbound-ssh client client-id]
nivel jerárquico:
[edit system services outbound-ssh client client-id] address address { retry number; timeout seconds; port port-number; }
Las conexiones SSH salientes admiten formatos de direcciones IPv4 e IPv6.
Configurar instancias de enrutamiento para clientes SSH salientes
Para usar la instancia de enrutamiento de administración, primero habilite la instancia de mgmt_junos
enrutamiento mediante el set system management-instance
comando.
Para usar 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 mediante la tabla de enrutamiento predeterminada.
Configurar 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 utilizado para las conexiones NETCONF-over-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 regulares de sesión SSH para este puerto.
Puede configurar el puerto predeterminado 830 para conexiones NETCONF mediante SSH, como se especifica en RFC 4742, Mediante el protocolo de configuración de NETCONF mediante shell seguro (SSH) o configurar cualquier puerto del 1 al 65535.
-
El puerto SSH predeterminado (22) sigue aceptando sesiones NETCONF incluso con un puerto de servidor NETCONF configurado. Para deshabilitar que el puerto SSH acepte sesiones de NETCONF, especíquelo en la secuencia de comandos de evento de inicio de sesión.
-
No recomendamos configurar los puertos predeterminados para los servicios FTP (21) y Telnet (23) para configurar conexiones NETCONF-sobre-SSH.