Nós exaltamos as virtudes do SSH inúmeras vezes, tanto para segurança quanto para acesso remoto. Vamos dar uma olhada no próprio servidor, alguns aspectos de "manutenção" importantes e algumas peculiaridades que podem adicionar turbulência a um passeio de outra forma tranquilo.
Embora tenhamos escrito este guia com o Linux em mente, isso também pode se aplicar ao OpenSSH no Mac OS X e Windows 7 via Cygwin .
Por que é seguro
Já mencionamos muitas vezes como o SSH é uma ótima maneira de conectar e encapsular dados com segurança de um ponto a outro. Vamos dar uma breve olhada em como as coisas funcionam para que você tenha uma ideia 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. O Telnet e o FTP vêm à mente. Enviamos informações para um servidor remoto e depois obtemos a confirmação de nossa conexão. Para estabelecer algum tipo de segurança, esses protocolos costumam usar combinações de nome de usuário e senha. Isso significa que eles estão totalmente seguros, certo? Errado!
Se pensarmos em nosso processo de conexão como uma correspondência, usar FTP, Telnet e outros não é como usar envelopes de correspondência padrão. É mais como usar cartões postais. Se acontecer de alguém entrar no meio, eles podem ver todas as informações, incluindo os endereços de ambos os correspondentes e o nome de usuário e a senha enviados. Eles podem então mudar a mensagem, mantendo as informações as mesmas, e se passar por um ou outro correspondente. 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 arquivo recebido. 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 o que está ocorrendo no meio.
Agora, vejamos a criptografia SSL, o tipo que torna o HTTP mais seguro. Aqui, temos uma agência de correios que lida com a correspondência, que verifica se o destinatário é quem afirma ser e possui leis que protegem a sua correspondência. É mais seguro no geral, e a autoridade central - a Verisign, para nosso exemplo HTTPS - garante que a pessoa para a qual você está enviando o e-mail faça a verificação. Eles fazem isso não permitindo cartões postais (credenciais não criptografadas); em vez disso, eles exigem envelopes reais.
Finalmente, vamos dar uma olhada no SSH. Aqui, a configuração é um pouco diferente. 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 essa pessoa ao telefone - e está usando uma matemática realmente sofisticada para assinar o seu envelope. Você o entrega a seu irmão, namorada, pai ou filha para levá-lo ao endereço, e apenas se a matemática extravagante do destinatário corresponder, você presume que o endereço é o que deveria ser. Então, você recebe uma carta de volta, também protegido de olhares curiosos por esta 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 presumir que o destinatário original se mudou e precisamos confirmar o endereço novamente.
Com a explicação tão longa, achamos que vamos cortá-la aí. Se você tiver mais informações, fique à vontade para bater um papo nos comentários, é claro. Por enquanto, vamos dar uma olhada no recurso mais relevante do SSH, autenticação de host.
Chaves de host
A autenticação de host é essencialmente a parte em que alguém em quem você confia 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 simplesmente ignorar. Existem algumas coisas importantes a serem tiradas disso, no entanto:
- Como não há autoridade central, a segurança real está na chave do host, nas chaves públicas e nas chaves privadas. (Estas 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 prolixas).
- Se a chave do host for alterada, você provavelmente será alertado e deve 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! Freqüentemente, quando a segurança é uma preocupação, haverá um local especial onde a chave do host (impressão digital ECDSA acima) pode ser confirmada. Em empreendimentos inteiramente online, geralmente será em um site seguro apenas com login. Você pode ter que (ou escolher!) Telefonar para seu 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 pode verificar por si mesmo!
Verificando a chave do host do seu sistema
Existem 4 tipos de algoritmos de criptografia usados para fazer chaves, mas o padrão para OpenSSH no início deste ano é ECDSA ( com algumas boas razões ) Vamos nos concentrar nisso hoje. Este é o comando que você pode executar no servidor SSH ao qual você tem acesso:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Sua saída deve retornar algo assim:
256 ца: 62: еа: щц: еч: яй: 2е: аш: яч: 20: 11: дб: яц: 78: цз: чц /етц/сш/сш_хост_ецдса_кей.пуб
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 fazer login remotamente. Deve corresponder e está tudo pronto. Se não, então outra coisa pode estar acontecendo.
Você pode ver todos os hosts aos quais você se conectou via SSH olhando 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.
Alteração de chaves e problemas do host
Existem alguns motivos pelos quais as chaves do host mudam ou não correspondem ao que está registrado em seu arquivo known_hosts.
- O sistema foi reinstalado / reconfigurado.
- As chaves do host foram alteradas manualmente devido a protocolos de segurança.
- O servidor OpenSSH foi atualizado e está usando padrões diferentes devido a questões de segurança.
- O aluguel de IP ou DNS mudou. Isso geralmente significa que você está tentando acessar um computador diferente.
- O sistema foi comprometido de alguma forma que a chave do host mudou.
Provavelmente, o problema é um dos três primeiros e você pode ignorar a alteração. Se a concessão de IP / DNS mudou, pode haver um problema com o servidor e você pode ser encaminhado para uma máquina diferente. Se você não tem certeza de qual é o motivo da mudança, então você provavelmente deve assumir que é o último da lista.
Como 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 em seu arquivo known_hosts) podem ser de três maneiras.
- StrictHostKeyChecking é definido como nã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ê o alterará novamente.
- StrictHostKeyChecking está configurado para perguntar; O OpenSSH mostrará a você novas chaves de host e pedirá 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]' usuário @ host
Substitua [option] por "não", "pergunte" ou "sim". Esteja ciente de que existem aspas simples em torno desta variável e sua configuração. Substitua também usuário @ host pelo nome de usuário e nome do 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ê estiver tentando acessar um servidor que já teve a 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 inteiramente, completamente, paranóico seguro, seria? Em vez disso, podemos simplesmente remover o valor ofensivo de nosso arquivo known_hosts.
Isso é definitivamente uma coisa feia de se ter na tela. Felizmente, nosso motivo para isso foi a reinstalação do sistema operacional. Então, vamos ampliar a linha de que precisamos.
Aqui vamos nós. Veja como ele cita o arquivo que precisamos editar? Até nos dá o número da linha! Então, vamos abrir esse arquivo no Nano:
Aqui está nossa tecla ofensiva, na linha 1. Tudo o que precisamos fazer é pressionar Ctrl + K para cortar a linha inteira.
Isso é muito melhor! Portanto, agora pressionamos Ctrl + O para escrever (salvar) o arquivo e, em seguida, Ctrl + X para sair.
Agora recebemos um bom prompt, ao qual podemos simplesmente responder com "sim".
Criação de novas chaves de host
Para registro, não há realmente um motivo muito grande para você alterar sua chave de host, mas se você achar necessário, pode fazer isso facilmente.
Primeiro, mude para o diretório de sistema apropriado:
cd / etc / ssh /
Normalmente é onde estão as chaves de host globais, embora algumas distros as tenham 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_ *
Alternativamente, 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, será capaz de sair de situações difíceis. O aviso / erro “Remote Host Identification Has Changed” é algo que afasta muitos usuários, mesmo aqueles que estão familiarizados com a linha de comando.
Para pontos de bônus, você pode verificar Como copiar arquivos remotamente por SSH sem inserir sua senha . Lá, você aprenderá um pouco mais sobre os outros tipos de algoritmos de criptografia e como usar arquivos de chave para aumentar a segurança.
