Todos que usam o SSH sabem que, na primeira vez em que se conectam ao servidor, aparece uma mensagem confirmando a impressão digital da chave. Além disso, a chave é armazenada no lado do cliente e essa mensagem não é exibida novamente até que a chave salva seja alterada. Mas qual é o significado prático desse procedimento?Na vida real, quase ninguém verifica a impressão digital da chave SSH do servidor sem pensar na possibilidade de ataques MiTM. Com o advento do registro DNS SSHFP, a impressão digital da chave do servidor pode ser armazenada no DNS e autenticada usando DNSSEC. Nesse caso, você nem precisa confirmar a chave na primeira conexão. Este artigo mostra como configurar um registro SSHFP para o servidor SSH.Servidor de teste
Primeiro, precisamos de um servidor.No painel RuVDS, os detalhes para o acesso SSH estão localizados imediatamente na placa do servidor. Nós salvamos o endereço IP e a senha da conexão.
Você também pode configurar o firewall diretamente no painel de controle para permitir o acesso SSH apenas para o seu IP.Para configurar o SSHFP, um domínio deve ser direcionado ao endereço IP do servidor; configuraremos os registros DNS para esse domínio.Como as chaves funcionam no SSH
Nos exemplos, consideraremos apenas o pacote OpenSSH, pois essa é a opção mais popular.Ao instalar um novo servidor, chaves SSH aleatórias são geradas, geralmente isso acontece imediatamente ao instalar o pacote OpenSSH ou durante a primeira inicialização se forem usadas imagens de sistema prontas.Os arquivos principais estão localizados aqui:$ ls -la /etc/ssh/ssh_host_*_key*
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub
Nesta lista, existem várias chaves de tipos diferentes ao mesmo tempo: dsa, rsa, ecdsa, ed25519. Isso é feito para compatibilidade com diferentes clientes SSH. No estágio de conexão, o cliente e o servidor concordam com qual algoritmo de chave será usado. O cliente pode solicitar ao servidor que use um algoritmo diferente se o proposto não for suportado. O servidor envia a parte pública de sua chave ao cliente e o usuário é solicitado a verificar sua impressão digital manualmente.
O servidor envia a impressão digital da chave pública para o cliente no momento da conexão.Seesta é a primeira conexão, uma mensagem será exibida ao cliente com a solicitação para verificar manualmente a impressão digital:The authenticity of host 'example.com (123.45.67.89)' can't be established.
ECDSA key fingerprint is SHA256:7Q4nIqjuo/lSXWFkt9RaJYVHrT6LUAc6KWrdQ4/DDeA.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Nesse estágio, todos geralmente clicamos em Sim sem hesitar e a impressão digital da chave é salva em um arquivo ~/.ssh/known_hosts. Agora, se a chave no servidor mudar, o cliente receberá uma mensagem sobre um possível ataque ao MiTM. Supõe-se que, pela primeira vez, o cliente executou uma verificação de chave por conta própria e garantiu sua autenticidade.Essa abordagem é bastante arriscada, porque se o invasor conseguir aproveitar o momento da primeira conexão, ele poderá deslizar sua chave e interceptar a conexão. No caso de c HTTPS, temos um terceiro que confirma a chave do servidor com um certificado. Se a mesma abordagem usada no SSH fosse usada na Web, seríamos constantemente atormentados por mensagens de verificação de chave e os ataques MiTM estariam por toda parte, porque ninguém verificaria as chaves, mas simplesmente concordaria sempre.Armazenamos uma impressão de chave no DNS. O que são entradas SSHFP
Como descobrir que a chave SSH proposta pelo servidor é realmente real e isso não é um ataque MiTM? De fato, para entrar no servidor e verificar a chave, você deve primeiro digitar a senha. Mas o invasor poderá invadir instantaneamente o servidor e substituir todos os dados nele, tanto que não perceberemos a captura. Portanto, precisamos de uma maneira de verificar a autenticidade da chave ANTES da conexão real.Por um longo tempo, a única maneira de verificar a chave SSH do servidor antes de conectar era usar outro canal, por exemplo, peça ao administrador do servidor para fornecer a impressão digital da chave do servidor. Isso é inconveniente, por isso é mais fácil ignorar o problema e sempre concordar sem hesitar.
O SSHFP permite a autenticação da chave do servidor antes de conectar-se através do DNS doSSHFP- tipo de registros DNS para armazenar chaves SSH. A impressão digital da chave SSH é colocada no servidor DNS como um registro TXT e assinada com a chave DNSSEC. Ou seja, ao conectar-se ao servidor pela primeira vez usando o nome do host, o cliente poderá conhecer antecipadamente a impressão digital da chave do servidor via DNS e, se corresponder ao servidor proposto, conecte-se sem aviso prévio .Configurar DNSSEC
Para usar o SSHFP, você precisa de um nome de domínio com o DNSSEC configurado. Existem muitos serviços DNS públicos que oferecem um painel de controle DNS imediatamente com a função DNSSEC. O serviço mais popular é o CloudFlare. Considere a configuração usando seu exemplo. Para as etapas a seguir, o domínio deve ser delegado ao servidor Cloudflare NS.1Etapa 1 - gere uma chave
Vá para o painel DNS -> Ativar DNSSEC.Nestemomento, serão geradas chaves para assinar sua zona de domínio. Você verá as chaves públicas. Eles precisarão ser adicionados ao lado do registrador de domínio.Etapa 2 - adicionando chaves públicas ao registrador
Em seguida, você precisa criar registros do DS que contenham a chave pública do registrador de domínio.Dependendo do seu registrador, a interface de adição de chave DNSSEC pode parecer diferente. É importante não confundir os valores, pois eles podem ter nomes diferentes e diferir dos nomes mostrados no CloudFlare.O exemplo abaixo mostra como os valores mostrados no painel CloudFlare se relacionam com os valores no painel de controle do domínio do registrador Uniregistry.
3Etapa 3 - verifique os registros DS adicionados
Depois de adicionar registros DS ao lado do registrador, você pode verificar se as configurações estão corretas. No lado do CloudFlare, a assinatura dos registros DNS será ativada apenas quando a verificação da correção da adição de registros DS no lado do registrador for aprovada.
Aguardando a adição de registros do DSApós alguns minutos ou horas, se os registros foram adicionados corretamente, você verá essa mensagem. Isso significa que as respostas DNS agora são assinadas usando DNSSEC.
4Etapa 4 - verifique a operação DNSSEC
Agora você pode testar a operação do DNSSEC em nosso domínio usando serviços online como dnssec-analyzer.verisignlabs.com . Todas as marcas de seleção devem estar verdes.
Resultado da validação DNSSECAdicionando entradas SSHFP
Geraremos registros SSHFP no servidor. Em nosso exemplo, estamos administrando um servidor com o endereço myserver.com . Para esse nome de domínio, configuramos o DNSSEC anteriormente.No servidor, execute o comando:
sudo ssh-keygen -r myserver.com
myserver.com IN SSHFP 1 1 057ecce168ace29d5a0099e3b63df2850e4c8e20
myserver.com IN SSHFP 1 2 52cd6099a304b9b8f57f2cd914e96a1b7477eb2f88c98c602
myserver.com IN SSHFP 2 1 42d677482e4450ee515d3aac94d96302a99bd4ec
myserver.com IN SSHFP 2 2 edda5fa445dc0da570c772a6df0d4012037e1a102840d29c4
...
Impressões digitais serão geradas para todas as chaves da pasta / etc / ssh / . Você pode gerar seletivamente impressões digitais para chaves específicas especificando o caminho do arquivo.Agora todos esses registros precisam ser adicionados no painel DNS, no nosso caso, o Cloudflare.
Adicionando um registro SSHFP ao painel CloudflarePortanto, você precisa adicionar todas as chaves obtidas na etapa anterior. Agora você pode verificar se as chaves foram adicionadas:dig SSHFP myserver.com
Na resposta, você deve ver todas as chaves adicionadas. Pode levar algum tempo para assinar novas entradas, portanto, as chaves na resposta podem não aparecer imediatamente. Isso geralmente não leva mais de 10 a 15 minutos.Conecte-se ao servidor
Para que o cliente SSH verifique a validade das chaves através do DNS, é necessário adicionar habilitar isso nas configurações. A configuração do cliente está localizada na pasta inicial do usuário. Adicione uma linha lá.
vi ~/.ssh/config
VerifyHostKeyDNS yes
Agora você pode se conectar ao servidor. Para a pureza do experimento, você pode remover a linha com a impressão digital de ~ / .ssh / known_hosts . Para maior clareza, você pode adicionar a opção -v
ssh -v root@myserver.com
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
.....
DNS lookup error: data does not exist
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_rsa_verify: signature correct
Se tudo estiver configurado corretamente, na primeira vez em que você se conectar ao servidor, não será solicitado que você verifique manualmente a impressão digital da chave. Isso também requer que o resolvedor DNS do sistema suporte a validação DNSSEC.É importante lembrar que o SSHFP funcionará apenas quando conectado a um servidor por nome de domínio e não funcionará quando conectado por IP ou outro domínio que não possua registros SSHFP.