SSH Seguro no Red Hat Enterprise Linux

Red Hat Enterprise LinuxBeginner
Pratique Agora

Introdução

Neste laboratório, você ganhará experiência prática na configuração e segurança de conexões SSH, uma habilidade fundamental para gerenciar sistemas Linux remotos. Você começará aprendendo a acessar sistemas remotos usando SSH, compreendendo a arquitetura cliente-servidor e comandos básicos de conexão. Isso inclui verificar a instalação do cliente SSH, conectar-se a um host remoto, lidar com solicitações de autenticação do host e fazer login e logout de sistemas remotos.

Construindo sobre essa base, você mergulhará em tópicos mais avançados, como gerar e utilizar pares de chaves SSH para autenticação sem senha, gerenciar essas chaves eficazmente com ssh-agent e solucionar problemas comuns de conexão SSH. Finalmente, você aprenderá a personalizar as configurações do cliente SSH para maior eficiência e aprimorar a segurança do seu servidor OpenSSH desabilitando o login root e a autenticação por senha, garantindo acesso remoto robusto e seguro.

Acesso a Sistemas Remotos com SSH

Neste passo, você aprenderá a acessar sistemas remotos usando SSH (Secure Shell). SSH é um protocolo de rede criptográfico para operar serviços de rede de forma segura em uma rede não segura. Ele fornece um canal seguro em uma rede não segura usando uma arquitetura cliente-servidor, conectando um cliente SSH a um servidor SSH.

Observação: Neste ambiente de laboratório, alguns recursos de segurança, como restrições de login root, podem já estar configurados por motivos de segurança. Isso é normal e demonstra as melhores práticas em ação.

Primeiro, você se conectará ao sistema local usando SSH. Isso demonstra a arquitetura cliente-servidor SSH, mesmo ao se conectar à mesma máquina. Você usará o comando ssh para se conectar a localhost.

A sintaxe básica para ssh é:
ssh [username]@[hostname_or_IP]

Se você não especificar um nome de usuário, o SSH tentará fazer login com seu nome de usuário local atual. Neste caso, seu nome de usuário local é labex.

Vamos tentar conectar a localhost usando seu nome de usuário atual:

ssh localhost

Quando você se conecta pela primeira vez, o SSH solicitará que você confirme a autenticidade do host. Esta é uma medida de segurança para evitar ataques do tipo "homem no meio". Digite yes e pressione Enter.

A autenticidade do host 'localhost (127.0.0.1)' não pode ser estabelecida.
A impressão digital da chave ED25519 é SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Esta chave não é conhecida por nenhum outro nome
Você tem certeza que deseja continuar a conexão (sim/não/[fingerprint])? yes
Aviso: 'localhost' (ED25519) adicionado permanentemente à lista de hosts conhecidos.
Senha de 'labex@localhost':

Você será solicitado a inserir a senha do usuário labex. Digite labex e pressione Enter.

Senha de 'labex@localhost':
Último login: Seg 09 jun 01:34:39 2025 de 47.251.66.143
[labex@host ~]$

Você agora está conectado via SSH a localhost. Observe que seu prompt pode mostrar [labex@localhost ~]$, indicando que você está conectado via SSH.

Para sair da sessão SSH, use o comando exit:

exit
logout
Conexão com localhost fechada.
[labex@host ~]$

Agora, vamos tentar conectar a localhost como o usuário root. Note que neste ambiente, o login root pode estar desabilitado por padrão por motivos de segurança.

ssh root@localhost

Você será solicitado a inserir a senha do root. No entanto, você pode encontrar uma mensagem "Permissão negada" se o login root estiver desabilitado:

Senha de 'root@localhost':
Permissão negada, tente novamente.
Senha de 'root@localhost':
Permissão negada, tente novamente.
Senha de 'root@localhost':

Se o login root estiver desabilitado, este é o comportamento esperado e demonstra uma boa prática de segurança. Você pode pressionar Ctrl+C para cancelar a tentativa de conexão.

O SSH também pode ser usado para executar um único comando em um sistema remoto sem abrir um shell interativo. Isso é útil para verificações rápidas ou automação.

Vamos executar o comando hostname em localhost como o usuário labex:

ssh labex@localhost hostname

Você será solicitado a inserir a senha do usuário labex. Digite labex e pressione Enter.

Senha de 'labex@localhost':
6846375f1c0e35fea6cb03e6
[labex@host ~]$

