Tutorial de Ubuntu 26.04 / Configure OpenSSH e teste a autenticação por chave

Configure as chaves SSH verificando a porta em escuta no servidor, registrando apenas a chave pública do cliente e testando uma nova conexão. Restrinja a autenticação por senha somente depois que o login por chave e o acesso administrativo funcionarem, mantendo a sessão e o console existentes disponíveis.

Inspecione o serviço, o socket e o endereço

sudo apt update
sudo apt install openssh-server
systemctl status ssh.socket ssh.service --no-pager
sudo ss -lntp
ip -br address

Inspecione a porta e o endereço em escuta juntamente com ssh.socket e ssh.service. Mantenha a porta SSH existente. Com a configuração NAT mais host-only na lição de criação da VM, o servidor é .20 e o cliente Linux é .10; execute os comandos de chave nesse cliente. Uma unidade inativa pode ser normal dependendo da ativação do socket.

O guia do OpenSSH do Ubuntu explica instalação, precedência de configuração e validação.

No cliente Linux, execute command -v ssh e command -v ssh-copy-id. Se necessário, instale o openssh-client com sudo apt update && sudo apt install openssh-client. Substitua pelo nome de usuário comum criado durante a instalação e estabeleça um login inicial autorizado ou rota de console antes de registrar a chave pública. Não enfraqueça a autenticação de produção apenas para o exercício.

Verifique a identidade do servidor e crie uma chave de cliente

No console do servidor, inspecione a impressão digital da chave do host com sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub e compare-a, por um canal confiável, com a impressão digital apresentada pelo cliente na primeira conexão. Confirme que o algoritmo da impressão apresentada é o mesmo; se for diferente, obtenha a impressão correspondente no console. Execute os seguintes comandos de geração e cópia no cliente Linux, não no servidor.

ssh-keygen -t ed25519 -f "$HOME/.ssh/ubuntu-lab-ed25519"
ssh-copy-id -i "$HOME/.ssh/ubuntu-lab-ed25519.pub" labuser@192.168.56.20

Substitua labuser e o endereço por valores reais, e não sobrescreva um arquivo de chave existente. Defina e proteja uma frase-senha. Transfira apenas a chave pública .pub; nunca copie a chave privada para o servidor. O exemplo de cópia assume Linux, pois as ferramentas padrão de SSH do Windows podem omitir ssh-copy-id.

Teste uma nova conexão usando apenas a chave

ssh -i "$HOME/.ssh/ubuntu-lab-ed25519" -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -o PasswordAuthentication=no labuser@192.168.56.20

Um prompt de frase-senha de chave privada é diferente de um prompt de senha de conta do servidor. Após a conexão, verifique whoami e o acesso necessário sudo. Em caso de falha, inspecione a conta, o proprietário e as permissões do diretório pessoal e dos arquivos SSH, e os logs do servidor; não os torne graváveis por todos.

Valide a política de autenticação pretendida

Em um novo servidor de laboratório destinado especificamente à autenticação por chave única, faça backup da configuração do SSH e revise um arquivo separado, como /etc/ssh/sshd_config.d/00-lab-auth.conf. Não aplique a política abaixo sem alterações em um servidor com MFA existente ou autenticação organizacional.

PubkeyAuthentication yes
AuthenticationMethods publickey
PasswordAuthentication no
PermitRootLogin no

O OpenSSH usa o primeiro valor lido para muitas opções; inspecione a configuração efetiva em vez de confiar em um nome de arquivo. As regras Match exigem avaliação com as condições reais do usuário e do cliente através do sshd -T -C. Aplique esta política de laboratório apenas após a verificação do login por chave privada.

sudo sshd -t
sudo sshd -T | grep -E '^(pubkeyauthentication|authenticationmethods|passwordauthentication|permitrootlogin) '

Aplique, reinicie e recupere na ordem

Após a validação de sintaxe bem-sucedida, recarregue as configurações de autenticação com sudo systemctl reload ssh.service quando o serviço estiver realmente em execução. Este exercício não altera portas. Alterações de Port ou ListenAddress com ativação por socket exigem revisar separadamente a geração de soquetes e o comportamento de recarga do daemon.

Antes de fechar a sessão antiga, teste uma nova conexão com a chave, o acesso sudo e a rejeição de autenticação indesejada. Repita após uma reinicialização planejada. Se falhar, restaure apenas a configuração alterada através do console, valide e aplique. Investigue avisos de alteração da chave do host em vez de apagar automaticamente os registros de confiança.