Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Visão geral do acesso remoto

Você (o administrador de rede) pode acessar um roteador, switch ou dispositivo de segurança remotamente usando serviços como DHCP, Finger, FTP, rlogin, SSH e serviços Telnet. Este tópico mostra como configurar o acesso remoto usando os serviços Telnet, SSH, FTP e Finger.

Visão geral dos serviços de sistema

Por motivos de segurança, o acesso remoto ao roteador é desativado por padrão. Você deve configurar o roteador explicitamente para que os usuários em sistemas remotos possam acessá-lo. Os usuários podem acessar o roteador a partir de um sistema remoto por meio dos serviços DHCP, finger, FTP, rlogin, SSH e Telnet. Além disso, os aplicativos de cliente de protocolo Junos XML podem usar o Secure Sockets Layer (SSL) ou o serviço de texto claro específico para protocolo Junos XML, entre outros serviços.

Nota:

Para proteger os recursos do sistema, você pode limitar o número de conexões simultâneas que um serviço aceita e o número de processos de propriedade de um único usuário. Se qualquer limite for excedido, as tentativas de conexão falharão.

Configure o serviço Telnet para acesso remoto a um roteador ou switch

Para configurar o roteador ou switch para aceitar a Telnet como um serviço de acesso, inclua a telnet declaração no nível de [edit system services] hierarquia:

Por padrão, o roteador ou switch oferece suporte a um número limitado de sessões de Telnet simultâneas e tentativas de conexão por minuto.

Opcionalmente, você pode incluir as duas declarações a seguir para alterar os padrões:

  • connection-limit limit— Número máximo de conexões simultâneas por protocolo (IPV4 e IPv6). A faixa é de 1 a 250. O padrão é 75. Quando você configura um limite de conexão, o limite é aplicável ao número de sessões de telnet por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões de telnet IPv6 e 10 sessões de telnet IPv4.

  • rate-limit limit— Número máximo de tentativas de conexão aceitas por minuto (de 1 a 250). O padrão é 150. Quando você configura um limite de taxa, o limite é aplicável ao número de tentativas de conexão por protocolo (IPv4 e IPv6). Por exemplo, um limite de taxa de 10 permite 10 tentativas de conexão de sessão de telnet IPv6 por minuto e 10 tentativas de conexão de sessão de telnet IPv4 por minuto.

Configure o serviço FTP para acesso remoto ao roteador ou switch

Para configurar o dispositivo para aceitar o FTP como um serviço de acesso, inclua a ftp declaração no [edit system services] nível de hierarquia:

Você pode usar FTP passivo para acessar dispositivos que aceitam apenas serviços FTP passivos. Todos os comandos e declarações que usam FTP também aceitam FTP passivo. Inclua a ftp declaração no nível de [edit system services] hierarquia para usar FTP ativo ou FTP passivo.

