Red Hat Training

A Red Hat training course is available for RHEL 8

Capítulo 26. Redes de segurança

26.1. Usando comunicações seguras entre dois sistemas com OpenSSH

SSH (Secure Shell) é um protocolo que fornece comunicações seguras entre dois sistemas usando uma arquitetura cliente-servidor e permite que os usuários façam login em sistemas host de servidores remotamente. Ao contrário de outros protocolos de comunicação remota, como FTP ou Telnet, o SSH criptografa a sessão de login, o que impede que intrusos coletem senhas não criptografadas da conexão.

O Red Hat Enterprise Linux inclui os pacotes básicos OpenSSH: o pacote geral openssh, o pacote openssh-server e o pacote openssh-clients. Note que os pacotes OpenSSH requerem o pacote OpenSSL openssl-libs , que instala várias bibliotecas criptográficas importantes que permitem que OpenSSH forneça comunicações criptografadas.

26.1.1. SSH e OpenSSH

SSH (Secure Shell) é um programa para efetuar login em uma máquina remota e executar comandos nessa máquina. O protocolo SSH fornece comunicações criptografadas seguras entre dois hosts não confiáveis através de uma rede insegura. Você também pode encaminhar conexões X11 e portas TCP/IP arbitrárias através do canal seguro.

O protocolo SSH atenua as ameaças à segurança, tais como interceptação da comunicação entre dois sistemas e imitação de um determinado host, quando você o utiliza para login remoto ou cópia de arquivo. Isto porque o cliente e o servidor SSH usam assinaturas digitais para verificar suas identidades. Além disso, toda a comunicação entre os sistemas cliente e servidor é criptografada.

OpenSSH é uma implementação do protocolo SSH suportada por uma série de sistemas operacionais Linux, UNIX e similares. Ele inclui os arquivos centrais necessários tanto para o cliente OpenSSH quanto para o servidor. A suíte OpenSSH consiste das seguintes ferramentas de espaço do usuário:

  • ssh é um programa de login remoto (cliente SSH)
  • sshd é um OpenSSH daemon SSH
  • scp é um programa seguro de cópia remota de arquivos
  • sftp é um programa seguro de transferência de arquivos
  • ssh-agent é um agente de autenticação para o cache de chaves privadas
  • ssh-add adiciona identidades chave privadas a ssh-agent
  • ssh-keygen gera, gerencia e converte chaves de autenticação para ssh
  • ssh-copy-id é um script que adiciona chaves públicas locais ao arquivo authorized_keys em um servidor SSH remoto
  • ssh-keyscan - reúne as chaves de anfitrião público do SSH

Existem atualmente duas versões do SSH: a versão 1, e a mais recente versão 2. A suíte OpenSSH no Red Hat Enterprise Linux 8 suporta apenas o SSH versão 2, que tem um algoritmo melhorado de troca de chaves não vulnerável a explorações conhecidas na versão 1.

OpenSSH, como um dos subsistemas criptográficos centrais da RHEL, utiliza políticas de criptografia em todo o sistema. Isto assegura que os conjuntos de cifras fracas e algoritmos criptográficos sejam desabilitados na configuração padrão. Para ajustar a política, o administrador deve usar o comando update-crypto-policies para fazer configurações mais rígidas ou mais frouxas ou optar manualmente pela exclusão das políticas criptográficas de todo o sistema.

A suíte OpenSSH utiliza dois conjuntos diferentes de arquivos de configuração: aqueles para programas de clientes (ou seja, ssh, scp e sftp), e aqueles para o servidor (o daemon sshd ). As informações de configuração SSH de todo o sistema são armazenadas no diretório /etc/ssh/. As informações de configuração do SSH específicas do usuário são armazenadas em ~/.ssh/, no diretório home do usuário. Para uma lista detalhada dos arquivos de configuração do OpenSSH, consulte a seção FILES na página de manual sshd(8).

Recursos adicionais

26.1.2. Configurando e iniciando um servidor OpenSSH

Use o seguinte procedimento para uma configuração básica que possa ser necessária para seu ambiente e para iniciar um servidor OpenSSH. Observe que após a instalação padrão da RHEL, o daemon sshd já foi iniciado e as chaves do servidor são criadas automaticamente.