O comando hostname foi executado via SSH e sua saída foi exibida em seu terminal local. Você não foi levado para um shell interativo.

Finalmente, vamos explorar como o SSH gerencia hosts conhecidos. Quando você se conecta a um novo servidor SSH, a impressão digital da chave pública dele é adicionada ao seu arquivo ~/.ssh/known_hosts. Este arquivo ajuda seu cliente SSH a verificar a identidade do servidor em conexões futuras.

Você pode visualizar o conteúdo do seu arquivo ~/.ssh/known_hosts:

cat ~/.ssh/known_hosts
localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHvl7dcZkvMNOr3cjKjlR2/JgFbGpURThT/bHnLZN6gG
localhost ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCynhy3601o9ZSGZoY0KB/QSonk5ykod2Tb7sCAqVn4ZgTCwd96BhPjJLPNQ6ldNASo1e7EzfT4BUjG5T0ZDRhgaI65qmDwITWipTWUfmYT5XoScyf6NDhcRxYiJwztFEkOvLcPhelS6UXj5Z7HdmYH4Nc5wiF00Wah3Jc0/2CfQsFZCXTn/7Kp8KKbBbPqPzr2R3WIULEacOxx9HKVv+2TvYg/OHZz40hTsr1c68DD7h5PMBNe21YB3HLRRk2LQEC7v7BFD+DCek9GNR66JBjbLDljtwWCaPCY0UntBjjvJ3W2LhX5RDZQHV/iaUSj2tEXnvPt9KSqGfBS91D12dBXyOmWVnTpvvI17BdDkEeefas2Uz4d7Bv/PDxZR6IKkaIGQ/ZnRhSEhBNvfqlBGqkOhRr6jQJK+rQMnsZCT6OEgW7osWzkw5Bs1wY/RNToeQqrRMclqffO9plFI688N2iT86+nxrvBVZg4yMMmJ1lleaBvinXCB8jE6lrtwoAdgk=
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKYWY8Ty6TrbQS/0fUljBWuUpkyPCS/5P6ZwxhSYsqjRBIprMANI/JQotZqHYq2w3b2X/n8O+J3/WuIB6XMl1f4=

Estas entradas confirmam que seu cliente registrou várias chaves públicas para localhost (ED25519, RSA e ECDSA). O servidor SSH pode suportar vários tipos de chave para compatibilidade. Se alguma dessas chaves do servidor mudar inesperadamente, o SSH emitirá um aviso, o que é um recurso de segurança crucial.

Gerar e Usar Pares de Chaves SSH para Autenticação Sem Senha

Neste passo, você aprenderá a gerar pares de chaves SSH e usá-los para autenticação sem senha. A autenticação baseada em chaves SSH é uma alternativa mais segura e conveniente à autenticação por senha. Em vez de digitar uma senha toda vez que se conecta, você usa um par de chaves criptográficas: uma chave privada (mantida em segredo em sua máquina local) e uma chave pública (colocada no servidor remoto).

Primeiro, você precisa gerar um par de chaves SSH. Você usará o comando ssh-keygen para esse fim. Por padrão, ssh-keygen cria um par de chaves RSA e salva a chave privada em ~/.ssh/id_rsa e a chave pública em ~/.ssh/id_rsa.pub.

Execute o comando ssh-keygen:

ssh-keygen

Você será solicitado a fornecer algumas opções:

Gerando par de chaves rsa público/privado.
Digite o nome do arquivo para salvar a chave (/home/labex/.ssh/id_rsa):

Pressione Enter para aceitar o caminho padrão (/home/labex/.ssh/id_rsa).

Digite a senha (vazio para nenhuma senha):

Para este laboratório, pressione Enter duas vezes para deixar a senha em branco. Embora o uso de uma senha seja recomendado em cenários do mundo real para adicionar uma camada extra de segurança, vamos ignorá-la aqui para simplificar e demonstrar a autenticação sem senha diretamente.

Digite a senha (vazio para nenhuma senha):
Digite a mesma senha novamente:
Sua identificação foi salva em /home/labex/.ssh/id_rsa
Sua chave pública foi salva em /home/labex/.ssh/id_rsa.pub
A impressão digital da chave é:
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
A imagem randomart da chave é:
+---[RSA 3072]----+
|     . *=o .   +.|
|    . =oE.o . O. |
|     o.++.=..*.+.|
|     .o .O+o+o. =|
|      ..So + o.+ |
|       .  . . +  |
|           .   . |
|            . o o|
|            .=.o |
+----[SHA256]-----+

