OpenSSH - Qualquer maneira de manter a verificação da chave do host estrito, mas verificar apenas a chave e ignorar o nome do servidor?

Question

Pergunta

Existe uma maneira de manter o comportamento de verificação da chave de host estrito em , mas verificar apenas a impressão digital da chave do servidor (que já é efetivamente uma identidade exclusiva para o host), sem também considerando o nome do host / IP?

Problema

Tenho vários dispositivos móveis / móveis pessoais: telefones, laptops, mais telefones usados como computadores de bolso etc., e uso o SSH rotineiramente entre eles, usando o endereço IP em vez do nome do host.

Sempre que acabo em uma nova rede (normalmente em casa / escritório / WiFi público de alguém) ou quando as concessões DHCP expiram em uma rede existente, os endereços IP desses dispositivos são embaralhados, causando uma ou ambas as situações a seguir:

1. O host mesmo com uma chave de host inalterada está em um local diferente - portanto ssh me pede para confirmar a mesma chave de host novamente para o novo IP.

2. Um novo host acaba no mesmo IP que um host conectado anteriormente (mas o host anterior também ainda está vivo agora em um IP diferente) - portanto, ao tentar conectar-se ao novo host ssh o trata como o erro bem conhecido que impede a conexão, e consertar o problema requer que eu gerencie vários arquivos de hosts conhecidos com opções de configuração ou perca a associação de chaves de host conhecida para o host anterior.

Eu gostaria de alguma maneira de manter a verificação automática da chave do host, mas no meu caso não faz sentido associar o nome do host / IP ao servidor em si, de modo que:

1. A mesma chave do host exibida para um nome / IP diferente deve ser aceita automaticamente como um host conhecido.

2. Uma chave de host diferente em um endereço IP conhecido anteriormente deve apenas causar o diálogo sim / não para uma nova chave.

Por outras palavras, gostaria que o known_hosts fosse verificado como se fosse apenas uma lista de chaves conhecidas, em vez de uma lista de nomes conhecidos (/ IP) < - > tuplas chave.

Mas, segurança

Apenas antecipando essa tangente:

Não haverá perda real de segurança se eu conseguir que o SSH ignore o nome do host / IP e decida se a chave é nova ou conhecida, porque a chave do host do servidor já é tão segura quanto um identificador exclusivo para o servidor como podemos obter, independentemente do nome / IP em que o servidor está atualmente.

A única diferença no caso de um MitM seria que eu obteria o prompt yes / no em vez da conexão abortar obstinadamente, mas da mesma forma eu imediatamente saberia que algo estava errado, já que eu estaria conectando a um dispositivo cuja chave do host eu espero ser conhecida.

Comentários sobre outras possíveis ideias de solução

O DNS não se aplica, já que estamos falando de mudanças entre redes diferentes e geralmente endereços IP privados da LAN, etc.

/etc/hosts tweaks seria apenas uma dor dada a frequência com que eu poderia mudar de rede.

Eu não uso tecnologias de autodescoberta / autopromoção como mDNS / ZeroConf / Bonjour porque elas adicionam complexidade não negligenciável para configuração, manutenção e auditoria de segurança em alguns desses pequenos dispositivos (em alguns deles eu tenho que compilar tudo o que eu quero usar a partir do código-fonte), e eu geralmente não sou um fã dos meus dispositivos que se anunciam ativamente e constantemente para a rede como um todo.

Uma não-solução manual corrente que eu tenho que, pelo menos, atenua a known_hosts dor é forçar o ssh a usar /dev/null como o arquivo de hosts conhecidos - o que significa que eu sou solicitado a verificar a chave todas as vezes . Mas mesmo com a minha boa memória e arte-chave ASCII para ajudar, isso não escala e quebra a automação, e eu tenho me safado disso apenas porque o número de chaves em jogo é muito pequeno por enquanto.

Eu poderia corrigir ssh para permitir uma opção KeyOnly para verificação de chave de host restrita em vez de apenas "sim" e "não", mas não sei se tenho isso em mim agora, especialmente desde isso significaria que eu teria que conseguir mesclar o upstream ou criar versões do OpenSSH a partir da fonte para mais dispositivos.

Estou tentado a escrever um serviço local que rastreie as chaves de host conhecidas para ssh e crie um soquete de domínio Unix nomeado que ssh possa usar como o arquivo de hosts conhecidos em vez do texto comum normal Arquivo. Isso parece factível, mas requer alguns cuidados para ficar certo e robusto.

Obviamente, desativar a verificação estrita da chave do host não é uma opção. Se eu fosse fazer isso, poderia muito bem usar rsh para não fingir que restava alguma segurança. Nós não somos animais.

Então, eu espero que haja alguma maneira inteligente de fazer esse ajuste no comportamento de verificação de chave do host do OpenSSH para ignorar o IP do nome do host e apenas verificar a chave fora da caixa.

    

Answer 1

Solução

Modifique ou adicione manualmente entradas de host conhecidas para cada chave de host com o nome / campo de IP definido como * .

Explicação

Acontece que há dois detalhes pouco conhecidos do formato de arquivo de hosts conhecidos do OpenSSH (documentado, por algum motivo, na página de manual sshd , em vez da página de manual ssh , sob o SSH_KNOWN_HOSTS_FILE_FORMAT seção), que fornece exatamente o comportamento que eu quero:

1. O OpenSSH permite curingas no campo nome / IP do host , para que vários (ou mesmo todos) hosts correspondam a uma determinada chave pública.

2. O OpenSSH permite mais de uma entrada de host conhecida para o mesmo host e verifica todos eles, de modo que várias chaves de host podem ser consideradas válidas para o mesmo host.

A combinação dessas duas coisas permite que você adicione qualquer número de chaves de host consideradas válidas para qualquer host ao qual você se conecta, aproveitando ao mesmo tempo a verificação rigorosa da chave do host.

Isso funciona se você tem ou não HashKnownHosts ativado - se estiver modificando uma entrada em hash existente, você apenas substituirá o primeiro campo (delimitado por espaço) na entrada. Se você executar ssh-keygen -H você fazer obter um aviso de que as entradas de caractere curinga não podem ser criptografadas, mas tudo bem: o ponto inteiro desse hashing é ocultar os hosts aos quais você se conecta caso o conteúdo do arquivo seja exposto mas um curinga * da mesma forma não revela hosts específicos.

Advertência de segurança

Eu estava errado na minha pergunta para dizer que não há nenhuma perda de segurança. Há um risco adicional pequeno, mas real: Se uma ou mais chaves do host forem consideradas válidas para vários hosts, então, se qualquer dessas chaves do host estiver comprometida, todas de suas conexões pode ser MitMed pela chave comprometida.

Para algumas pessoas, esse será um risco aceitável, que vale a conveniência extra, na conveniência usual versus trade-off de segurança.

Mas com um pouco de configuração extra, isso pode ser reduzido a um nível razoavelmente indolor por ter um arquivo de hosts conhecidos para cada host "roaming", armazenando apenas a entrada de chave de host com caractere curinga do host, um arquivo de configuração para cada aqueles que especificam que os hosts conhecidos arquivam com a opção UserKnownHosts file e especificam esse arquivo de configuração com a opção -F ao se conectar.

    

Answer 2

Você pode escrever um script de shell simples, que gerará um arquivo de host conhecido do usuário personalizado em tempo real e se conectará ao host, conforme necessário.

Consulte a linha de comando ssh especifica a impressão digital da chave do host do servidor .