Pré-requisitos

  • O pacote openssh-server está instalado.

Procedimento

  1. Inicie o daemon sshd na sessão atual e configure-o para iniciar automaticamente no momento da inicialização: 

    # systemctl start sshd
# systemctl enable sshd

  2. Para especificar endereços diferentes do padrão 0.0.0.0 (IPv4) ou :: (IPv6) para a diretiva ListenAddress no arquivo de configuração /etc/ssh/sshd_config e para usar uma configuração de rede dinâmica mais lenta, adicione a dependência da unidade alvo network-online.target ao arquivo de unidade sshd.service. Para conseguir isso, crie o arquivo /etc/systemd/system/sshd.service.d/local.conf com o seguinte conteúdo: 

    [Unit]
Wants=network-online.target
After=network-online.target
  3. Analise se as configurações do servidor OpenSSH no arquivo de configuração /etc/ssh/sshd_config atendem aos requisitos de seu cenário.

  4. Opcionalmente, altere a mensagem de boas-vindas que seu servidor OpenSSH exibe antes que um cliente se autentique, editando o arquivo /etc/issue, por exemplo: 

    Welcome to ssh-server.example.com
Warning: By accessing this server, you agree to the referenced terms and conditions.

    Certifique-se de que a opção Banner não seja comentada em /etc/ssh/sshd_config e seu valor contenha /etc/issue: 

    # less /etc/ssh/sshd_config | grep Banner
Banner /etc/issue

    Note que para alterar a mensagem exibida após um login bem sucedido, você tem que editar o arquivo /etc/motd no servidor. Consulte a página de manual pam_motd para maiores informações.

  5. Recarregue a configuração systemd e reinicie sshd para aplicar as mudanças: 

    # systemctl daemon-reload
# systemctl restart sshd

Etapas de verificação

  1. Verifique se o daemon sshd está funcionando: 

    # systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-11-18 14:59:58 CET; 6min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1149 (sshd)
    Tasks: 1 (limit: 11491)
   Memory: 1.9M
   CGroup: /system.slice/sshd.service
           └─1149 /usr/sbin/sshd -D -oCiphers=aes128-ctr,aes256-ctr,aes128-cbc,aes256-cbc -oMACs=hmac-sha2-256,>

Nov 18 14:59:58 ssh-server-example.com systemd[1]: Starting OpenSSH server daemon...
Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on 0.0.0.0 port 22.
Nov 18 14:59:58 ssh-server-example.com sshd[1149]: Server listening on :: port 22.
Nov 18 14:59:58 ssh-server-example.com systemd[1]: Started OpenSSH server daemon.

  2. Conecte-se ao servidor SSH com um cliente SSH. 

    # ssh user@ssh-server-example.com
ECDSA key fingerprint is SHA256:dXbaS0RG/UzlTTku8GtXSz0S1++lPegSy31v3L/FAEc.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'ssh-server-example.com' (ECDSA) to the list of known hosts.

user@ssh-server-example.com's password:

Recursos adicionais

  • sshd(8) e sshd_config(5) páginas man

26.1.3. Usando pares de chaves ao invés de senhas para autenticação SSH

Para melhorar ainda mais a segurança do sistema, gerar pares de chaves SSH e depois impor a autenticação baseada em chaves, desativando a autenticação por senha.

26.1.3.1. Configurando um servidor OpenSSH para autenticação baseada em chaves

Siga estes passos para configurar seu servidor OpenSSH para fazer cumprir a autenticação baseada em chaves.

Pré-requisitos

  • O pacote openssh-server está instalado.
  • O daemon sshd está rodando no servidor.

Procedimento

  1. Abra a configuração /etc/ssh/sshd_config em um editor de texto, por exemplo: 

    # vi /etc/ssh/sshd_config

  2. Mude a opção PasswordAuthentication para no: 

    SenhaAutenticação não

    Em um sistema que não seja uma nova instalação padrão, verifique se PubkeyAuthentication no não foi definido e se a diretiva ChallengeResponseAuthentication está definida para no. Se você estiver conectado remotamente, não usando console ou acesso fora da banda, teste o processo de login baseado em chave antes de desativar a autenticação da senha.

  3. Para utilizar a autenticação baseada em chaves com diretórios domésticos montados em NFS, habilite o use_nfs_home_dirs SELinux boolean: 

    # setsebool -P use_nfs_home_dirs 1

  4. Recarregue o daemon sshd para aplicar as mudanças: 

    # systemctl reload sshd