Para iniciar uma sessão de FTP passiva, use pasvftp (em vez de ftp ) no formato FTP padrão (ftp://destination). Por exemplo:

Configure o serviço Finger para acesso remoto ao roteador

Para configurar o roteador para aceitar o dedo como um serviço de acesso, inclua a finger declaração no [edit system services] nível de hierarquia:

Configure o serviço SSH para acesso remoto ao roteador ou switch

Para configurar o roteador ou switch para aceitar o SSH como um serviço de acesso, inclua a ssh declaração no nível de [edit system services] hierarquia:

Por padrão, o roteador ou switch oferece suporte a um número limitado de sessões de SSH simultâneas e tentativas de conexão por minuto. Use as seguintes declarações para alterar os padrões:

  • connection-limit limit— Número máximo de conexões simultâneas por protocolo (IPv4 e IPv6). A faixa é um valor de 1 a 250. O padrão é 75. Quando você configura um limite de conexão, o limite é aplicável ao número de sessões de SSH por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões de SSH IPv6 e 10 sessões de SSH IPv4.

  • max-sessions-per-connection number— Inclua esta declaração para especificar o número máximo de sessões de SSH permitidas por uma única conexão SSH. Isso permite limitar o número de sessões clonadas em tunelamento em uma única conexão SSH. O valor padrão é de 10.

  • rate-limit limit— Número máximo de tentativas de conexão aceitas por minuto (um valor de 1 a 250). O padrão é 150. Quando você configura um limite de taxa, o limite é aplicável ao número de tentativas de conexão por protocolo (IPv4 e IPv6). Por exemplo, um limite de taxa de 10 permite 10 tentativas de conexão de sessão SSH IPv6 por minuto e 10 tentativas de conexão de sessão SSH IPv4 por minuto.

  • data-limit— Limite de dados antes de renegociar chaves de sessão (bytes)

  • time-limit— Limite de tempo antes de renegociar chaves de sessão (minutos)

Por padrão, um usuário pode criar um túnel SSH em uma sessão de CLI para um roteador que executa o Junos OS via SSH. Esse tipo de túnel pode ser usado para encaminhar o tráfego TCP, ignorando quaisquer filtros de firewall ou listas de controle de acesso. Ao ignorar filtros de firewall ou listas de controle de acesso, esse tipo de túnel permite o acesso a recursos além do roteador. Use a opção no-tcp-forwarding para impedir que um usuário crie um túnel SSH para um roteador via SSH.

Para obter informações sobre outras configurações de configuração, veja os seguintes tópicos:

Configure o login raiz através do SSH

Por padrão, os usuários podem fazer login no roteador ou switch como root por SSH quando o método de autenticação não exigir uma senha. Para controlar o acesso do usuário através do SSH, inclua a root-login declaração no nível de [edit systems services ssh] hierarquia:

allow— permite que os usuários façam login no roteador ou switch como raiz através do SSH.

deny— Desativa os usuários de fazer login no roteador ou switch como raiz através do SSH.

deny-password— permite que os usuários façam login no roteador ou switch como raiz através do SSH quando o método de autenticação (por exemplo, RSA) não requer uma senha.

O padrão é deny-password.

Configure as próximas conexões SFTP

O SSH File Transfer Protocol (SFTP) é um protocolo de rede que fornece acesso a arquivos, transferência de arquivos e gerenciamento de arquivos em qualquer fluxo de dados confiável. As conexões SFTP de entrada são desabilitadas por padrão. Se desejado, você pode habilitar globalmente as próximas conexões SFTP configurando a declaração sftp-server no nível hierárquica [edit system services ssh] .

Nota:

Apenas as conexões SFTP de entrada são desabilitadas por padrão. Por exemplo, dado os dispositivos A e B, você não pode se conectar através do SFTP de B a A por padrão. No entanto, você pode se conectar através do SFTP do dispositivo B ao dispositivo A se você configurar sftp-server no dispositivo A.

As conexões SFTP de entrada são desativadas por padrão. Para permitir conexões SFTP de entrada:

  1. Configure a sftp-server declaração no nível de [edit system services ssh] hierarquia:
  2. Confirmar a configuração.

    A sftp-server declaração agora está ativa. Portanto, as conexões SFTP de entrada estão habilitadas.

Configure a versão do protocolo SSH

Por padrão, apenas a versão 2 do protocolo SSH está habilitada.

Para configurar o roteador ou switch para usar a versão 2 do protocolo SSH, inclua a protocol-version declaração e especifique v2 no nível de [edit system services ssh] hierarquia:

Configure o mecanismo Client Alive

O mecanismo de vida do cliente é valioso quando o cliente ou servidor depende de saber quando uma conexão se tornou inativa. Ela difere do mecanismo keepalive padrão porque as mensagens vivas do cliente são enviadas pelo canal criptografado. O mecanismo de vida do cliente não é habilitado por padrão. Para habilitá-la, configure as declarações e client-alive-interval as client-alive-count-max declarações. Essa opção se aplica apenas ao protocolo SSH versão 2.

No exemplo a seguir, os clientes SSH sem resposta serão desconectados após aproximadamente 100 segundos (20 x 5):

Configure o algoritmo de hash de impressão digital SSH

Para configurar o algoritmo de hash usado pelo servidor SSH quando ele exibe as principais impressões digitais, inclua a fingerprint-hash declaração e especifique md5 ou sha2-256 no nível de [edit system services ssh] hierarquia:

Visão geral da autenticação baseada em certificadoSH

A partir do Junos OS e junos OS Evolved Release 22.4R1, você pode configurar a autenticação baseada em certificadoS SSH para usuários e hosts. Esse recurso permite estabelecer acesso SSH sem senha para usuários e hosts de confiança sem verificar as principais impressões digitais.

Benefícios da autenticação baseada em certificados SSH

  • A autenticação baseada em certificadoSH elimina a necessidade de os usuários lembrarem e inserirem senhas, agilizando o processo de login.

  • Em comparação com as abordagens tradicionais baseadas em senha, os certificados SSH oferecem uma segurança mais forte. Eles são mais difíceis de violar sem senha para adivinhar ou quebrar.

  • Os certificados SSH simplificam o gerenciamento das chaves de autenticação. Em vez de gerenciar as chaves individuais para cada usuário e host, os administradores podem emitir e revogar certificados de uma autoridade de certificado centralizada.

Gerando chaves de assinatura

As chaves de assinatura são chaves criptográficas especializadas usadas na autenticação baseada em certificados SSH. O primeiro passo para configurar a autenticação baseada em certificados SSH é gerar chaves de assinatura. Você pode gerar chaves de assinatura em qualquer sistema Linux/FreeBSD. Siga essas etapas para gerar chaves de assinatura para autenticação baseada em certificado SSH:

  1. Execute o comando: ssh-keygen -f <filename_ca>. Isso criará uma chave privada nomeada <filename_ca> e uma chave pública correspondente nomeada <filename_ca.pub>.

  2. Faça login no seu dispositivo da Juniper e configure o arquivo chave de autoridade de certificado de usuário confiável (CA) da SSH executando o comando: set system services ssh trusted-user-ca-key-file <path-to-public-key> e então comprometa a configuração.

  3. Cada usuário pode gerar suas próprias chaves de usuário usando o seguinte comando CLI: ssh-keygen -t <rsa|ecdsa|ed25519>.

  4. Copie a chave pública criada pelo usuário na máquina que tem os certificados <filename_ca> de usuário e <filename_ca.pub>.

  5. Assine a chave pública do usuário no <filename_ca.pub> arquivo.

Configuração

Para configurar a autenticação baseada em certificado SSH, use as seguintes declarações de configuração de CLI:

  • [system services ssh trusted-user-ca-key-file filename]— Configure o TrustedUserCAKey arquivo em /etc/ssh/sshd_config, que contém as chaves públicas de um certificado SSH.

  • [system services ssh host-certificate-file filename]— Configure o HostCertificate arquivo em /etc/ssh/sshd_config, que contém o certificado de host assinado.

  • [system services ssh authorized-principals-file filename]— Configure o AuthorizedPrincipals arquivo em /var/etc, que contém uma lista de nomes, um dos quais deve aparecer no certificado para que ele seja aceito para autenticação.

  • [system services ssh authorized-principals-command program-path]— Especifique um programa a ser usado para gerar a lista de diretores de certificados permitidos encontrados no AuthorizedPrincipals arquivo.

O comando telnet

Você pode usar o comando CLI telnet para abrir uma sessão de Telnet a um dispositivo remoto:

Para sair da sessão da Telnet e retornar ao prompt de comando telnet, pressione Ctrl-].