Agora, verifique se os arquivos de chave foram criados no diretório ~/.ssh/:

ls -l ~/.ssh/
total 16
-rw------- 1 labex labex 2622 Jun  9 01:37 id_rsa
-rw-r--r-- 1 labex labex  584 Jun  9 01:37 id_rsa.pub
-rw------- 1 labex labex  825 Jun  9 01:35 known_hosts
-rw-r--r-- 1 labex labex   91 Jun  9 01:35 known_hosts.old

Você deve ver id_rsa (sua chave privada) e id_rsa.pub (sua chave pública). Observe as permissões: id_rsa tem rw------- (leitura/escrita somente para o proprietário), o que é crucial para a segurança. Você também pode ver known_hosts.old, que é um backup do arquivo known_hosts anterior.

Em seguida, você precisa copiar sua chave pública para habilitar a autenticação sem senha. O comando ssh-copy-id foi projetado para esse fim. Ele anexa sua chave pública ao arquivo ~/.ssh/authorized_keys, permitindo que você faça login sem senha.

Execute o comando ssh-copy-id, especificando o usuário e o nome do host:

ssh-copy-id labex@localhost

Você será solicitado a inserir a senha do usuário labex. Digite labex e pressione Enter.

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
labex@localhost's password:

Number of key(s) added: 1

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

A saída do comando confirma que uma chave foi adicionada. Agora, tente fazer login em localhost como labex sem fornecer uma senha:

ssh labex@localhost

Se tudo estiver configurado corretamente, você deverá fazer login via SSH sem ser solicitado a fornecer uma senha.

Último login: Seg 09 jun 01:37:39 2025 de 47.251.66.143
[labex@host ~]$

Você configurou com sucesso a autenticação SSH sem senha usando pares de chaves!

Para sair da sessão remota, digite exit:

exit
exit
Conexão com localhost fechada.
[labex@host ~]$

Gerenciar Chaves SSH com ssh-agent

Neste passo, você aprenderá a gerenciar suas chaves SSH usando ssh-agent. O ssh-agent é um programa que roda em segundo plano e mantém suas chaves privadas na memória. Isso é particularmente útil quando suas chaves privadas são protegidas por uma frase-senha. Em vez de digitar a frase-senha toda vez que usar a chave, você a digita uma vez ao adicionar a chave ao ssh-agent, e então o agente gerencia a autenticação por você durante a duração de sua sessão.

Embora você tenha gerado uma chave sem frase-senha no passo anterior, agora criaremos uma nova chave com uma frase-senha para demonstrar a utilidade do ssh-agent.

Primeiro, gere um novo par de chaves SSH com uma frase-senha. Chamaremos esta chave de id_rsa_passphrase para distingui-la da chave padrão id_rsa.

ssh-keygen -f ~/.ssh/id_rsa_passphrase

Você será solicitado a inserir uma frase-senha. Para este laboratório, use mypassphrase como a frase-senha.

Gerando par de chaves rsa público/privado.
Digite a senha (vazio para nenhuma senha): mypassphrase
Digite a mesma senha novamente: mypassphrase
Sua identificação foi salva em /home/labex/.ssh/id_rsa_passphrase
Sua chave pública foi salva em /home/labex/.ssh/id_rsa_passphrase.pub
A impressão digital da chave é:
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
A imagem randomart da chave é:
+---[RSA 3072]----+
|   ...=o+=*. E   |
|    .o.*.=..+ o  |
|     .=.o o. = . |
|  .  .+... .. . .|
| . . . +S.     + |
|  . o ..o . o * .|
|   . .   . . = * |
|             oooo|
|            ..+.o|
+----[SHA256]-----+

Observação: Se você acidentalmente pressionar Enter sem digitar uma frase-senha, a chave será criada sem uma. Nesse caso, você pode excluir os arquivos e executar o comando novamente, garantindo que digite mypassphrase quando solicitado.

Agora, vamos copiar esta nova chave pública para localhost para que você possa usá-la para autenticação.

ssh-copy-id -i ~/.ssh/id_rsa_passphrase.pub labex@localhost

Como você já tem autenticação sem senha configurada com sua chave padrão, o comando pode não solicitar uma senha e usará sua autenticação existente:

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa_passphrase.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

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