Recursos adicionais

  • sshd(8), sshd_config(5), e setsebool(8) páginas man

26.1.3.2. Geração de pares de chaves SSH

Use este procedimento para gerar um par de chaves SSH em um sistema local e para copiar a chave pública gerada para um servidor OpenSSH. Se o servidor estiver configurado de acordo, você pode entrar no servidor OpenSSH sem fornecer nenhuma senha.

Importante

Se você completar os seguintes passos como root, somente root é capaz de usar as chaves.

Procedimento

  1. Para gerar um par de chaves ECDSA para a versão 2 do protocolo SSH: 

    $ ssh-keygen -t ecdsa
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/joesec/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/joesec/.ssh/id_ecdsa.
Your public key has been saved in /home/joesec/.ssh/id_ecdsa.pub.
The key fingerprint is:
SHA256:Q/x+qms4j7PCQ0qFd09iZEFHA+SqwBKRNaU72oZfaCI joesec@localhost.example.com
The key's randomart image is:
+---[ECDSA 256]---+
|.oo..o=++        |
|.. o .oo .       |
|. .. o. o        |
|....o.+...       |
|o.oo.o +S .      |
|.=.+.   .o       |
|E.*+.  .  . .    |
|.=..+ +..  o     |
|  .  oo*+o.      |
+----[SHA256]-----+

    Você também pode gerar um par de chaves RSA usando a opção -t rsa com o comando ssh-keygen ou um par de chaves Ed25519, digitando o comando ssh-keygen -t ed25519.

  2. Para copiar a chave pública para uma máquina remota: 

    $ ssh-copy-id joesec@ssh-server-example.com
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
joesec@ssh-server-example.com's password:
...
Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'joesec@ssh-server-example.com'" and check to make sure that only the key(s) you wanted were added.

    Se você não usar o programa ssh-agent em sua sessão, o comando anterior copia a chave pública ~/.ssh/id*.pub modificada mais recentemente, caso ainda não esteja instalada. Para especificar outro arquivo de chave pública ou para priorizar chaves em arquivos sobre chaves armazenadas em cache na memória por ssh-agent, use o comando ssh-copy-id com a opção -i.

Nota

Se você reinstalar seu sistema e quiser manter os pares de chaves gerados anteriormente, faça backup do diretório ~/.ssh/. Após a reinstalação, copie-o de volta para seu diretório home. Você pode fazer isso para todos os usuários em seu sistema, incluindo root.

Etapas de verificação

  1. Acesse o servidor OpenSSH sem fornecer nenhuma senha: 

    $ ssh joesec@ssh-server-example.com
Welcome message.
...
Last login: Mon Nov 18 18:28:42 2019 from ::1

Recursos adicionais

  • ssh-keygen(1) e ssh-copy-id(1) páginas man

26.1.4. Usando chaves SSH armazenadas em um cartão inteligente

O Red Hat Enterprise Linux 8 permite que você use chaves RSA e ECDSA armazenadas em um cartão inteligente em clientes OpenSSH. Use este procedimento para habilitar a autenticação usando um Cartão Smart Card ao invés de usar uma senha.

Pré-requisitos

  • No lado do cliente, o pacote opensc está instalado e o serviço pcscd está funcionando.

Procedimento

  1. Liste todas as chaves fornecidas pelo módulo OpenSC PKCS #11 incluindo seus PKCS #11 URIs e salve a saída para o arquivo keys.pub: 

    $ ssh-keygen -D pkcs11: > keys.pub
$ ssh-keygen -D pkcs11:
ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

  2. Para permitir a autenticação usando um cartão inteligente em um servidor remoto (example.com), transfira a chave pública para o servidor remoto. Use o comando ssh-copy-id com keys.pub criado na etapa anterior: 

    $ ssh-copy-id -f -i keys.pub username@example.com

  3. Para conectar-se a example.com usando a chave ECDSA da saída do comando ssh-keygen -D no passo 1, você pode usar apenas um subconjunto do URI, que faz referência única à sua chave, por exemplo: 

    $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