Para sair da sessão da Telnet e retornar ao prompt de comando CLI, entre quit.

Tabela 1: Opções de comando de telnet CLI

Opção

Descrição

8bit

Use um caminho de dados de 8 bits.

host

Abra uma sessão da Telnet para o nome de host ou endereço IP especificado.

inet

Force a sessão da Telnet a um destino IPv4.

inet6

Force a sessão da Telnet a um destino IPv6.

port port

Especifique o número de porta ou o nome do serviço no host.

routing-instance routing-instance-name

Use a instância de roteamento especificada para a sessão da Telnet.

O comando ssh

Você pode usar o comando CLI ssh para usar o programa secure shell (SSH) para abrir uma conexão a um dispositivo remoto:

A Tabela 2 descreve as ssh opções de comando.

Tabela 2: Opções de comando ssh de CLI

Opção

Descrição

bypass-routing

Contorne as tabelas de roteamento e abra uma conexão SSH apenas para hosts em interfaces diretamente anexadas. Se o host não estiver em uma interface diretamente anexada, uma mensagem de erro será devolvida.

host

Abra uma conexão SSH com o nome de host ou endereço IP especificado.

inet

Force a conexão SSH a um destino IPv4.

inet6

Force a conexão SSH a um destino IPv6.

interface source-interface

