NESTA PÁGINA
Configure o serviço Telnet para acesso remoto a um roteador ou switch
Configure o serviço FTP para acesso remoto ao roteador ou switch
Configure o serviço SSH para acesso remoto ao roteador ou switch
Configure as chaves de host conhecidas do SSH para uma cópia segura dos dados
Configure o serviço SSH para dar suporte à criptografia legado
Configure conexões NETCONF-Over-SSH em uma porta TCP especificada
Visão geral do acesso remoto
Você (o administrador de rede) pode acessar remotamente um roteador, switch ou dispositivo de segurança 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 do protocolo Junos XML, entre outros serviços.
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:
[edit system services] telnet { connection-limit limit; rate-limit limit; }
Por padrão, o roteador ou switch oferece suporte a um número limitado de sessões simultâneas de Telnet 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 telnet IPv6 por minuto e 10 tentativas de conexão de sessão 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 nível de [edit system services]
hierarquia:
[edit system services] ftp;
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 ftp passiva, use pasvftp
(em vez de ftp
) no formato FTP padrão (ftp://destination). Por exemplo:
request system software add pasvftp://name.com/jinstall.tgz
Configure o finger service 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 nível de [edit system services]
hierarquia:
[edit system services] finger;
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:
[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 }
Por padrão, o roteador ou switch oferece suporte a um número limitado de sessões simultâneas de SSH 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 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 é 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 contornar 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 por meio do SSH
- Configure as próximas conexões SFTP
- Configure a versão do protocolo SSH
- Configure o mecanismo do cliente vivo
- Configure o algoritmo de hash de impressões digitais SSH
- Configure a autenticação baseada em certificadoSH
Configure o login raiz por meio do SSH
Por padrão, os usuários podem fazer login no roteador ou switch como root
por meio do SSH quando o método de autenticação não exigir uma senha. Para controlar o acesso do usuário por meio de SSH, inclua a root-login
declaração no nível de [edit systems services ssh]
hierarquia:
[edit system services ssh] root-login (allow | deny | deny-password);
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 da [edit system services ssh]
hierarquia.
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 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:
Configure a versão do protocolo SSH
Configure o mecanismo do cliente vivo
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 de 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á-lo, 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):
[edit system services ssh] client-alive-count-max 5; client-alive-interval 20;
Configure o algoritmo de hash de impressões digitais SSH
Para configurar o algoritmo de hash usado pelo servidor SSH quando exibir impressões digitais principais, incluir a fingerprint-hash
declaração e especificar md5
ou sha2-256
no nível de [edit system services ssh]
hierarquia:
[edit system services ssh] fingerprint-hash (md5 | sha2-256);
Configure a autenticação baseada em certificadoSH
A partir do Junos OS e do Junos OS Evolved Release 22.4R1, você pode configurar a autenticação baseada em certificados SSH para usuários e hosts. Esse recurso permite configurar o acesso SSH a um dispositivo com login sem senha para usuários e oferece a capacidade de confiar em hosts sem a necessidade de verificar as principais impressões digitais.
Para configurar a autenticação baseada em certificadoSH, use as seguintes declarações de configuração de CLI:
-
[system services ssh trusted-user-ca-key-file filename]
— Configure oTrustedUserCAKey
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 oHostCertificate
arquivo em /etc/ssh/sshd_config, que contém o certificado de host assinado. -
[system services ssh authorized-principals-file filename]
— Configure oAuthorizedPrincipals
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 noAuthorizedPrincipals
arquivo.
O comando telnet
Você pode usar o comando CLI telnet
para abrir uma sessão telnet a um dispositivo remoto:
user@host> telnet host <8bit> <inet> <inet6> <port port> <routing-instance routing-instance-name>
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 CLI, entre quit
.
Opção |
Descrição |
---|---|
|
Use um caminho de dados de 8 bits. |
|
Abra uma sessão telnet para o nome de host ou endereço IP especificado. |
|
Force a sessão telnet a um destino IPv4. |
|
Force a sessão telnet a um destino IPv6. |
|
Especifique o número da porta ou o nome do serviço no host. |
|
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 a um dispositivo remoto:
user@host> ssh host <bypass-routing> <inet> <inet6> <interface interface-name> <logical-system> <routing-instance routing-instance-name> <source address> <v2>
A Tabela 2 descreve as ssh
opções de comando.
Opção |
Descrição |
---|---|
|
Contorne as tabelas de roteamento e abra uma conexão SSH apenas para hosts em interfaces diretamente conectadas. Se o host não estiver em uma interface diretamente conectada, uma mensagem de erro será devolvida. |
|
Abra uma conexão SSH ao nome de host ou endereço IP especificado. |
|
Force a conexão SSH a um destino IPv4. |
|
Force a conexão SSH a um destino IPv6. |
|
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. |
|
Use a instância de roteamento especificada para a conexão SSH. |
|
Use o sistema lógico especificado para a conexão SSH. |
|
Use o endereço de origem especificado para a conexão SSH. |
|
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 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 de SSH, incluindo nomes de host e informações-chave do host na hierarquia de configuração do Mecanismo de Roteamento.
-
Defina 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 é autêntica.
-
Aceite a conexão segura. Aceitar essa conexão armazena automaticamente informações-chave do host no banco de dados local da chave do host. Armazenar informações-chave do host na hierarquia de configuração automatiza o aperto de mão seguro e permite a transferência de dados de fundo usando SCP.
As tarefas para configurar as chaves de host SSH para uma cópia segura dos dados são:
- Configure hosts conhecidos de SSH
- Configure o suporte para transferência de arquivos SCP
- Atualize as informações principais do host SSH
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:
[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; }
As chaves do host são uma das seguintes:
-
dsa-key key
— Algoritmo de assinatura digital (DSA) codificado base64 para SSH versão 2. -
ecdsa-sha2-nistp256-key
key— Base64 codificada chave ECDSA-SHA2-NIST256. -
ecdsa-sha2-nistp384-key
key— Base64 codificada chave ECDSA-SHA2-NIST384. -
ecdsa-sha2-nistp521-key
key— Base64 codificada chave ECDSA-SHA2-NIST521. -
ed25519-key
key— Chave ED25519 codificada base64. -
rsa-key key
— Algoritmo de chave pública codificado base64 que oferece suporte a criptografia e assinaturas digitais para as versões SSH 1 e SSH versão 2. -
rsa1-key key
— Algoritmo de chave pública RSA codificado 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 dar suporte a transferências de arquivo SCP de fundo, inclua a archive-sites
declaração no nível de [edit system archival configuration]
hierarquia.
[edit system archival configuration] archive-sites { scp://username<:password>@host<:port>/url-path; }
Ao especificar uma URL em uma declaração do Junos OS Evolved usando um endereço de host IPv6, você deve incluir toda a URL entre aspas (" ") e incluir o endereço de host IPv6 em suportes ([]). Por exemplo, "scp://username<:password>@[]host<:port>/url-path";
Definir a archive-sites
declaração para apontar para um 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.
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 verificar se a chave do host é autêntica, 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 armazenadas na configuração do Mecanismo de Roteamento e oferecem suporte a transferências de dados em segundo plano usando SCP.
Atualize 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.
- Recupere as informações da chave do host manualmente
- Importar informações-chave do host de um arquivo
Recupere 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 de onde recuperar a chave pública SSH.
user@host# set security ssh-known-hosts fetch-from-server <hostname>
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.
user@host# set security ssh-known-hosts load-key-file /var/tmp/known-hosts
Configure o serviço SSH para dar suporte à criptografia legado
O servidor SSH no Junos OS Evolved é baseado no OpenSSH 7 e é padrão para um conjunto mais seguro de cifras e algoritmos de troca de chaves. O OpenSSH 7 omite algumas criptografias legadas.
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 você pode configurar seu dispositivo para dar suporte a eles. Eles estão listados dos mais seguros aos menos seguros:
-
aes256-cbc
-
aes192-cbc
-
aes128-cbc
-
blowfish-cbc
-
cast128-cbc
-
arcfour256
-
arcfour128
-
arcfour
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 dar suporte a eles:
-
group-exchange-sha1
-
dh-group1-sha1
Para configurar o serviço SSH para dar suporte a criptografia legadas:
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).
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 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.
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é ter sucesso. Se a conexão entre o dispositivo e o aplicativo de gerenciamento do cliente for descartada, o dispositivo tenta novamente criar uma nova conexão SSH de saída até ter sucesso. Essa conexão é mantida até que a estrofe de 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 de SSH pública para o cliente SSH de saída
- Configure mensagens keepalive para conexões SSH de saída
- Configure uma nova conexão SSH de saída
- Configure o cliente SSH de saída para aceitar o NETCONF como um serviço disponível
- Configure clientes SSH de saída
- Configure instâncias de roteamento para clientes SSH de saída
Envie a chave de host de 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 o switch para o cliente de gerenciamento. Nesta 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 de [edit system services outbound-ssh client client-id]
hierarquia:
[edit system services outbound-ssh client client-id] device-id device-id;
A sequência de iniciação quando secret
não está configurada:
MSG-ID: DEVICE-CONN-INFO\r\n MSG-VER: V1\r\n DEVICE-ID: <device-id>\r\n
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. 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
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 de host SSH pública 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.
Incluir a secret
declaraçã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 do host podem mudar por vários motivos. Ao substituir a chave cada vez 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 de [edit system services outbound-ssh client client-id]
hierarquia:
[edit system services outbound-ssh client client-id] secret password;
A mensagem a seguir é enviada pelo dispositivo quando o secret
atributo está configurado:
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
Configure mensagens keepalive para conexões SSH de saída
Após o aplicativo do cliente ter a chave de host SSH pública do roteador ou do switch, ele pode iniciar a sequência de SSH como se tivesse criado a conexão TCP/IP. O cliente pode autenticar o dispositivo usando sua cópia da chave SSH de host pública 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 de protocolo SSH para o aplicativo do cliente, configure a keep-alive
declaração no nível de [edit system services outbound-ssh client client-id]
hierarquia:
[edit system services outbound-ssh client client-id] keep-alive { retry number; timeout seconds; }
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 da [edit system services outbound-ssh client client-id]
hierarquia:
[edit system services outbound-ssh client-id] reconnect-strategy (sticky | in-order);
Você também pode especificar o número de tentativasdes e definir o 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:
[edit system services outbound-ssh client client-id] services { netconf; }
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:
[edit system services outbound-ssh client client-id] address address { retry number; timeout seconds; port port-number; }
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 rejeitadas.
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.
-
A porta SSH padrão (22) continua a aceitar sessões NETCONF mesmo com uma porta de servidor NETCONF configurada. Para desativar a porta SSH de aceitar sessões NETCONF, especifique-a no script do 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.