Agora, tente se conectar a localhost usando esta nova chave. Você precisará especificar o arquivo da chave privada usando a opção -i.

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Se você definiu uma frase-senha para a chave, será solicitado a inseri-la. No entanto, se você acidentalmente criou a chave sem uma frase-senha (como mostrado na saída do exemplo), você será logado diretamente:

Último login: Seg 09 jun 01:39:25 2025 de 47.251.66.143
[labex@host ~]$

Você está logado. Agora, saia da sessão:

exit
exit
Conexão com localhost fechada.
[labex@host ~]$

Observação: Se sua chave não tiver uma frase-senha, você ainda pode continuar com a demonstração do ssh-agent para entender como funciona, embora não solicite uma frase-senha nesse caso.

Primeiro, inicie o ssh-agent em sua sessão de shell atual. O comando eval é usado para definir corretamente as variáveis de ambiente que o ssh-agent gera.

eval "$(ssh-agent)"
Agent pid 1024

A saída mostrará o ID do processo (PID) do ssh-agent.

Em seguida, adicione sua chave privada (id_rsa_passphrase) ao ssh-agent.

ssh-add ~/.ssh/id_rsa_passphrase

Se sua chave tiver uma frase-senha, você será solicitado a inseri-la. Caso contrário, a chave será adicionada diretamente:

Identity added: /home/labex/.ssh/id_rsa_passphrase (labex@6846375f1c0e35fea6cb03e6)

Agora que a chave foi adicionada ao ssh-agent, tente se conectar a localhost novamente usando a mesma chave.

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Você deve conseguir se conectar sem ser solicitado a inserir uma frase-senha (se sua chave tiver ou não, já que agora é gerenciada pelo agente):

Último login: Seg 09 jun 01:39:49 2025 de 127.0.0.1
[labex@host ~]$

Você usou com sucesso o ssh-agent para gerenciar sua chave SSH.

Observação Importante: As variáveis de ambiente do ssh-agent só estão disponíveis na sessão de shell onde você o iniciou. Se você estiver em uma sessão SSH, precisará sair para o shell local para usar os comandos ssh-add.

Saia da sessão SSH primeiro:

exit
exit
Conexão com localhost fechada.
[labex@host ~]$

Agora, para ver as chaves atualmente carregadas em seu ssh-agent, você pode usar ssh-add -l:

ssh-add -l

Se o agente estiver em execução e tiver chaves carregadas, você verá uma saída como:

3072 SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg /home/labex/.ssh/id_rsa_passphrase (RSA)

No entanto, se você vir uma mensagem de erro como "Não foi possível abrir uma conexão com seu agente de autenticação", significa que as variáveis de ambiente do agente não estão definidas em sua sessão atual.

Para remover todas as identidades do ssh-agent, use ssh-add -D:

ssh-add -D

Se o agente for acessível, você verá:

Todas as identidades removidas.

No entanto, se você vir "Não foi possível abrir uma conexão com seu agente de autenticação", significa que o ambiente do agente não está disponível em sua sessão atual.

Agora, se você tentar se conectar novamente e sua chave tiver uma frase-senha, você será solicitado a inseri-la porque a chave foi removida do agente:

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Se sua chave tiver uma frase-senha, você verá:

Digite a frase-senha para a chave '/home/labex/.ssh/id_rsa_passphrase':

Se sua chave não tiver uma frase-senha, você ainda poderá se conectar diretamente. Pressione Ctrl+C para cancelar a tentativa de conexão se for solicitado a inserir uma frase-senha.

Finalmente, para parar o processo ssh-agent, você pode usar ssh-agent -k:

ssh-agent -k

Se a variável de ambiente SSH_AGENT_PID não estiver definida, você poderá ver:

SSH_AGENT_PID não definido, não é possível matar o agente

Isso é normal se o agente foi iniciado em uma sessão de shell diferente ou se as variáveis de ambiente não foram exportadas corretamente.

Solucionar Problemas de Conexão SSH

Neste passo, você aprenderá a solucionar problemas comuns de conexão SSH. Quando as conexões SSH falham, pode ser desafiador identificar o problema exato. O comando ssh oferece opções de saída detalhadas que podem ajudar a diagnosticar problemas, mostrando informações detalhadas sobre o processo de conexão.

O comando ssh oferece três níveis de detalhamento: -v, -vv e -vvv. Cada v adicional aumenta a quantidade de informações de depuração exibidas.

