Introdução
Neste laboratório, você ganhará experiência prática na configuração e proteção de conexões SSH, uma habilidade fundamental para gerenciar sistemas Linux remotos. Você começará aprendendo como acessar sistemas remotos usando SSH, compreendendo a arquitetura cliente-servidor e os comandos básicos de conexão. Isso inclui verificar a instalação do cliente SSH, conectar-se a um host remoto, lidar com avisos de autenticidade do host e realizar login e logout em sistemas remotos.
Com base nessa fundação, você explorará tópicos mais avançados, como a geração e utilização de pares de chaves SSH para autenticação sem senha, o gerenciamento eficaz dessas chaves com o ssh-agent e a solução de problemas comuns de conexão SSH. Por fim, você aprenderá a personalizar as configurações do cliente SSH para melhorar a eficiência e aumentar a segurança do seu servidor OpenSSH, desativando o login root e a autenticação por senha, garantindo um acesso remoto robusto e seguro.
Acessar sistemas remotos com SSH
Nesta etapa, você aprenderá como acessar sistemas remotos usando SSH (Secure Shell). O SSH é um protocolo de rede criptográfico para operar serviços de rede de forma segura sobre uma rede não segura. Ele fornece um canal seguro através de uma rede não segura usando uma arquitetura cliente-servidor, conectando um cliente SSH a um servidor SSH.
Nota: 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.
Antes de se conectar a sistemas remotos, prepare seu ambiente de laboratório instalando os pacotes do cliente e servidor OpenSSH e iniciando o serviço SSH. O SSH usa uma arquitetura cliente-servidor: o cliente (ssh) inicia as conexões e o servidor (sshd) as aceita. Você também instalará o nano, que usará posteriormente para editar arquivos de configuração do SSH.
Execute o seguinte comando para instalar os pacotes necessários. O sinalizador -y confirma automaticamente as solicitações de instalação de pacotes:
sudo dnf install -y openssh-clients openssh-server nano
Inicie o serviço SSH e configure-o para iniciar automaticamente na inicialização:
sudo systemctl start sshd
sudo systemctl enable sshd
Verifique se o serviço SSH está em execução:
sudo systemctl status sshd
Você deverá ver Active: active (running) na saída. Pressione q para sair da visualização de status.
Primeiro, você se conectará ao sistema local usando SSH. Isso demonstra a arquitetura cliente-servidor do SSH mesmo ao se conectar à mesma máquina. Você usará o comando ssh para se conectar ao localhost.
A sintaxe básica para o 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 nos conectar ao localhost usando seu nome de usuário atual:
ssh localhost
Ao se conectar pela primeira vez, o SSH solicitará que você confirme a autenticidade do host. Esta é uma medida de segurança para evitar ataques de homem-no-meio (man-in-the-middle). Digite yes e pressione Enter.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
labex@localhost's password:
Você será solicitado a inserir a senha do usuário labex. Digite labex e pressione Enter.
labex@localhost's password:
Last login: Mon Jun 9 01:34:39 2025 from 47.251.66.143
[labex@host ~]$
Agora você está logado via SSH no 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
Connection to localhost closed.
[labex@host ~]$
Agora, vamos tentar nos conectar ao localhost como usuário root. Observe que, neste ambiente, o login root pode estar desativado 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 de "Permission denied" se o login root estiver desativado:
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Se o login root estiver desativado, este é o comportamento esperado e demonstra uma prática recomendada 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 no localhost como usuário labex:
ssh labex@localhost hostname
Você será solicitado a inserir a senha do usuário labex. Digite labex e pressione Enter.
labex@localhost's password:
6846375f1c0e35fea6cb03e6
[labex@host ~]$
O comando hostname foi executado via SSH e sua saída foi exibida no seu terminal local. Você não foi levado a um shell interativo.
Por fim, vamos explorar como o SSH gerencia hosts conhecidos. Quando você se conecta a um novo servidor SSH, a impressão digital (fingerprint) 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+nxrvBVZg4yMMm2J1lleaBvinXCB8jE6lrtwoAdgk=
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKYWY8Ty6TrbQS/0fUljBWuUpkyPCS/5P6ZwxhSYsqjRBIprMANI/JQotZqHYq2w3b2X/n8O+J3/WuIB6XMl1f4=
Essas 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 qualquer uma dessas chaves do servidor mudar inesperadamente, o SSH irá avisá-lo, o que é um recurso de segurança crucial.
Gerar e usar pares de chaves SSH para autenticação sem senha
Nesta etapa, você aprenderá como gerar pares de chaves SSH e usá-los para autenticação sem senha. A autenticação baseada em chave SSH é uma alternativa mais segura e conveniente à autenticação por senha. Em vez de digitar uma senha toda vez que você se conecta, você usa um par de chaves criptográficas: uma chave privada (mantida em segredo na 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, 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 escolher algumas opções:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/labex/.ssh/id_rsa):
Pressione Enter para aceitar o caminho de arquivo padrão (/home/labex/.ssh/id_rsa).
Enter passphrase (empty for no passphrase):
Para este laboratório, pressione Enter duas vezes para deixar a senha (passphrase) vazia. Embora o uso de uma senha seja recomendado para cenários do mundo real para adicionar uma camada extra de segurança, vamos ignorá-la aqui por simplicidade e para demonstrar a autenticação sem senha diretamente.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/labex/.ssh/id_rsa
Your public key has been saved in /home/labex/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[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/gravação apenas 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 no localhost como labex sem fornecer uma senha:
ssh labex@localhost
Se tudo estiver configurado corretamente, você deverá estar logado via SSH sem ser solicitado a inserir uma senha.
Last login: Mon Jun 9 01:37:39 2025 from 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
Connection to localhost closed.
[labex@host ~]$
Gerenciar chaves SSH com ssh-agent
Nesta etapa, você aprenderá como gerenciar suas chaves SSH usando o 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 senha (passphrase). Em vez de digitar a senha toda vez que você usa a chave, você a digita uma vez ao adicionar a chave ao ssh-agent, e então o agente lida com a autenticação para você durante a duração da sua sessão.
Embora você tenha gerado uma chave sem senha na etapa anterior, agora criaremos uma nova chave com uma senha para demonstrar a utilidade do ssh-agent.
Primeiro, gere um novo par de chaves SSH com uma senha. Nomearemos esta chave como id_rsa_passphrase para distingui-la da chave id_rsa padrão.
ssh-keygen -f ~/.ssh/id_rsa_passphrase
Você será solicitado a inserir uma senha. Para este laboratório, use mypassphrase como senha.
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): mypassphrase
Enter same passphrase again: mypassphrase
Your identification has been saved in /home/labex/.ssh/id_rsa_passphrase
Your public key has been saved in /home/labex/.ssh/id_rsa_passphrase.pub
The key fingerprint is:
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[RSA 3072]----+
| ...=o+=*. E |
| .o.*.=..+ o |
| .=.o o. = . |
| . .+... .. . .|
| . . . +S. + |
| . o ..o . o * .|
| . . . . = * |
| oooo|
| ..+.o|
+----[SHA256]-----+
Nota: Se você pressionar Enter acidentalmente sem digitar uma senha, a chave será criada sem uma. Nesse caso, você pode excluir os arquivos e executar o comando novamente, certificando-se de inserir mypassphrase quando solicitado.
Agora, vamos copiar esta nova chave pública para o 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 a 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 ao localhost usando esta nova chave. Você precisará especificar o arquivo de chave privada usando a opção -i.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Se você definiu uma senha para a chave, será solicitado que você a insira. No entanto, se você criou a chave acidentalmente sem uma senha (como mostrado na saída de exemplo), você será logado diretamente:
Last login: Mon Jun 9 01:39:25 2025 from 47.251.66.143
[labex@host ~]$
Você está logado. Agora, saia da sessão:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Nota: Se sua chave não tiver uma senha, você ainda pode continuar com a demonstração do ssh-agent para entender como ele funciona, mesmo que ele não solicite uma senha neste caso.
Primeiro, inicie o ssh-agent na 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 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 ao 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 senha (tenha sua chave uma senha ou não, já que agora ela é gerenciada pelo agente):
Last login: Mon Jun 9 01:39:49 2025 from 127.0.0.1
[labex@host ~]$
Você usou com sucesso o ssh-agent para gerenciar sua chave SSH.
Nota 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 de volta para o seu shell local para usar os comandos ssh-add.
Saia da sessão SSH primeiro:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Agora, para ver as chaves carregadas atualmente no 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 "Could not open a connection to your authentication agent", significa que as variáveis de ambiente do agente não estão definidas na sua sessão atual.
Para remover todas as identidades do ssh-agent, use ssh-add -D:
ssh-add -D
Se o agente estiver acessível, você verá:
All identities removed.
No entanto, se você vir "Could not open a connection to your authentication agent", significa que o ambiente do agente não está disponível na sua sessão atual.
Agora, se você tentar se conectar novamente e sua chave tiver uma 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 senha, você verá:
Enter passphrase for key '/home/labex/.ssh/id_rsa_passphrase':
Se sua chave não tiver uma senha, você ainda poderá se conectar diretamente. Pressione Ctrl+C para cancelar a tentativa de conexão se for solicitado a inserir uma senha.
Por fim, para interromper 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ê pode ver:
SSH_AGENT_PID not set, cannot kill agent
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
Nesta etapa, você aprenderá como solucionar problemas comuns de conexão SSH. Quando as conexões SSH falham, pode ser difícil identificar o problema exato. O comando ssh fornece opções de saída detalhadas (verbose) 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 verbosidade: -v, -vv e -vvv. Cada v adicional aumenta a quantidade de informações de depuração exibidas.
Vamos começar tentando nos conectar a uma porta inexistente no localhost para demonstrar a falha de conexão e ver a saída de depuração.
Primeiro, tente com -v (verbose) para se 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: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 2222.
ssh: connect to host localhost port 2222: Connection refused
Agora, vamos tentar com -vv (mais verbose):
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: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused
Por fim, tente com -vvv (mais verbose possível):
ssh -vvv -p 2222 labex@localhost
Este nível fornece a quantidade máxima de informações de depuração, o que pode ser esmagador, mas extremamente útil para problemas complexos.
OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug3: ssh_connect_internal: entering
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused
Neste caso, o erro Connection refused indica claramente que não há servidor SSH rodando na porta 2222.
Agora, vamos simular um problema comum: uma chave de host alterada. Na primeira etapa, você se conectou ao localhost e sua impressão digital de chave pública foi adicionada ao seu arquivo ~/.ssh/known_hosts. Se a chave do servidor SSH mudasse (por exemplo, devido a uma reinstalação do servidor ou um ataque malicioso), seu cliente SSH detectaria essa incompatibilidade e se recusaria a conectar.
Para simular isso, modificaremos intencionalmente a entrada known_hosts para localhost para torná-la inválida.
Primeiro, abra o arquivo ~/.ssh/known_hosts usando o nano:
nano ~/.ssh/known_hosts
Você verá várias linhas com diferentes tipos de chave:
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. Para este 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 o salvamento e Enter para confirmar o nome do arquivo.
Agora, tente se conectar ao localhost novamente:
ssh labex@localhost
Você receberá um aviso sobre uma chave de host alterada:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Please contact your system administrator.
Add correct host key in /home/labex/.ssh/known_hosts to get rid of this message.
Offending key in /home/labex/.ssh/known_hosts:1
ED25519 host key for localhost has changed and you have requested strict checking.
Host key verification failed.
Este é um aviso de segurança crítico. Se você encontrar isso em um cenário do mundo real, deve investigar por que a chave do host mudou. Se for uma alteração legítima (por exemplo, reinstalação do servidor), você precisa remover a entrada antiga de known_hosts.
Para corrigir isso, você pode editar manualmente ~/.ssh/known_hosts e remover a linha ofensiva, 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 found: line 1
## Host localhost found: line 2
## Host localhost found: line 3
/home/labex/.ssh/known_hosts updated.
Original contents retained as /home/labex/.ssh/known_hosts.old
Agora, tente se conectar ao localhost novamente. Você será solicitado a confirmar a autenticidade do host, exatamente como na primeira vez que se conectou.
ssh labex@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Last login: Mon Jun 9 01:40:03 2025 from 127.0.0.1
[labex@host ~]$
Agora você está conectado novamente com sucesso usando autenticação baseada em chave.
Saia da sessão:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Personalizar configurações do cliente SSH
Nesta etapa, você aprenderá como personalizar as configurações do seu cliente SSH usando o arquivo ~/.ssh/config. Este arquivo permite definir aliases 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 de chave privada a ser usado, o número da 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 a seguinte configuração ao arquivo. Esta configuração define um alias localhost_labex para se conectar ao localhost como usuário labex, e um alias localhost_root para se conectar como usuário root. Ele também especifica explicitamente o IdentityFile para o usuário labex usar a chave id_rsa gerada em uma etapa 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 o salvamento e Enter para confirmar o nome do arquivo.
Agora, vamos tentar nos conectar ao localhost usando esses novos aliases.
Conecte-se como labex usando o alias 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.
Last login: Mon Jun 9 01:54:16 2025 from 47.251.66.143
[labex@host ~]$
Saia da sessão:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Agora, conecte-se como root usando o alias localhost_root:
ssh localhost_root
Você será solicitado a inserir a senha do usuário root. No entanto, como o login root está desativado neste ambiente, você receberá uma mensagem de "Permission denied":
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Pressione Ctrl+C para cancelar a tentativa de conexão:
^C
Isso demonstra que o alias de configuração SSH funciona, mas a conexão falha devido à política de segurança que desativa 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 o 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 alias localhost_port_example que define explicitamente a porta como 2222. (Nota: o localhost não 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 se conectar usando o alias localhost_port_example:
ssh localhost_port_example
Esta conexão falhará porque o localhost não está escutando na porta 2222, mas demonstra como especificar uma porta personalizada na sua configuração SSH.
ssh: connect to host localhost port 2222: Cannot assign requested address
You can find some explanations for typical errors at this 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
Por fim, 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.
Compreender 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 root e as configurações de autenticação por 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 compreender essas medidas de segurança e aprender sobre as melhores práticas para a configuração do servidor SSH.
Compreender a segurança do login root
Permitir o login root direto via SSH é geralmente desencorajado porque a conta root tem privilégios administrativos totais. Se um invasor obtiver acesso à conta root, ele terá controle total sobre seu sistema. É mais seguro fazer login como um usuário comum e, em seguida, usar sudo para realizar tarefas administrativas.
Vamos examinar a configuração atual de login root e testar sua eficácia.
Primeiro, faça login via SSH como usuário labex.
ssh labex@localhost
Você deve fazer login sem senha se sua configuração de 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 de PermitRootLogin. Você deve ver algo como:
PermitRootLogin no
Essa configuração significa que o login root direto via SSH está desativado, o que é uma prática recomendada de segurança.
Vamos testar se o login 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 no localhost:
ssh root@localhost
Você deve ver uma mensagem de "Permission denied", indicando que o login root direto não é permitido (isso pode já estar configurado no seu ambiente).
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
Isso confirma que o login root está desativado neste ambiente, que é a configuração de segurança desejada. A mensagem "Permission denied" demonstra que a medida de segurança está funcionando efetivamente.
Compreender a segurança da autenticação por senha
Desativar a autenticação por senha força os usuários a depender 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 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 de 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á ativada. 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 senha.
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 PAM
Essa configuração significa que os usuários podem se autenticar usando senhas e chaves SSH. Para maior segurança, recomenda-se desativar a autenticação por senha e confiar apenas na autenticação baseada em chave SSH.
Saia da sessão SSH 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 uma 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 importantes de segurança:
- A autenticação por senha está ativada (
PasswordAuthentication yes) - Os usuários podem fazer login com senhas e chaves SSH - A autenticação baseada em chave SSH funciona corretamente - Método de autenticação mais seguro está disponível
- O servidor permite ambos os métodos de autenticação - Embora conveniente, isso pode representar riscos de segurança de ataques de força bruta
- O login root está desativado - O acesso administrativo requer a escalada de usuário adequada
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 root desativado (o que segue as melhores práticas de segurança) e a autenticação por senha ativada (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 ao localhost via SSH. Eles praticaram a autenticação com senha e entenderam a verificação inicial de autenticidade do host.
O laboratório guiou ainda mais os usuários através da geração e utilização de pares de chaves SSH para autenticação sem senha, gerenciamento dessas chaves com ssh-agent e solução de problemas comuns de conexão SSH. Por fim, os participantes aprenderam a personalizar as configurações do cliente SSH e proteger o servidor OpenSSH desativando o login root e a autenticação por senha, aprimorando sua compreensão das práticas de acesso remoto seguro.