Abra uma conexão SSH a um host na interface especificada. Se você não incluir essa opção, todas as interfaces serão usadas.

routing-instance routing-instance-name

Use a instância de roteamento especificada para a conexão SSH.

logical-system

Use o sistema lógico especificado para a conexão SSH.

source address

Use o endereço de origem especificado para a conexão SSH.

v2

Force o SSH a usar a versão 2 para a conexão.

Configure as chaves de host conhecidas do SSH para uma cópia segura dos dados

O Secure Shell (SSH) usa algoritmos de criptografia para gerar um sistema de host, servidor e chave de sessão que garante uma transferência segura de dados. Você pode configurar as chaves de host SSH para oferecer suporte a cópia segura (SCP) como uma alternativa ao FTP para a transferência de dados em segundo plano, como arquivos de configuração e logs de eventos. Para configurar o suporte de SSH para SCP, você deve concluir as seguintes tarefas:

  • Especifique hosts conhecidos do SSH, incluindo nomes de host e informações chave do host na hierarquia de configuração do Mecanismo de Roteamento.

  • Configure uma URL SCP para especificar o host a partir do qual receber dados. Definir esse atributo recupera automaticamente as informações chave do host SSH do servidor SCP.

  • Verifique se a chave do host é autentica.

  • Aceite a conexão segura. Aceitar essa conexão armazena automaticamente as principais informações de host no banco de dados da chave do host local. Armazenar informações chave do host na hierarquia de configuração automatiza o uso seguro e permite a transferência de dados em segundo plano usando SCP.

As tarefas para configurar as chaves do host SSH para uma cópia segura dos dados são:

Configure hosts conhecidos de SSH

Para configurar hosts conhecidos de SSH, inclua a host declaração e especifique opções de nome de host e host para servidores confiáveis no nível de [edit security ssh-known-hosts] hierarquia:

As chaves do host são uma das seguintes:

  • dsa-key key— Algoritmo de assinatura digital codificado (DSA) base64 para SSH versão 2.

  • ecdsa-sha2-nistp256-keykey— Chave ECDSA-SHA2-NIST256 codificada para Base64.

  • ecdsa-sha2-nistp384-keykey— Chave de NIST384 ECDSA-SHA2 codificada para a Base64.

  • ecdsa-sha2-nistp521-keykey— Chave ECDSA-SHA2-NIST521 codificada para base64.

  • ed25519-keykey— Chave de ED25519 codificada base64.

  • rsa-key key— Algoritmo de chave pública codificado base64 que oferece suporte a criptografia e assinaturas digitais para SSH versão 1 e SSH versão 2.

  • rsa1-key key— Algoritmo de chave pública RSA codificado pela Base64, que oferece suporte a criptografia e assinaturas digitais para SSH versão 1.

Configure o suporte para transferência de arquivos SCP