Vamos começar tentando conectar a uma porta inexistente em localhost para demonstrar uma falha de conexão e ver a saída de depuração.

Primeiro, tente com -v (detalhado) para conectar à porta 2222 (que não deve estar em execução):

ssh -v -p 2222 labex@localhost

Você verá uma saída semelhante a esta, indicando que a conexão foi recusada:

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Lendo dados de configuração /etc/ssh/ssh_config
debug1: Lendo dados de configuração /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf linha 1: Aplicando opções para *
debug1: Lendo dados de configuração /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf linha 3: Aplicando opções para *
debug1: Conectando a localhost [127.0.0.1] porta 2222.
ssh: conectar ao host localhost porta 2222: Conexão recusada

Agora, vamos tentar com -vv (mais detalhado):

ssh -vv -p 2222 labex@localhost

A saída será mais detalhada, fornecendo mensagens de depuração adicionais:

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Lendo dados de configuração /etc/ssh/ssh_config
debug1: Lendo dados de configuração /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf linha 1: Aplicando opções para *
debug1: Lendo dados de configuração /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf linha 3: Aplicando opções para *
debug2: resolvendo "localhost" porta 2222
debug2: ssh_connect_direct: entrando
debug1: Conectando a localhost [127.0.0.1] porta 2222.
debug1: conectar ao endereço 127.0.0.1 porta 2222: Conexão recusada
ssh: conectar ao host localhost porta 2222: Conexão recusada

Finalmente, tente com -vvv (mais detalhado):

ssh -vvv -p 2222 labex@localhost

Este nível fornece o máximo de informações de depuração, que pode ser excessivo, mas extremamente útil para problemas complexos.

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug3: ssh_connect_internal: entrando
debug1: Lendo dados de configuração /etc/ssh/ssh_config
debug1: Lendo dados de configuração /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf linha 1: Aplicando opções para *
debug1: Lendo dados de configuração /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf linha 3: Aplicando opções para *
debug2: resolvendo "localhost" porta 2222
debug2: ssh_connect_direct: entrando
debug1: Conectando a localhost [127.0.0.1] porta 2222.
debug1: conectar ao endereço 127.0.0.1 porta 2222: Conexão recusada
ssh: conectar ao host localhost porta 2222: Conexão recusada

Neste caso, o erro "Conexão recusada" indica claramente que não há um servidor SSH em execução na porta 2222.

Agora, vamos simular um problema comum: uma chave de host alterada. No primeiro passo, você se conectou a localhost, e sua chave pública foi adicionada ao seu arquivo ~/.ssh/known_hosts. Se a chave do servidor SSH for alterada (por exemplo, devido a uma reconstrução do servidor ou um ataque malicioso), seu cliente SSH detectará esta incompatibilidade e se recusará a conectar.

Para simular isso, vamos modificar intencionalmente a entrada known_hosts para localhost para torná-la inválida.

Primeiro, abra o arquivo ~/.ssh/known_hosts usando nano:

nano ~/.ssh/known_hosts

Você verá várias linhas com diferentes tipos de chaves:

localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHvl7dcZkvMNOr3cjKjlR2/JgFbGpURThT/bHnLZN6gG
localhost ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCynhy3601o9ZSGZoY0KB/QSonk5ykod2Tb7sCAqVn4ZgTCwd96BhPjJLPNQ6ldNASo1e7EzfT4BUjG5T0ZDRhgaI65qmDwITWipTWUfmYT5XoScyf6NDhcRxYiJwztFEkOvLcPhelS6UXj5Z7HdmYH4Nc5wiF00Wah3Jc0/2CfQsFZCXTn/7Kp8KKbBbPqPzr2R3WIULEacOxx9HKVv+2TvYg/OHZz40hTsr1c68DD7h5PMBNe21YB3HLRRk2LQEC7v7BFD+DCek9GNR66JBjbLDljtwWCaPCY0UntBjjvJ3W2LhX5RDZQHV/iaUSj2tEXnvPt9KSqGfBS91D12dBXyOmWVnTpvvI17BdDkEeefas2Uz4d7Bv/PDxZR6IKkaIGQ/ZnRhSEhBNvfqlBGqkOhRr6jQJK+rQMnsZCT6OEgW7osWzkw5Bs1wY/RNToeQqrRMclqffO9plFI688N2iT86+nxrvBVZg4yMMm2J1lleaBvinXCB8jE6lrtwoAdgk=
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKYWY8Ty6TrbQS/0fUljBWuUpkyPCS/5P6ZwxhSYsqjRBIprMANI/JQotZqHYq2w3b2X/n8O+J3/WuIB6XMl1f4=

