Não adicione a chave do host ao known

111

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?

ssh hosts

— Albert
fonte

99

-o "UserKnownHostsFile /dev/null"

Deveria trabalhar.

— Albert
fonte

3

Funciona como pretendido, mas sempre reportará: "Aviso: Adicionado permanentemente 'hostname, ip' (RSA) à lista de hosts conhecidos". Eu fiz isso ir embora com: 2> & 1 | grep -v "^Warning: Permanently added"

— Guillaume Boudreau

3

adicione -o "LogLevel ERROR" e ele não se queixará mais dos avisos

— John

1

Nota: uma solicitação para suprimir a mensagem "Aviso: adicionado permanentemente 'hostname, ip' (RSA) à lista de hosts conhecidos". foi relatado aos mantenedores bugzilla.mindrot.org/show_bug.cgi?id=2413

— Ben Creasy

2

A tubulação para grepmesclar stdout e stderr; também o status de saída pode mudar. Se estiver usando bash, será melhor usar substituição processo para se livrar da mensagem: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. Isso evitará o tubo e, portanto, as alterações correspondentes no manuseio do status de saída.

— Alex O

1

@John É melhor usar um dos outros métodos nesses comentários, caso contrário, você está apresentando uma falha de segurança devido ao potencial de ocultar outros avisos não relacionados

— Jon Bentley

97

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

Considere adicionar algo como:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET

Use o mais estrito possível como regex para que o host seja possível.
Definir o LogLevel como QUIET manterá o aviso mencionado por Guillaume de aparecer

— cclark
fonte

Você realmente deve tentar não desativar completamente o StrictHostKeyChecking, para que a resposta do cclark seja um ótimo compromisso para trabalhar com servidores em nuvem.

— Alex Recarey

Isso me mostrou muito útil, pois eu estava usando o Shipit (uma ferramenta de implantação de JavaScript) no Vagrant. Eu não conseguia facilmente chegar aos parâmetros que o Shipit estava passando para o SSH, então isso me permitiu desviar da ferramenta e contar o que eu fiz e não queria que ela se lembrasse.

— John Munsch

1

LogLevel é o que eu estava procurando. Tem a vantagem adicional de não mostrar o aviso configurado pela empresa ao executar scripts! (Estou executando o erro agora w / loglevel)

— Anshu Prateek

Em que arquivo eu adiciono isso?

— Wim Deblauwe

Este é o seu arquivo de configuração SSH. No Linux ou MacOS o arquivo geralmente seria em um diretório chamado .ssh dentro do seu diretório home e nomeado config - ~ / .ssh / config

— cclark

8

Sinto vontade de adicionar a chave do host ao seu known_hosts (na minha experiência, as pessoas que executam esses serviços são pelo menos inteligentes o suficiente para manter as chaves do host consistentes entre máquinas que servem o mesmo nome de host) e depois ativar StrictHostKeyChecking, desativar o CheckHostIP e o registro com o LogLevel ERROR fornecerá a melhor experiência sem sacrificar a segurança. (Ok, sem o CheckHostIP, você precisa confiar no DNS, que é um enorme buraco sem DNSSEC generalizado ou algo semelhante; mas vamos varrer isso para debaixo do tapete por enquanto.)

Eu uso um arquivo known_hosts somente leitura, então 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

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

— Kyle Rose
fonte

7

Para uma única sessão ssh, use este

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

— Quanlong
fonte

4

Isso não adiciona nada de novo a uma resposta aceita em uma pergunta com 5 anos de idade.

— JakeGould

5

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 desse tipo

— kiloforce
fonte

você deve poder confiar nas suas conexões SSH, imho. Não apenas faça silêncio sobre seus riscos.

— sylvainulg

3

Depende mesmo. Temos ambientes de desenvolvimento que são destruídos a cada semana e reconstruídos, os registros A permanecem os mesmos, mas a chave do host é gerada toda vez que é criada. Não podemos persistir as chaves do host porque o registro A é definido apenas em um banco de dados com base em um nome de ambiente, e os nomes de ambiente podem ser descartados ou novos, a qualquer momento, portanto, a solução alternativa acima é realmente útil.

— Alex Berry

2

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

— jneves
fonte

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

— Albert

0

Eu achei 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 serão comparados com endereços IP atribuídos dinamicamente, mas www.mycompany.com ou node42.planetlab.com ainda terão seus IPs estáticos confirmados.

— sylvainulg
fonte

Não adicione a chave do host ao known_hosts para SSH