Para configurar um host conhecido para oferecer suporte a transferências de arquivos SCP de fundo, inclua a archive-sites declaração no nível de [edit system archival configuration] hierarquia.

Nota:

Ao especificar uma URL em uma declaração Evolved do Junos OS usando um endereço de host IPv6, você deve incluir toda a URL entre aspas (" ") e colocar o endereço de host IPv6 em parênteses ([]). Por exemplo, "scp://username<:password>@[host]<:port>/url-path";

Definir a archive-sites declaração para apontar para uma URL SCP aciona a recuperação automática da chave do host. Neste ponto, o Junos OS Evolved se conecta ao host SCP para buscar a chave pública SSH, exibe a mensagem chave do host ou a impressão digital como saída para o console e encerra a conexão com o servidor.

Para verificar se a chave do host é autentica, compare esta impressão digital com uma impressão digital que você obtém do mesmo host usando uma fonte confiável. Se as impressões digitais forem idênticas, aceite a chave do host entrando yes no prompt. As informações chave do host são então armazenadas na configuração do Mecanismo de Roteamento e suportam transferências de dados em segundo plano usando SCP.

Atualizar as informações principais do host SSH

Normalmente, as informações chave do host SSH são recuperadas automaticamente quando você define um atributo de URL para SCP usando a archival configuration archive-sites declaração no nível de [edit system] hierarquia. No entanto, se você precisar atualizar manualmente o banco de dados da chave do host, use um dos seguintes métodos.

Recuperar as informações da chave do host manualmente

Para recuperar manualmente as informações de chave do host público SSH, configure a opção fetch-from-server no nível de [edit security ssh-known-hosts] hierarquia. Você deve especificar o host a partir do qual recuperar a chave pública SSH.

Importar informações chave do host de um arquivo

Para importar manualmente as informações chave do host SSH de um arquivo known_hosts , inclua a opção load-key-file no nível de [edit security ssh-known-hosts] hierarquia. Você deve especificar o caminho até o arquivo a partir do qual importar informações chave do host.

Configure o serviço SSH para oferecer suporte a criptografia legado

O servidor SSH no Junos OS Evolved é baseado no OpenSSH 7 e padrões para um conjunto mais seguro de cifras e algoritmos de troca de chaves. O OpenSSH 7 omite algumas criptografias legadas.

Nota:

Consulte a documentação do OpenSSH 7 em https://www.openssh.com/ para obter mais informações sobre essas extensões.

O Junos OS Evolved oferece suporte ao seguinte conjunto de cifras por padrão:

  • chacha20-poly1305@openssh.com

  • aes128-ctr

  • aes192-ctr

  • aes256-ctr

  • aes128-gcm@openssh.com

  • aes256-gcm@openssh.com

No Junos OS Evolved, as seguintes cifras não são suportadas por padrão, mas podem configurar seu dispositivo para dar suporte a eles. Eles estão listados dos mais seguros aos menos seguros:

  • aes256-cbc

  • aes192-cbc

  • aes128-cbc

O Junos OS Evolved oferece suporte ao seguinte conjunto de métodos de troca de chaves por padrão:

  • curve25519-sha256

  • ecdh-sha2-nistp256

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp521

  • group-exchange-sha2

  • dh-group14-sha1

No Junos OS Evolved, os seguintes métodos de troca de chave não são suportados por padrão, mas podem configurar seu dispositivo para dar suporte a eles:

  • group-exchange-sha1

  • dh-group1-sha1

Para configurar o serviço SSH para oferecer suporte a criptografia legadas:

Nota:

