Questão Não adicione hostkey a known_hosts para SSH


Quero me conectar a um host via SSH, mas não quero que o nome do host seja adicionado ao meu ~/.ssh/known_hosts.

Como eu posso fazer isso?


93


origem




Respostas:


Se você quiser esse comportamento porque está trabalhando com servidores em nuvem (AWS EC2, Rackspace CloudServers etc.) ou está constantemente provisionando novas imagens no Vagrant, convém atualizar sua configuração de SSH em vez de adicionar aliases de bash ou mais opções linha de comando.

Considere adicionar algo como:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET
  • Use tão restrito quanto regex para o host quanto possível para ser seguro.
  • Configurar o LogLevel para QUIET manterá o aviso que Guillaume mencionou ao aparecer

81



Você realmente deve tentar não desabilitar totalmente o StrictHostKeyChecking, então a resposta do cclark é um grande compromisso para trabalhar com servidores em nuvem. - Alex Recarey
Isso se mostrou muito útil para mim quando eu estava usando o Shipit (uma ferramenta de implantação de JavaScript) contra o Vagrant. Eu não poderia facilmente chegar aos parâmetros que o Shipit estava passando para o SSH, então isso me permitiu contornar a ferramenta e dizer o que eu fiz e não queria que ela lembrasse. - John Munsch
LogLevel é o que eu estava procurando. Tem a vantagem adicional de não mostrar o aviso configurado da empresa ao executar scripts! (Eu estou correndo agora w / loglevel ERROR) - Anshu Prateek
Em qual arquivo eu adiciono isso? - Wim Deblauwe
Este é o seu arquivo de configuração SSH. No Linux ou macOS, o arquivo geralmente estaria em um diretório chamado .ssh dentro do seu diretório home e chamado config - ~ / .ssh / config - cclark


-o "UserKnownHostsFile /dev/null"

Deveria trabalhar.


75



Funciona como planejado, mas sempre relatará: "Aviso: permanentemente adicionado 'hostname, ip' (RSA) à lista de hosts conhecidos." Eu fiz isso com 2: & 1 | grep -v "^Warning: Permanently added" - Guillaume Boudreau
Isso é o que eu precisava para o meu cenário - sem DNS, LAN com DHCP, computadores recebendo endereços diferentes o tempo todo. Vou precisar digitar "sim" o tempo todo, mas por outro lado é ótimo. - Tomasz Gandor
add -o "LogLevel ERROR" e não vai mais reclamar com avisos - John
Nota: uma solicitação para suprimir a mensagem "Aviso: permanentemente adicionado 'hostname, ip' (RSA) à lista de hosts conhecidos." foi relatado aos mantenedores bugzilla.mindrot.org/show_bug.cgi?id=2413 - Ben Creasy
Tubulação para grep irá mesclar stdout e stderr; também o status de saída pode mudar. Se estiver usando bash, será melhor usar a substituição do processo para se livrar da mensagem: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Isso evitará o cano e, portanto, as alterações correspondentes no manuseio do status de saída. - Alex O


Eu sinto como adicionar a chave de host ao seu known_hosts (as pessoas que executam esses serviços são, pelo menos na minha experiência, inteligentes o suficiente para manter suas chaves de host consistentes entre as máquinas que atendem ao mesmo hostname) e ativando o StrictHostKeyChecking, desligando o CheckHostIP e o registro em log com o LogLevel ERROR proporcionará a melhor experiência sem sacrificar a segurança. (Ok, sem o CheckHostIP você precisa confiar no DNS, que é um grande buraco sem DNSSEC ou algo parecido; mas vamos varrer isso para baixo do tapete por enquanto.)

Eu uso um arquivo known_hosts somente leitura, então eu tenho que fazer alguma coisa ou recebo avisos intermináveis ​​sobre não poder adicionar entradas a known_hosts.

O que eu uso:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

Eu gostaria que esses serviços publiquem suas chaves de host SSH em seus sites via HTTPS, para que eu possa copiá-los explicitamente sem ter que me conectar primeiro e potencialmente me expor a um ataque MITM.


8





Eu sugiro

LogLevel ERROR

sobre

LogLevel QUIET

então você ainda recebe "Não foi possível resolver o nome do host" e outros erros


4



você deve ser capaz de confiar em suas conexões SSH, imho. Não apenas faça silêncio sobre seus riscos. - sylvainulg
Depende mesmo. Temos ambientes de desenvolvimento que são demolidos a cada semana e reconstruídos, seus registros A permanecem os mesmos, mas a chave do host é gerada sempre que é criada. Não podemos persistir as chaves do host porque o registro A é definido apenas em um banco de dados baseado em um nome de ambiente, e os nomes de ambiente podem ser descartados ou novos criados a qualquer momento, portanto a solução acima é genuinamente útil. - Alex Berry


Para uma única sessão ssh, use este

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

3



Isso não acrescenta nada de novo a uma resposta aceita em uma pergunta que tem 5 anos de idade. - JakeGould


Você já tentou desativar StrictHostKeyChecking? Você pode fazer isso com o -o opção ou no arquivo de configuração ~/.ssh/config.


2



Eu já estou usando isso. Mas isso tem um efeito diferente: diminui o rigor da verificação da chave do host. Ou seja quando o host é desconhecido, ele ainda se conecta quando você desativa essa opção. Assim, ainda salva o host. Mas acho que encontrei a solução certa (veja minha resposta). - Albert


Eu encontrei as seguintes entradas .ssh / config úteis (LAN com DHCP e DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

O resultado é que os nomes das máquinas locais "zora" ou "goron" não verificarão os endereços IP designados dinamicamente, mas www.mycompany.com ou node42.planetlab.com ainda terão seus IPs estáticos confirmados.


0