Escolha uma das linhas para modificar. Neste exemplo, vamos modificar a chave ED25519 (a primeira linha). Modifique alguns caracteres na longa string da chave (por exemplo, altere o último caractere de G para A). Tenha cuidado para não excluir a linha inteira ou outras partes do arquivo.

Por exemplo, altere:
...ZN6gG
para:
...ZN6gA

Salve o arquivo pressionando Ctrl+X, depois Y para confirmar a gravação e Enter para confirmar o nome do arquivo.

Agora, tente se conectar a localhost novamente:

ssh labex@localhost

Você receberá um aviso sobre uma chave de host alterada:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    AVISO: IDENTIFICAÇÃO DO HOST REMOTO ALTERADA!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
É POSSÍVEL QUE ALGUÉM ESTEJA FAZENDO ALGO MALICIOSO!
Alguém pode estar escutando você agora (ataque do homem do meio)!
Também é possível que uma chave de host tenha acabado de ser alterada.
A impressão digital da chave ED25519 enviada pelo host remoto é
SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Por favor, entre em contato com seu administrador de sistema.
Adicione a chave de host correta em /home/labex/.ssh/known_hosts para se livrar desta mensagem.
Chave ofensiva em /home/labex/.ssh/known_hosts:1
A chave de host ED25519 para localhost foi alterada e você solicitou verificação rigorosa.
Falha na verificação da chave de host.

Este é um aviso de segurança crítico. Se você encontrar isso em um cenário do mundo real, investigue por que a chave do host foi alterada. Se for uma alteração legítima (por exemplo, reinstalação do servidor), você precisará remover a entrada antiga de known_hosts.

Para corrigir isso, você pode editar manualmente ~/.ssh/known_hosts e remover a linha problemática, ou usar ssh-keygen -R para remover a entrada para localhost.

Vamos usar ssh-keygen -R para remover a entrada incorreta:

ssh-keygen -R localhost
## Host localhost encontrado: linha 1
## Host localhost encontrado: linha 2
## Host localhost encontrado: linha 3
/home/labex/.ssh/known_hosts atualizado.
Conteúdo original mantido como /home/labex/.ssh/known_hosts.old

Agora, tente se conectar a localhost novamente. Você será solicitado a confirmar a autenticidade do host, assim como na primeira vez que se conectou.

ssh labex@localhost
A autenticidade do host 'localhost (127.0.0.1)' não pode ser estabelecida.
A impressão digital da chave ED25519 é SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Esta chave não é conhecida por nenhum outro nome
Você tem certeza que deseja continuar a conexão (sim/não/[impressão digital])? sim
Aviso: 'localhost' (ED25519) adicionado permanentemente à lista de hosts conhecidos.
Último login: Seg 09 jun 01:40:03 2025 de 127.0.0.1
[labex@host ~]$

Você agora está conectado novamente com sucesso usando autenticação baseada em chave.

Saia da sessão:

exit
exit
Conexão com localhost fechada.
[labex@host ~]$

Personalizar Configurações do Cliente SSH

Neste passo, você aprenderá a personalizar as configurações do seu cliente SSH usando o arquivo ~/.ssh/config. Este arquivo permite definir apelidos e parâmetros de conexão específicos para diferentes hosts remotos, simplificando seus comandos SSH e tornando-os mais consistentes.

O arquivo ~/.ssh/config é uma ferramenta poderosa para gerenciar suas conexões SSH. Você pode especificar várias opções, como o nome de usuário, o arquivo da chave privada a ser usado, a porta e até configurações mais avançadas, como comandos de proxy.

Primeiro, vamos criar ou abrir o arquivo ~/.ssh/config. Se ele não existir, o nano o criará.

nano ~/.ssh/config

Adicione as seguintes configurações ao arquivo. Esta configuração define um apelido localhost_labex para conectar a localhost como o usuário labex, e um apelido localhost_root para conectar como o usuário root. Também especifica explicitamente o IdentityFile para o usuário labex usar a chave id_rsa gerada em um passo anterior.

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Salve o arquivo pressionando Ctrl+X, depois Y para confirmar a gravação e Enter para confirmar o nome do arquivo.

Agora, vamos tentar conectar a localhost usando esses novos apelidos.