Ao configurar um conjunto ordenado de cifras, métodos de troca de chaves ou códigos de autenticação de mensagens (MACs), o conjunto recém-definido é aplicado a comandos de servidor e cliente. Alterações nos padrões afetam o file copy comando quando você usa o Secure Copy Protocol (SCP).

  1. Adicione suporte para cifras usando o set system services ssh ciphers [ cipher 1 cipher 2 ... ] comando. Recomendamos que você adicione as cifras ao final da lista de configuração para que elas estejam entre as últimas opções usadas. No exemplo a seguir, as cifras e blowfish-cbc as arcfour cifras são adicionadas ao conjunto padrão:
  2. Adicione suporte aos métodos de troca de chaves usando o set system services ssh key-exchange [ method 1 method 2 ... ] comando. Recomendamos que você adicione os métodos de troca de chaves ao fim da lista de configuração para que eles estejam entre as últimas opções usadas. No exemplo a seguir, o dh-group1-sha1 método de troca de chaves é adicionado ao conjunto padrão:
  3. Confirmar a configuração:

Veja também

Configure o serviço SSH de saída

Você pode configurar um dispositivo que executa o Junos OS Evolved para iniciar uma conexão TCP/IP com um aplicativo de gerenciamento de clientes. Se o aplicativo de gerenciamento não alcançar um dispositivo da Juniper Networks, por exemplo, o dispositivo será um firewall. Nesses casos, outbound-ssh pode ser configurado no dispositivo da Juniper Networks. Uma outbound-ssh configuração inicia uma conexão SSH reversa do servidor ao cliente até o aplicativo de gerenciamento. Essa conexão SSH de saída só é fechada após a configuração ser removida do dispositivo.

Nota:

Não há comando de iniciação com SSH de saída. Depois de configurar e confirmar SSH de saída, o dispositivo começa a iniciar uma conexão SSH de saída com base na configuração comprometida. O dispositivo tenta repetidamente criar essa conexão até ser bem sucedido. Se a conexão entre o dispositivo e o aplicativo de gerenciamento do cliente for perdida, o dispositivo novamente tenta criar uma nova conexão SSH de saída até ser bem-sucedido. Essa conexão é mantida até que a estrofe SSH de saída seja removida da configuração.

Para configurar o dispositivo para conexões SSH de saída, inclua a outbound-ssh declaração no nível de [edit system services] hierarquia:

[edit system services outbound-ssh]

Os tópicos a seguir descrevem as tarefas para configurar o serviço SSH de saída.

Envie a chave de host SSH pública para o cliente SSH de saída

Cada vez que o roteador ou switch estabelece uma conexão SSH de saída, ele primeiro envia uma sequência de iniciação para o cliente de gerenciamento. Essa sequência identifica o roteador ou o switch para o cliente de gerenciamento. Nesta transmissão há o valor de device-id.

Para configurar o identificador de dispositivo do roteador ou switch, inclua a device-id declaração no [edit system services outbound-ssh client client-id] nível hierárquico:

A sequência de iniciação quando secret não está configurada:

Durante a inicialização de uma conexão SSH, o cliente autentica a identidade do dispositivo usando a chave de host SSH pública do dispositivo. Portanto, antes que o cliente possa iniciar a sequência de SSH, o cliente precisa da chave SSH pública do dispositivo. Ao configurar a secret declaração, o dispositivo passa sua chave SSH pública como parte da sequência de iniciação da conexão SSH de saída.

Quando a secret declaração é definida e o dispositivo estabelece uma conexão SSH de saída, o dispositivo comunica seu ID de dispositivo, sua chave SSH pública e um hash SHA1 derivado em parte da secret declaração. O valor da secret declaração é compartilhado entre o dispositivo e o cliente de gerenciamento. O cliente usa o segredo compartilhado para autenticar a chave pública do host SSH que está recebendo para determinar se a chave pública é do dispositivo identificado pela device-id declaração.

Usar a secret declaração para transportar a chave de host SSH pública é opcional. Você pode transportar e instalar manualmente a chave pública no sistema do cliente.

Nota:

Incluir a secret declaração significa que o dispositivo envia a chave de host SSH pública toda vez que estabelece uma conexão com o cliente. Cabe então ao cliente decidir o que fazer com a chave de host SSH se o cliente já tiver uma chave SSH para esse dispositivo. Recomendamos que você substitua a cópia do cliente da chave de host SSH pela nova chave. As chaves do host podem mudar por vários motivos. Substituindo a chave cada vez que uma conexão for estabelecida, você garante que o cliente tenha a chave mais recente.