Enter PIN for 'SSH key':
[example.com] $

  4. Você pode usar a mesma cadeia URI no arquivo ~/.ssh/config para tornar a configuração permanente: 

    $ cat ~/.ssh/config
IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
$ ssh example.com
Enter PIN for 'SSH key':
[example.com] $

    Como o OpenSSH usa a embalagem p11-kit-proxy e o módulo OpenSC PKCS #11 está registrado no Kit PKCS #11, você pode simplificar os comandos anteriores: 

    $ ssh -i "pkcs11:id=%01" example.com
Enter PIN for 'SSH key':
[example.com] $

Se você pular a parte id= de um PKCS #11 URI, o OpenSSH carrega todas as chaves que estão disponíveis no módulo proxy. Isto pode reduzir a quantidade de digitação necessária: 

$ ssh -i pkcs11: example.com
Enter PIN for 'SSH key':
[example.com] $

Recursos adicionais

26.1.5. Tornando o OpenSSH mais seguro

As seguintes dicas o ajudam a aumentar a segurança ao usar o OpenSSH. Note que as mudanças no arquivo de configuração /etc/ssh/sshd_config OpenSSH requerem o recarregamento do daemon sshd para ter efeito: 

# systemctl reload sshd
Importante

A maioria das mudanças de configuração de endurecimento de segurança reduz a compatibilidade com clientes que não suportam algoritmos atualizados ou conjuntos de cifras.

Desabilitando protocolos de conexão inseguros

  • Para tornar o SSH verdadeiramente eficaz, evite o uso de protocolos de conexão inseguros que são substituídos pela suíte OpenSSH. Caso contrário, a senha de um usuário pode ser protegida usando SSH para apenas uma sessão, a ser capturada posteriormente ao fazer o login usando o Telnet. Por este motivo, considere desativar protocolos inseguros, tais como telnet, rsh, rlogin e ftp.

Habilitação da autenticação baseada em chave e desativação da autenticação baseada em senha

  • Desabilitar senhas para autenticação e permitir apenas pares de chaves reduz a superfície de ataque e também pode poupar o tempo dos usuários. Em clientes, gerar pares de chaves usando a ferramenta ssh-keygen e usar o utilitário ssh-copy-id para copiar chaves públicas de clientes no servidor OpenSSH. Para desativar a autenticação baseada em senhas em seu servidor OpenSSH, edite /etc/ssh/sshd_config e mude a opção PasswordAuthentication para no: 

    SenhaAutenticação não

Tipos de chaves

  • Embora o comando ssh-keygen gere um par de chaves RSA por padrão, você pode instruí-lo a gerar chaves ECDSA ou Ed25519 usando a opção -t. O ECDSA (Elliptic Curve Digital Signature Algorithm) oferece melhor desempenho do que o RSA com a força simétrica equivalente da chave. Ele também gera chaves mais curtas. O algoritmo de chave pública Ed25519 é uma implementação de curvas Edwards retorcidas que é mais segura e também mais rápida que RSA, DSA, e ECDSA.

    O OpenSSH cria automaticamente chaves de servidor RSA, ECDSA e Ed25519 se elas estiverem faltando. Para configurar a criação da chave de host no RHEL 8, use o serviço instanciado sshd-keygen@.service. Por exemplo, para desativar a criação automática do tipo de chave RSA: 

    # systemctl mask sshd-keygen@rsa.service
  • Para excluir tipos-chave específicos para conexões SSH, comente as linhas relevantes em /etc/ssh/sshd_config, e recarregue o serviço sshd. Por exemplo, para permitir apenas as chaves de host Ed25519: 
# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Porto sem falta

  • Por padrão, o daemon sshd ouve na porta TCP 22. A mudança da porta reduz a exposição do sistema a ataques baseados em varredura automatizada da rede e, assim, aumenta a segurança através da obscuridade. Você pode especificar a porta usando a diretiva Port no arquivo de configuração /etc/ssh/sshd_config.

    Você também tem que atualizar a política padrão da SELinux para permitir o uso de uma porta não inadimplente. Para fazer isso, utilize a ferramenta semanage do pacote policycoreutils-python-utils: 

    # semanage port -a -t ssh_port_t -p tcp port_number

    Além disso, atualizar a configuração firewalld: 

    # firewall-cmd --add-port port_number/tcp