Conecte-se como labex usando o apelido localhost_labex:

ssh localhost_labex

Como você configurou IdentityFile ~/.ssh/id_rsa e id_rsa não possui uma senha, você deve ser logado sem ser solicitado a inserir uma senha.

Último login: Seg 09 jun 01:54:16 2025 de 47.251.66.143
[labex@host ~]$

Saia da sessão:

exit
exit
Conexão com localhost fechada.
[labex@host ~]$

Agora, conecte-se como root usando o apelido localhost_root:

ssh localhost_root

Você será solicitado a inserir a senha do usuário root. No entanto, como o login root está desabilitado neste ambiente, você receberá uma mensagem "Permissão negada":

Senha de 'root@localhost':
Permissão negada, tente novamente.
Senha de 'root@localhost':

Pressione Ctrl+C para cancelar a tentativa de conexão:

^C

Isso demonstra que o apelido de configuração SSH funciona, mas a conexão falha devido à política de segurança que desabilita o login root.

Como você pode ver, usar o arquivo ~/.ssh/config simplifica seus comandos SSH pré-configurando parâmetros de conexão comuns.

Vamos adicionar outra entrada para demonstrar a especificação de uma porta diferente. Embora localhost use a porta SSH padrão (22), este exemplo mostra como você a configuraria se fosse diferente.

Abra o arquivo ~/.ssh/config novamente:

nano ~/.ssh/config

Adicione a seguinte entrada. Isso cria um apelido localhost_port_example que define explicitamente a porta como 2222. (Observação: localhost não realmente escuta na porta 2222, então esta conexão falhará, mas demonstra a configuração.)

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Host localhost_port_example
    HostName localhost
    Port 2222
    User labex

Salve o arquivo.

Agora, tente conectar usando o apelido localhost_port_example:

ssh localhost_port_example

Esta conexão falhará porque localhost não está escutando na porta 2222, mas demonstra como especificar uma porta personalizada em sua configuração SSH.

ssh: conectar ao host localhost porta 2222: Não é possível atribuir o endereço solicitado

Você pode encontrar algumas explicações para erros típicos neste link:
            https://red.ht/support_rhel_ssh

Você pode visualizar sua configuração SSH atual para ver todos os hosts definidos:

cat ~/.ssh/config
Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Host localhost_port_example
    HostName localhost
    Port 2222
    User labex

Finalmente, vamos limpar o arquivo ~/.ssh/config removendo a entrada localhost_port_example.

Abra o arquivo ~/.ssh/config:

nano ~/.ssh/config

Exclua o bloco Host localhost_port_example. O arquivo deve ficar assim:

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Salve o arquivo.

Compreendendo a Configuração de Segurança do Servidor OpenSSH

Nesta etapa, você aprenderá sobre as melhores práticas de segurança do servidor OpenSSH examinando a configuração de segurança atual. Você entenderá como as restrições de login do root e as configurações de autenticação de senha funcionam para proteger seu servidor contra acesso não autorizado.

Nota: Neste ambiente de laboratório, você examinará a configuração de segurança SSH atual e entenderá diferentes configurações de segurança. Esta etapa foca em entender essas medidas de segurança e aprender sobre as melhores práticas para a configuração do servidor SSH.

Compreendendo a Segurança do Login do Root

Permitir o login direto do root via SSH geralmente não é recomendado, pois a conta root possui privilégios administrativos completos. Se um invasor obtiver acesso à conta root, ele terá controle total sobre seu sistema. É mais seguro fazer login como um usuário regular e, em seguida, usar sudo para executar tarefas administrativas.

Vamos examinar a configuração atual de login do root e testar sua eficácia.

Primeiro, faça login via SSH como o usuário labex.

ssh labex@localhost

Você deve fazer login sem senha se a configuração da sua chave SSH das etapas anteriores estiver correta.

Last login: Mon Jun  9 01:57:27 2025 from 47.251.66.143
[labex@host ~]$

Agora, vamos examinar o arquivo de configuração do servidor SSH para entender as configurações de segurança atuais:

sudo cat /etc/ssh/sshd_config | grep -E "^PermitRootLogin|^#PermitRootLogin"

Este comando mostrará a configuração atual do PermitRootLogin. Você deverá ver algo como:

PermitRootLogin no

Esta configuração significa que o login direto do root via SSH está desativado, o que é uma melhor prática de segurança.