Para enviar a chave de host SSH pública do roteador ou switch quando o dispositivo se conectar ao cliente, inclua a secret declaração no [edit system services outbound-ssh client client-id] nível hierárquico:

A mensagem a seguir é enviada pelo dispositivo quando o secret atributo está configurado:

Configure mensagens keepalive para conexões SSH de saída

Depois que o aplicativo cliente tiver a chave de host SSH pública do roteador ou switch, ele pode iniciar a sequência de SSH como se tivesse criado a conexão TCP/IP. O cliente pode então autenticar o dispositivo usando sua cópia da chave SSH de host público do roteador ou switch como parte dessa sequência. O dispositivo autentica o usuário cliente através dos mecanismos suportados no Junos OS Evolved (autenticação pública de string ou senha RSA/DSA).

Para permitir que o dispositivo envie mensagens keepalives de protocolo SSH ao aplicativo do cliente, configure a keep-alive declaração no [edit system services outbound-ssh client client-id] nível hierárquica:

Configure uma nova conexão SSH de saída

Quando desconectado, o dispositivo começa a iniciar uma nova conexão SSH de saída. Para especificar como o dispositivo se reconecta ao servidor após a queda de uma conexão, inclua a reconnect-strategy declaração no nível de [edit system services outbound-ssh client client-id] hierarquia:

Você também pode especificar o número de tentativas de tentativas de nova tentativa e definir a quantidade de tempo antes que as tentativas de reconexão parem. Veja configurar mensagens keepalive para conexões SSH de saída.

Configure o cliente SSH de saída para aceitar o NETCONF como um serviço disponível

Para configurar o aplicativo para aceitar o NETCONF como um serviço disponível, inclua a services netconf declaração no nível de [edit system services outbound-ssh client client-id] hierarquia:

Configure clientes SSH de saída

Para configurar os clientes disponíveis para essa conexão SSH de saída, liste cada cliente com uma declaração de endereço separada no nível de [edit system services outbound-ssh client client-id] hierarquia:

Nota:

As conexões SSH de saída oferecem suporte a formatos de endereço IPv4 e IPv6.

Configure instâncias de roteamento para clientes SSH de saída

Para usar a instância de roteamento de gerenciamento, primeiro habilite a mgmt_junos instância de roteamento usando o set system management-instance comando.

Para usar qualquer outra instância de roteamento, configure primeiro a instância de roteamento na [edit routing-instances] hierarquia.

Se você não especificar uma instância de roteamento, seu dispositivo estabelecerá a conexão SSH de saída usando a tabela de roteamento padrão.

Configure conexões NETCONF-Over-SSH em uma porta TCP especificada

O Junos OS Evolved permite que você restrinja as conexões NETCONF de entrada a uma porta TCP especificada sem configurar um firewall. Para configurar a porta TCP usada para conexões NETCONF-over-SSH, inclua a port declaração no nível de [edit system services netconf ssh] hierarquia. A porta configurada aceita apenas sessões NETCONF-over-SSH. As solicitações regulares de sessão de SSH para esta porta são indeferidas.

Você pode configurar a porta padrão 830 para conexões NETCONF em SSH, conforme especificado no RFC 4742, usando o protocolo de configuração NETCONF sobre Secure Shell (SSH)ou configurar qualquer porta de 1 a 65535.

Nota:

  • A porta SSH padrão (22) continua a aceitar sessões de NETCONF mesmo com uma porta de servidor NETCONF configurada. Para desabilitar a porta SSH de aceitar sessões netconf, especifique isso no script de eventos de login.

  • Não recomendamos configurar as portas padrão para serviços FTP (21) e Telnet (23) para configurar conexões NETCONF-over-SSH.

Documentação relacionada