# firewall-cmd --runtime-to-permanent

    Nos comandos anteriores, substituir port_number pelo novo número de porta especificado usando a diretiva Port.

Sem login de raiz

  • Se seu caso particular de uso não exigir a possibilidade de login como usuário root, você deve considerar a possibilidade de configurar a diretiva de configuração PermitRootLogin para no no arquivo /etc/ssh/sshd_config. Desativando a possibilidade de logar-se como usuário root, o administrador pode auditar quais usuários executam que comandos privilegiados depois de logar-se como usuários regulares e depois ganhar direitos de root.

    Alternativamente, defina PermitRootLogin para prohibit-password: 

    PermitRootLogin proíbe palavras-passe

    Isto reforça o uso de autenticação baseada em chaves em vez do uso de senhas para o login como raiz e reduz os riscos ao prevenir ataques de força bruta.

Usando a extensão X Security

  • O servidor X em clientes Red Hat Enterprise Linux não fornece a extensão X Security. Portanto, os clientes não podem solicitar outra camada de segurança ao conectar-se a servidores SSH não confiáveis com o encaminhamento X11. A maioria das aplicações não é capaz de rodar com esta extensão habilitada de qualquer forma.

    Por padrão, a opção ForwardX11Trusted no arquivo /etc/ssh/ssh_config.d/05-redhat.conf está definida para yes, e não há diferença entre o comando ssh -X remote_machine (host não confiável) e ssh -Y remote_machine (trust host).

    Se seu cenário não exigir o recurso de encaminhamento X11, defina a diretiva X11Forwarding no arquivo de configuração /etc/ssh/sshd_config para no.

Restringir o acesso a usuários, grupos ou domínios específicos

  • As diretrizes AllowUsers e AllowGroups no servidor de arquivos de configuração /etc/ssh/sshd_config permitem que você permita que somente determinados usuários, domínios ou grupos se conectem ao seu servidor OpenSSH. Você pode combinar AllowUsers e AllowGroups para restringir o acesso de forma mais precisa, por exemplo: 

    AllowUsers *@192.168.1.*,*@10.0.0.*,!*@192.168.1.2
AllowGroups example-group

    As linhas de configuração anteriores aceitam conexões de todos os usuários dos sistemas em 192.168.1.* e 10.0.0.* sub-redes, exceto do sistema com o endereço 192.168.1.2. Todos os usuários devem estar no grupo example-group. O servidor OpenSSH nega todas as outras conexões.

    Observe que o uso de listas de permissão (diretrizes que começam com Allow) é mais seguro do que o uso de listas de bloco (opções que começam com Deny) porque as listas de permissão também bloqueiam novos usuários ou grupos não autorizados.

Mudando as políticas criptográficas de todo o sistema

  • OpenSSH utiliza as políticas criptográficas do sistema RHEL, e o nível padrão de políticas criptográficas do sistema oferece configurações seguras para os modelos de ameaça atuais. Para tornar suas configurações criptográficas mais rígidas, altere o nível da política atual: 

    # update-crypto-policies --set FUTURE
Setting system policy to FUTURE
  • Para optar pela exclusão das políticas de criptografia de todo o sistema para seu servidor OpenSSH, descomente a linha com a variável CRYPTO_POLICY= no arquivo /etc/sysconfig/sshd. Após esta mudança, os valores que você especificar nas seções Ciphers, MACs, KexAlgoritms, e GSSAPIKexAlgorithms no arquivo /etc/ssh/sshd_config não serão sobrepostos. Note que esta tarefa requer profunda experiência na configuração de opções criptográficas.
  • Veja Utilizando políticas criptográficas em todo o sistema no título de endurecimento de segurança RHEL 8 para mais informações.

Recursos adicionais

  • sshd_config(5), ssh-keygen(1), crypto-policies(7), e update-crypto-policies(8) páginas man

26.1.6. Conexão a um servidor remoto usando um host SSH jump

Use este procedimento para conectar-se a um servidor remoto através de um servidor intermediário, também chamado de jump host.

Pré-requisitos

  • Um host de salto aceita conexões SSH de seu sistema.
  • Um servidor remoto aceita conexões SSH somente a partir do host de salto.

