Aprenda os detalhes do OpenSSH no seu PC Linux

Nós enaltecemos as virtudes do SSH inúmeras vezes, tanto para segurança quanto para acesso remoto. Vamos dar uma olhada no servidor em si, alguns aspectos importantes de "manutenção" e algumas peculiaridades que podem adicionar turbulência a um passeio suave.

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 via Cygwin.

Por que é seguro

Mencionamos muitas vezes como o SSH é uma ótima maneira de conectar e encapsular dados com segurança de um ponto para outro. Vamos dar uma breve olhada em como as coisas funcionam, então você tem uma idéia melhor de por que as coisas podem ficar estranhas, às vezes.

Quando decidimos iniciar uma conexão com outro computador, geralmente usamos protocolos fáceis de trabalhar. Telnet e FTP vêm à mente. Enviamos as informações para um servidor remoto e, em seguida, recebemos a confirmação da nossa conexão. Para estabelecer algum tipo de segurança, esses protocolos geralmente usam combinações de nome de usuário e senha. Isso significa que eles são totalmente seguros, certo? Errado!

Se pensarmos em nosso processo de conexão como e-mail, usar FTP e 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, 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 também questiona toda e qualquer mensagem enviada e recebida. Você não pode ter certeza se está falando com o remetente ou não, e mesmo se estiver, não pode ter certeza de que ninguém está olhando para tudo de entre.

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. É mais seguro em geral, e a autoridade central - a Verisign é uma, 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.

Finalmente, vamos dar uma olhada no SSH. Aqui, a configuração é um pouco diferente. Nós não temos um autenticador central aqui, mas as coisas ainda estão seguras. Isso é porque você está enviando cartas para alguém cujo endereço você já conhece - digamos, conversando com eles ao telefone - e você está usando uma matemática muito chique para assinar seu envelope. Você o entrega ao seu irmão, namorada, pai ou filha para levá-lo para o endereço, e somente se os jogos de matemática extravagante do destinatário você assumir que o endereço é o que deveria ser. Então, você recebe uma carta de volta, também protegida de olhos curiosos por essa matemática incrível. Finalmente, você envia suas credenciais em outro envelope secreto encantado por algoritmos para o destino. Se a matemática não corresponder, podemos supor que o destinatário original foi movido e precisamos confirmar seu endereço novamente.

Com a explicação contanto que seja, achamos que vamos cortá-la lá. Se você tiver mais insight, fique à vontade para conversar nos comentários, é claro. Por enquanto, porém, vamos ver 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 é baseada em alguma matemática complicada que vamos pular. Há algumas coisas importantes a 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.

Você não deve se preocupar, no entanto! Muitas vezes, quando a segurança é uma preocupação, haverá um lugar especial em que a chave do host (impressão digital do ECDSA acima) pode ser confirmada. Em empreendimentos totalmente on-line, muitas vezes, ele estará em um site seguro de login. Você pode ter que (ou optar por!) Ligar para o departamento de TI para confirmar essa chave pelo telefone. Já ouvi falar de alguns lugares onde a chave está no seu crachá de trabalho ou na lista especial de “números de emergência”. E, se você tiver acesso físico à máquina de destino, também poderá verificar você mesmo!

Verificando 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. Aqui está 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 como isto:

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 própria chave e, finalmente, você tem o arquivo no qual ela está armazenada. Compare essa parte do meio com o que você vê quando é solicitado a efetuar login remotamente. Deve coincidir e está tudo pronto. Se isso não acontecer, 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ê observar, 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 algumas razões pelas 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 atualizado e está usando diferentes padrões 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 mudou.

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

O OpenSSH tem uma configuração de como ele lida com hosts desconhecidos, refletido na variável "StrictHostKeyChecking" (sem aspas).

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 um monte de hosts após a reinstalação do seu sistema operacional, após o qual você irá alterá-lo de volta.
StrictHostKeyChecking está definido para perguntar; O OpenSSH lhe mostrará novas chaves de host e solicitará confirmação antes de adicioná-las. Ele 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 [opção]' usuário @ 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 perguntar' [email protected]

Hosts bloqueados devido a chaves alteradas

Se você tem um servidor que está tentando acessar e que já teve sua chave alterada, a configuração padrão do OpenSSH impedirá que você o acesse. Você poderia alterar o valor de StrictHostKeyChecking para aquele 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.

Isso é definitivamente uma coisa feia para se ter em sua tela. Felizmente, nossa razão para isso foi um sistema operacional reinstalado. Então, vamos ampliar a linha que precisamos.

Aqui vamos nós. Veja como cita o arquivo que precisamos editar? Até nos dá o número da linha! Então, vamos abrir esse arquivo no Nano:

Aqui está a nossa chave ofensiva, na linha 1. Tudo o que precisamos fazer é pressionar Ctrl + K para cortar toda a linha.

Isso é muito melhor! Então, agora pressionamos Ctrl + O para gravar (salvar) o arquivo, depois Ctrl + X para sair.

Agora recebemos um bom aviso, ao qual podemos simplesmente responder com "sim".

Criando Novas Chaves do Host

Para o registro, não há realmente muita razão para você mudar sua chave de host, mas se você alguma vez encontrar a necessidade, você pode fazer facilmente.

Primeiro, mude para o diretório do sistema apropriado:

cd / etc / ssh /

Geralmente é 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, vamos excluir 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 aviso 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.