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 da 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 do sistema

Por motivos de segurança, o acesso remoto ao roteador é desabilitado 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 clientes do protocolo Junos XML podem usar o Secure Sockets Layer (SSL) ou o serviço de texto não criptografado específico do protocolo Junos XML, entre outros serviços.

Observação:

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 pertencentes a um único usuário. Se um dos limites for excedido, as tentativas de conexão falharão.

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

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

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

Opcionalmente, você pode incluir uma ou ambas as instruçõ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). O intervalo é 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 telnet por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões telnet IPv6 e 10 sessões 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 telnet IPv6 por minuto e 10 tentativas de conexão de sessão telnet IPv4 por minuto.

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

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

Você pode usar o FTP passivo para acessar dispositivos que aceitam apenas serviços FTP passivos. Todos os comandos e instruções que usam FTP também aceitam FTP passivo. Inclua a ftp instrução no nível da [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:

Configurar o Finger Service para acesso remoto ao roteador

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

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

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

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

  • connection-limit limit— Número máximo de conexões simultâneas por protocolo (IPv4 e IPv6). O intervalo é 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 SSH por protocolo (IPv4 e IPv6). Por exemplo, um limite de conexão de 10 permite 10 sessões SSH IPv6 e 10 sessões SSH IPv4.

  • max-sessions-per-connection number— Inclua esta declaração para especificar o número máximo de sessões SSH permitidas por conexão SSH única. Isso permite limitar o número de sessões clonadas em túnel em uma única conexão SSH. O valor padrão é 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 as chaves de sessão (minutos)

Por padrão, um usuário pode criar um túnel SSH em uma sessão CLI para um roteador que executa o Junos OS via SSH. Esse tipo de túnel pode ser usado para encaminhar tráfego TCP, ignorando quaisquer filtros de firewall ou listas de controle de acesso. Ignorando 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 no-tcp-forwarding opção para impedir que um usuário crie um túnel SSH para um roteador via SSH.

A Juniper Networks fortalece os parâmetros de criptografia de campo finito (FFC) na criptografia de chave pública existente para reduzir o risco de computadores quânticos criptograficamente relevantes (CRQCs) usarem buffer quântico para o protocolo SSH. Essa abordagem de buffer quântico estende a janela de tempo e resiste a ataques criptoanalíticos reforçando os parâmetros FFC. Veja O buffer quântico.

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

Configurar o login root por meio de 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 requer uma senha. Para controlar o acesso do usuário por meio do SSH, inclua a root-login instrução no nível da [edit systems services ssh] hierarquia:

allow— Permite que os usuários façam login no roteador ou switch como root através de SSH.

deny— Desabilita os usuários de fazer login no roteador ou switch como root através de SSH.

deny—password Permite que os usuários efetuem login no roteador ou switch como root por SSH quando o método de autenticação (por exemplo, RSA) não exigir uma senha.

O padrão é deny-password.

Configurar conexões SFTP de entrada

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 desejar, você pode habilitar globalmente conexões SFTP de entrada configurando a declaração sftp-server no nível de [edit system services ssh] hierarquia.

Observação:

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

As conexões SFTP de entrada são desabilitadas por padrão. Para habilitar conexões SFTP de entrada:

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

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

Configurar a versão do protocolo SSH

Por padrão, somente 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:

Configurar o mecanismo Client Alive

O mecanismo de ativação do cliente é valioso quando o cliente ou servidor depende de saber quando uma conexão se tornou inativa. Ele difere do mecanismo de keepalive padrão porque as mensagens ativas do cliente são enviadas por meio do canal criptografado. O mecanismo de ativação do cliente não está habilitado por padrão. Para habilitá-lo, configure as client-alive-count-max instruções and client-alive-interval . Essa opção se aplica somente ao protocolo SSH versão 2.

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

Configurar o algoritmo de hash de impressão digital SSH

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

Visão geral da autenticação baseada em certificado SSH

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

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

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

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

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

Gerando chaves de assinatura

As chaves de assinatura são chaves criptográficas especializadas usadas na autenticação baseada em certificado SSH. A primeira etapa para configurar a autenticação baseada em certificado SSH é gerar chaves de assinatura. Você pode gerar chaves de assinatura em qualquer sistema Linux/FreeBSD. Siga estas 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 chamada <filename_ca> e uma chave pública correspondente chamada <filename_ca.pub>.

  2. Faça login em seu dispositivo Juniper e configure o arquivo de chave da autoridade de certificação de usuário confiável (CA) SSH executando o comando: e, set system services ssh trusted-user-ca-key-file <path-to-public-key> em seguida, confirme 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 para o computador que tem os certificados <filename_ca> de usuário e <filename_ca.pub>o .

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

Configuração

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

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

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

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

  • [system services ssh authorized-principals-command program-path]— Especifique um programa a ser usado para gerar a lista de entidades de certificado permitidas encontradas no AuthorizedPrincipals arquivo.

Desativando o SSH

Se você ativou o SSH e deseja desativá-lo, basta remover a ssh instrução do nível de [edit system services] hierarquia.

Se você quiser desabilitar apenas o SSH externo, use a access-disable-external instrução no nível da [edit system services ssh] hierarquia.

Quando o SSH está habilitado por padrão, você não pode desabilitá-lo por meio da [edit system services] hierarquia normalmente. Em vez disso, você pode configurar um filtro de firewall para negar o acesso SSH:

Procedimento passo a passo

Siga estas etapas para configurar um filtro de firewall para negar acesso SSH:

  1. Defina o termo 1do filtro . Este termo nega o tráfego TCP do SSH:

  2. Defina o termo 2do filtro . Esse termo permite que qualquer tráfego que não seja negado pelo termo 1de filtro:

Para obter mais informações sobre como usar filtros de firewall para desabilitar o SSH, consulte Exemplo: configurar um filtro para bloquear o acesso Telnet e SSH.

O comando telnet

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

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

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

Tabela 1: Opções de comando CLI telnet

Opção

Descrição

8bit

Use um caminho de dados de 8 bits.

host

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

inet

Force a sessão Telnet para um destino IPv4.

inet6

Force a sessão Telnet para um destino IPv6.

port port

Especifique o número da 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 Telnet.

O comando ssh

Você pode usar o comando CLI ssh para usar o programa Secure Shell (SSH) para abrir uma conexão com um dispositivo remoto:

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

Tabela 2: Opções do comando CLI ssh

Opção

Descrição

bypass-routing

Ignore as tabelas de roteamento e abra uma conexão SSH apenas com hosts em interfaces conectadas diretamente. Se o host não estiver em uma interface conectada diretamente, uma mensagem de erro será retornada.

host

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

inet

Force a conexão SSH para um destino IPv4.

inet6

Force a conexão SSH com um destino IPv6.

interface source-interface

Abra uma conexão SSH com 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.

Configurar chaves de host conhecidas SSH para cópia segura de dados

O Secure Shell (SSH) usa algoritmos de criptografia para gerar um sistema de host, servidor e chave de sessão que garante a transferência segura de dados. Você pode configurar chaves de host SSH para suportar 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 SSH para SCP, você deve concluir as seguintes tarefas:

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

  • Defina uma URL SCP para especificar o host do qual os dados serão recebidos. A configuração desse atributo recupera automaticamente as informações da chave do host SSH do servidor SCP.

  • Verifique se a chave de host é autêntica.

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

As tarefas para configurar chaves de host SSH para cópia segura de dados são:

Configurar hosts conhecidos SSH

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

As chaves de host são uma das seguintes:

  • dsa-key key— Chave de algoritmo de assinatura digital (DSA) codificada em Base64 para SSH versão 2.

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

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

  • ecdsa-sha2-nistp521-keykey— Chave de NIST521 ECDSA-SHA2-codificada em Base64.

  • ed25519-keykey— Chave ED25519 codificada em Base64.

  • rsa-key key— Algoritmo de chave pública codificado em 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 em Base64, que oferece suporte a criptografia e assinaturas digitais para SSH versão 1.

Configurar suporte para transferência de arquivos SCP

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

Observação:

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

Definir a archive-sites instruçã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 o resumo da mensagem da chave do host ou impressão digital como saída para o console e encerra a conexão com o servidor.

Para verificar se a chave do host é autêntica, compare essa impressão digital com uma impressão digital obtida do mesmo host usando uma fonte confiável. Se as impressões digitais forem idênticas, aceite a chave do host digitando yes no prompt. As informações da chave do host são armazenadas na configuração do Mecanismo de Roteamento e oferecem suporte a transferências de dados em segundo plano usando SCP.

Atualizar informações da chave do host SSH

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

Recuperar informações da chave do host manualmente

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

Importar informações de chave de host de um arquivo

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

Configurar o serviço SSH para oferecer suporte à criptografia legada

Você pode configurar o Junos OS Evolved para oferecer suporte a cifras de criptografia legadas e métodos de troca de chaves.

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 você pode configurar seu dispositivo para oferecer suporte a elas. Eles são listados do mais seguro para o menos seguro:

  • 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 chaves não são suportados por padrão, mas você pode configurar seu dispositivo para suportá-los:

  • group-exchange-sha1

  • dh-group1-sha1

Para configurar o serviço SSH para oferecer suporte à criptografia herdada:

Observação:

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

  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 arcfour cifras e blowfish-cbc são adicionadas ao conjunto padrão:
  2. Adicione suporte para 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 final 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. Confirme a configuração:

Veja também

Configurar 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, se o dispositivo for 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 para o cliente e para o aplicativo de gerenciamento. Essa conexão SSH de saída é fechada somente depois que a configuração é removida do dispositivo.

Observação:

Não há comando de iniciação com SSH de saída. Depois de configurar e confirmar o SSH de saída, o dispositivo começa a iniciar uma conexão SSH de saída com base na configuração confirmada. O dispositivo tenta criar essa conexão repetidamente até ser bem-sucedido. Se a conexão entre o dispositivo e o aplicativo de gerenciamento do cliente for descartada, o dispositivo tentará novamente criar uma nova conexão SSH de saída até ser bem-sucedida. Essa conexão é mantida até que a sub-rotina 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 da [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 ao cliente de gerenciamento. Essa sequência identifica o roteador ou switch para o cliente de gerenciamento. Dentro desta transmissão está o valor de device-id.

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

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

Usar a secret instruçã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.

Observação:

Incluir a secret instrução significa que o dispositivo envia sua 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 de host podem mudar por vários motivos. Ao substituir a chave sempre que uma conexão é 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 nível da [edit system services outbound-ssh client client-id] hierarquia:

A seguinte mensagem é enviada pelo dispositivo quando o secret atributo é configurado:

Configurar 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 poderá iniciar a sequência 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 do host público do roteador ou switch como parte dessa sequência. O dispositivo autentica o usuário cliente por meio dos mecanismos suportados no Junos OS Evolved (string pública RSA/DSA ou autenticação de senha).

Para permitir que o dispositivo envie mensagens keepalive do protocolo SSH para o aplicativo cliente, configure a keep-alive declaração no nível da [edit system services outbound-ssh client client-id] hierarquia:

Configurar 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 depois que uma conexão é descartada, inclua a reconnect-strategy instrução no nível da [edit system services outbound-ssh client client-id] hierarquia:

Você também pode especificar o número de tentativas de repetição e definir a quantidade de tempo antes que as tentativas de reconexão sejam interrompidas. Consulte Configurar mensagens keepalive para conexões SSH de saída.

Configure o cliente SSH de saída para aceitar 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 da [edit system services outbound-ssh client client-id] hierarquia:

Configurar 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 da [edit system services outbound-ssh client client-id] hierarquia:

Observação:

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

Configurar 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, primeiro configure a [edit routing-instances] instância de roteamento na 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.

Configurar conexões NETCONF-over-SSH em uma porta TCP especificada

O Junos OS Evolved permite restringir 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 da [edit system services netconf ssh] hierarquia. A porta configurada aceita apenas sessões NETCONF-over-SSH. As solicitações regulares de sessão SSH para esta porta são rejeitadas.

Você pode configurar a porta padrão 830 para conexões NETCONF sobre 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.

Observação:

  • A porta SSH padrão (22) continua a aceitar sessões NETCONF mesmo com uma porta de servidor NETCONF configurada. Para desabilitar a porta SSH de aceitar sessões NETCONF, especifique isso no script de evento 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