Procedimento

  1. Defina o host de salto, editando o arquivo ~/.ssh/config, por exemplo: 

    Host jump-server1
  HostName jump1.example.com

  2. Adicione a configuração de salto do servidor remoto com a diretiva ProxyJump para ~/.ssh/config, por exemplo: 

    Host remote-server
  HostName remote1.example.com
  ProxyJump jump-server1

  3. Conecte-se ao servidor remoto através do servidor de salto: 

    $ ssh remote-server

    O comando anterior é equivalente ao comando ssh -J jump-server1 remote-server se você omitir os passos de configuração 1 e 2.

Nota

Você pode especificar mais servidores de salto e também pode pular a adição de definições de host ao arquivo de configurações quando você fornecer seus nomes de host completos, por exemplo: 

$ ssh -J jump1.example.com,jump2.example.com,jump3.example.com remote1.example.com

Mude a notação do nome do host apenas no comando anterior se os nomes dos usuários ou portas SSH nos servidores de salto forem diferentes dos nomes e portas no servidor remoto, por exemplo: 

$ ssh -J johndoe@jump1.example.com:75,johndoe@jump2.example.com:75,johndoe@jump3.example.com:75 joesec@remote1.example.com:220

Recursos adicionais

  • ssh_config(5) e ssh(1) páginas man

26.1.7. Conexão a máquinas remotas com chaves SSH usando o ssh-agent

Para evitar a entrada de uma senha cada vez que você inicia uma conexão SSH, você pode usar o utilitário ssh-agent para fazer o cache da chave SSH privada. A chave privada e a frase-senha permanecem seguras.

Pré-requisitos

  • Você tem um host remoto com daemon SSH rodando e alcançável através da rede.
  • Você sabe o endereço IP ou o nome do host e as credenciais para fazer o login no host remoto.
  • Você gerou um par de chaves SSH com uma frase-chave e transferiu a chave pública para a máquina remota. Para mais informações, consulte Gerando pares de chaves SSH.

Procedimento

  1. Opcional: Verifique se você pode usar a chave para autenticar no host remoto:

    1. Conecte-se ao host remoto usando SSH: 

      $ ssh example.user1@198.51.100.1 hostname

    2. Digite a frase-chave que você definiu ao criar a chave para conceder acesso à chave privada. 

      $ ssh example.user1@198.51.100.1 hostname
 host.example.com

  2. Inicie o ssh-agent. 

    $ eval $(ssh-agent)
Agent pid 20062

  3. Adicione a chave a ssh-agent. 

    $ ssh-add ~/.ssh/id_rsa
Enter passphrase for ~/.ssh/id_rsa:
Identity added: ~/.ssh/id_rsa (example.user0@198.51.100.12)

Etapas de verificação

  • Opcional: Faça o login na máquina host usando SSH. 

    $ ssh example.user1@198.51.100.1

Last login: Mon Sep 14 12:56:37 2020

    Note que você não precisou digitar a senha.

26.1.8. Recursos adicionais

Para mais informações sobre configuração e conexão com servidores e clientes do OpenSSH no Red Hat Enterprise Linux, veja os recursos listados abaixo.

Documentação instalada

  • sshd(8) página man documenta as opções de linha de comando disponíveis e fornece uma lista completa de arquivos de configuração e diretórios suportados.
  • a página de manualssh(1) fornece uma lista completa de opções de linha de comando disponíveis e arquivos de configuração e diretórios suportados.
  • a página de manualscp(1) fornece uma descrição mais detalhada da utilidade scp e seu uso.
  • a página de manualsftp(1) fornece uma descrição mais detalhada da utilidade sftp e seu uso.
  • ssh-keygen(1) man page documents in detail the use of the ssh-keygen utility to generate, manage, and convert authentication keys used by ssh.
  • a página de manualssh-copy-id(1) descreve o uso do roteiro ssh-copy-id.
  • ssh_config(5) página man documentos disponíveis opções de configuração do cliente SSH.
  • a página de manualsshd_config(5) fornece uma descrição completa das opções de configuração do daemon SSH disponíveis.
  • a página de manualupdate-crypto-policies(8) fornece orientação sobre o gerenciamento de políticas criptográficas de todo o sistema
  • crypto-policies(7) página man fornece uma visão geral dos níveis de política criptográfica de todo o sistema

Documentação on-line