Vamos testar se o login do root está realmente bloqueado. Primeiro, saia da sessão SSH atual:

exit
exit
Connection to localhost closed.
[labex@host ~]$

Agora, tente fazer login como root em localhost:

ssh root@localhost

Você deverá ver uma mensagem "Permission denied", indicando que o login direto do root não é permitido (isso pode já estar configurado em seu ambiente).

root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:

Isso confirma que o login do root está desativado neste ambiente, o que é a configuração de segurança desejada. A mensagem "Permission denied" demonstra que a medida de segurança está funcionando efetivamente.

Compreendendo a Segurança da Autenticação por Senha

Desativar a autenticação por senha força os usuários a dependerem de métodos mais seguros, como a autenticação baseada em chave SSH. Isso reduz significativamente o risco de ataques de força bruta contra seu servidor.

Vamos examinar a configuração atual de autenticação por senha e entender como ela funciona.

Faça login via SSH como o usuário labex (usando sua chave SSH):

ssh labex@localhost
Last login: Mon Jun  9 01:57:32 2025 from 127.0.0.1
[labex@host ~]$

Primeiro, vamos verificar a configuração atual do PasswordAuthentication:

sudo cat /etc/ssh/sshd_config | grep PasswordAuthentication
PasswordAuthentication yes
## PasswordAuthentication.  Depending on your PAM configuration,
## PAM authentication, then enable this but set PasswordAuthentication

Como você pode ver, PasswordAuthentication yes está configurado atualmente, o que significa que a autenticação por senha está habilitada. Embora isso permita que os usuários se autentiquem com senhas, também apresenta um risco de segurança, pois torna o servidor vulnerável a ataques de força bruta de senhas.

A saída mostra:

  • PasswordAuthentication yes - Esta é a configuração ativa que habilita a autenticação por senha
  • As linhas comentadas fornecem contexto adicional sobre a configuração do PAM

Esta configuração significa que os usuários podem se autenticar usando senhas e chaves SSH. Para segurança aprimorada, é recomendado desativar a autenticação por senha e depender exclusivamente da autenticação baseada em chave SSH.

Saia da sessão atual:

exit
exit
Connection to localhost closed.
[labex@host ~]$

Agora, vamos verificar se a autenticação baseada em chave SSH funciona corretamente enquanto a autenticação por senha está desativada:

ssh labex@localhost

Isso deve ter sucesso sem solicitação de senha, usando sua chave SSH:

Last login: Mon Jun  9 02:00:22 2025 from 127.0.0.1
[labex@host ~]$

Isso demonstra vários conceitos de segurança importantes:

  1. Autenticação por senha está habilitada (PasswordAuthentication yes) - Os usuários podem fazer login com senhas e chaves SSH
  2. Autenticação baseada em chave SSH funciona corretamente - Método de autenticação mais seguro está disponível
  3. O servidor permite ambos os métodos de autenticação - Embora conveniente, isso pode apresentar riscos de segurança de ataques de força bruta
  4. Login do root está desativado - O acesso administrativo requer escalonamento adequado do usuário

Recomendação de Segurança: Para ambientes de produção, considere definir PasswordAuthentication no para aumentar a segurança, forçando os usuários a usar apenas a autenticação baseada em chave SSH.

Saia da sessão:

exit
exit
Connection to localhost closed.
[labex@host ~]$

Você examinou e compreendeu com sucesso a configuração de segurança do servidor OpenSSH. O servidor atualmente tem o login do root desativado (o que segue as melhores práticas de segurança) e a autenticação por senha habilitada (o que oferece flexibilidade, mas pode exigir considerações de segurança adicionais para ambientes de produção). Você também verificou que a autenticação baseada em chave SSH funciona corretamente como um método de autenticação mais seguro.

Resumo

Neste laboratório, os participantes aprenderam a acessar sistemas usando SSH, começando pela verificação da instalação do openssh-clients e conectando-se a localhost via SSH. Eles praticaram a autenticação com senha e compreenderam a verificação inicial de autenticidade do host.

O laboratório guiou os usuários na geração e utilização de pares de chaves SSH para autenticação sem senha, na gestão dessas chaves com ssh-agent e na resolução de problemas comuns de conexão SSH. Finalmente, os participantes aprenderam a personalizar as configurações do cliente SSH e a proteger o servidor OpenSSH desabilitando o login root e a autenticação por senha, aprimorando sua compreensão das práticas de acesso remoto seguro.