Embora tenhamos escrito este guia com o Linux em mente, isso também pode se aplicar ao OpenSSH no Mac OS X e no Windows 7 por meio do Cygwin.
Por que é seguro
Mencionamos muitas vezes como o SSH é uma ótima maneira de se conectar e encapsular dados de forma segura de um ponto para outro. Vamos dar uma breve olhada em como as coisas funcionam, para que você possa ter uma ideia melhor de por que as coisas podem ficar estranhas às vezes.
Se pensarmos em nosso processo de conexão como e-mail, usar FTP, Telnet e afins não é como usar envelopes de correspondência padrão. É mais como usar cartões postais. Se alguém passar pelo meio, ele poderá ver todas as informações, incluindo os endereços dos dois correspondentes e o nome de usuário e a senha enviados. Eles podem, então, alterar a mensagem, mantendo as informações iguais e representar um correspondente ou outro. Isso é conhecido como um ataque “man-in-the-middle”, e não apenas compromete sua conta, mas questiona toda e qualquer mensagem enviada e arquivo recebido. Você não pode ter certeza se está falando com o remetente ou não, e, mesmo que esteja, não pode ter certeza de que ninguém está olhando para tudo.
Agora, vamos ver a criptografia SSL, o tipo que torna o HTTP mais seguro. Aqui, temos uma agência postal que lida com a correspondência, que verifica se o destinatário é quem ele diz ser e tem leis que protegem sua correspondência. No geral, a segurança é mais segura, e a autoridade central - a Verisign é uma delas, para nosso exemplo de HTTPS - garante que a pessoa para quem você está enviando e-mails seja enviada. Eles fazem isso não permitindo cartões postais (credenciais não criptografadas); em vez disso, exigem envelopes reais.
Com a explicação, enquanto for, pensamos que vamos cortar lá. Se você tiver mais insight, fique à vontade para conversar nos comentários, é claro. Por enquanto, vamos analisar o recurso mais relevante do SSH, a autenticação do host.
Chaves do Host
A autenticação do host é essencialmente a parte em que alguém da sua confiança pega o envelope (selado com matemática mágica) e confirma o endereço do destinatário. É uma descrição bem detalhada do endereço, e é baseado em algumas contas complicadas que apenas pularemos. Há algumas coisas importantes para tirar disso, porém:
- Como não há autoridade central, a segurança real está na chave do host, nas chaves públicas e nas chaves privadas. (Essas duas últimas chaves são configuradas quando você recebe acesso ao sistema.)
- Normalmente, quando você se conecta a outro computador via SSH, a chave do host é armazenada. Isso torna as ações futuras mais rápidas (ou menos detalhadas).
- Se a chave do host mudar, você provavelmente será alertado e deverá ser cauteloso!
Como a chave do host é usada antes da autenticação para estabelecer a identidade do servidor SSH, você deve verificar a chave antes de se conectar. Você verá uma caixa de diálogo de confirmação como abaixo.
Como verificar a chave do host do seu sistema
Existem 4 tipos de tipos de algoritmos de criptografia usados para fazer chaves, mas o padrão para o OpenSSH no início deste ano é o ECDSA (com algumas boas razões). Vamos nos concentrar nisso hoje.Este é o comando que você pode executar no servidor SSH a que você tem acesso:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Sua saída deve retornar algo assim:
256 ca:62:ea:7c:e4:9e:2e:a6:94:20:11:db:9c:78:c3:4c /etc/ssh/ssh_host_ecdsa_key.pub
O primeiro número é o comprimento de bits da chave, depois é a chave em si e, finalmente, você tem o arquivo no qual ela está armazenada. Compare essa parte do meio com o que vê quando você é solicitado a efetuar login remotamente. Deve corresponder e está tudo pronto. Se não, então algo mais poderia estar acontecendo.
Você pode visualizar todos os hosts aos quais você se conectou via SSH, observando seu arquivo known_hosts. Geralmente está localizado em:
~/.ssh/known_hosts
Você pode abrir isso em qualquer editor de texto. Se você olhar, tente prestar atenção em como as chaves são armazenadas. Eles são armazenados com o nome do computador host (ou endereço da web) e seu endereço IP.
Alterando Chaves e Problemas do Host
Existem alguns motivos pelos quais as chaves do host mudam ou não correspondem ao que está registrado no arquivo known_hosts.
- O sistema foi reinstalado / reconfigurado.
- As chaves do host foram alteradas manualmente devido a protocolos de segurança.
- O servidor OpenSSH atualizou e está usando padrões diferentes devido a problemas de segurança.
- A concessão de IP ou DNS foi alterada. Isso geralmente significa que você está tentando acessar um computador diferente.
- O sistema foi comprometido de alguma forma, de modo que a chave do host foi alterada.
Provavelmente, o problema é um dos três primeiros e você pode ignorar a mudança. Se a concessão de IP / DNS for alterada, poderá haver um problema com o servidor e você poderá ser roteado para uma máquina diferente. Se você não tem certeza do motivo da mudança, provavelmente deve assumir que é o último da lista.
Como o OpenSSH lida com hosts desconhecidos
Dependendo da sua configuração, as conexões SSH com hosts desconhecidos (cujas chaves ainda não estão no arquivo known_hosts) podem ser de três maneiras.
- StrictHostKeyChecking está definido como não; O OpenSSH se conectará automaticamente a qualquer servidor SSH, independentemente do status da chave do host. Isso é inseguro e não é recomendado, exceto se você estiver adicionando vários hosts após a reinstalação do sistema operacional. Depois disso, você o alterará novamente.
- StrictHostKeyChecking está definido para perguntar; O OpenSSH mostrará a você novas chaves de host e solicitará confirmação antes de adicioná-las. Isso impedirá que as conexões acessem as chaves do host alteradas. Este é o padrão.
- StrictHostKeyChecking está definido como sim; O oposto de "não", isso impedirá que você se conecte a qualquer host que ainda não esteja presente em seu arquivo known_hosts.
Você pode alterar essa variável facilmente na linha de comando usando o seguinte paradigma:
ssh -o 'StrictHostKeyChecking [option]' user@host
Substitua [opção] por “não”, “perguntar” ou “sim”. Esteja ciente de que há cotações simples em torno desta variável e sua configuração. Substitua também user @ host pelo nome de usuário e host do servidor ao qual você está se conectando. Por exemplo:
ssh -o 'StrictHostKeyChecking ask' [email protected]
Hosts bloqueados devido a chaves alteradas
Se você tem um servidor que está tentando acessar e que já tinha sua chave alterada, a configuração padrão do OpenSSH impedirá que você o acesse. Você poderia alterar o valor de StrictHostKeyChecking para esse host, mas isso não seria totalmente, completamente seguro, paranóico, seria? Em vez disso, podemos simplesmente remover o valor ofensivo do nosso arquivo known_hosts.
Agora recebemos um bom aviso, ao qual podemos simplesmente responder com "sim".
Criando Novas Chaves do Host
Só para constar, não há muita razão para você alterar sua chave de host, mas se você encontrar a necessidade, poderá fazê-lo facilmente.
Primeiro, mude para o diretório do sistema apropriado:
cd /etc/ssh/
Este é normalmente o lugar onde estão as chaves globais do host, embora algumas distribuições as tenham colocado em outro lugar. Em caso de dúvida, verifique sua documentação!
Em seguida, excluiremos todas as chaves antigas.
sudo rm /etc/ssh/ssh_host_*
Como alternativa, você pode querer movê-los para um diretório de backup seguro. Apenas um pensamento!
Então, podemos dizer ao servidor OpenSSH para se reconfigurar:
sudo dpkg-reconfigure openssh-server
Você verá um prompt enquanto seu computador cria suas novas chaves. Ta-da!
Agora que você sabe como o SSH funciona um pouco melhor, você deve ser capaz de sair de situações difíceis. O aviso / erro "Identificação do host remoto foi alterado" é algo que desativa muitos usuários, mesmo aqueles que estão familiarizados com a linha de comando.
Para pontos de bônus, você pode conferir como copiar remotamente arquivos através de SSH sem inserir sua senha. Lá, você aprenderá um pouco mais sobre os outros tipos de algoritmos de criptografia e sobre como usar arquivos de chave para aumentar a segurança.
