Como desativar a verificação estrita da chave do host no ssh?


223

Gostaria de desativar o check-in estrito da chave do host no sshUbuntu 11.04. Como fazer isso?


10
Oi karthick87, eu espero que você entenda as implicações de fazer essa mudança de segurança;)
Panther

1
Note-se, no entanto, que você deseja saber se uma chave de host foi alterada . Essa é uma grande bandeira vermelha de que alguém pode estar falsificando o host. Portanto, UserKnownHostFile / dev / null é uma péssima idéia.

4
O SSH é usado não apenas para conexões remotas, você sabe. Todos os hosts aos quais estou me conectando estão na pilha da minha tabela e compartilham o mesmo IP, portanto, sempre tenho o aviso de novo host.
Barafu Albino 10/09

Se você quiser apenas remover a mensagem de um host específico, exclua a linha correspondente ~ / .ssh / known_hosts.
stackexchanger

2
Se você só precisa fazer uma conexão única sem erros:ssh -o UserKnownHostsFile=/dev/null
odinho - Velmont 29/08

Respostas:


227

No seu ~/.ssh/config(se esse arquivo não existir, basta criá-lo):

Host *
    StrictHostKeyChecking no

Isso desativará todos os hosts aos quais você se conecta. É possível substituir o *padrão por um nome de host se você desejar que ele se aplique a alguns hosts.

Verifique se as permissões no arquivo restringem o acesso somente a você:

sudo chmod 400 ~/.ssh/config

1
Não há nenhum arquivo nomeado configno meu diretório pessoal.
karthick87

4
Faça um - todo o conteúdo do arquivo está na minha citação acima. Observe que também está no .sshsubdiretório do seu homedir.
Cesium

O recuo é necessário? Minhas entradas parecem blocos divididos por uma linha vazia.
Andi Giga

4
Isso é imprudente em muitos casos, geralmente você deseja desativá-lo apenas uma vez:ssh -o UserKnownHostsFile=/dev/null
odinho - Velmont 29/08

1
mkdir -p ~ / .ssh && echo "Host *"> ~ / .ssh / config && echo "StrictHostKeyChecking no" >> ~ / .ssh / config
147.3k

189

Em vez de adicioná-lo ao seu ~/.ssh/configarquivo para todos os hosts *, seria mais seguro especificar um host específico.

Você também pode passar um parâmetro na linha de comando como este:

ssh -o StrictHostKeyChecking=no yourHardenedHost.com

Observe que, geralmente, você só precisa fazer isso uma vez por host, uma vez que diz isso pela primeira vez:Warning: Permanently added 'frxxx.blaps.net,10.11.12.13' (RSA) to the list of known hosts.
MarkHu 24/07/2013

24
Isso não vai funcionar. Deve ser em ssh -o UserKnownHostsFile=/dev/nullvez disso.
Qwertzguy

1
@qwertzguy Funciona. Sua opção fará com que a chave do host seja perdida a cada vez, o que é útil e mais seguro, mas não o que a pergunta fazia.
Jon Bentley

@qwertzguy Você poderia adicionar isso como resposta, a sua é realmente a melhor para quick'n'dirty "basta conectar, eu sei o que estou fazendo"? Não queria ninja-roubar sua resposta.
odinho - Velmont 29/08

@ odinho-velmont done
qwertzguy

106

Vale ressaltar essa configuração na sua configuração ssh:

StrictHostKeyChecking no

Significará que as chaves do host ainda são adicionadas ao .ssh / known_hosts - você não será questionado se confia nelas, mas, caso as máquinas mudem, estou disposto a apostar que você receberá um grande aviso sobre isso. Você pode solucionar esse problema adicionando outro parâmetro:

UserKnownHostsFile /dev/null

Isso adicionará todos esses hosts "recém-descobertos" à lixeira. Se uma chave do host mudar, não haverá problemas.

Eu seria negligente em não mencionar que contornar esses avisos nas chaves do host tem implicações óbvias na segurança - você deve tomar cuidado pelas razões certas e pelo qual você está se conectando é o que você deseja se conectar e não um host mal-intencionado, pois nesse momento você corroeu grande parte da segurança no ssh como solução.

Por exemplo, se você tentasse definir isso com a linha de comando, o comando completo seria:

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

Isso seria tolo - dado que os exemplos de trabalho acima para arquivos de configuração ssh provavelmente farão mais sentido em todos os casos.


1
Você está correto, você começa a grande aviso
Freedom_Ben

1
Eu acho que essa é a resposta certa. Isso funciona bem para conectar-se a hosts em uma rede local privada.
21415 Steve Steve

4
Pode ser conveniente ter um alias para ssh -o StrictHostKeyChecking=no -o UserKnownHostFiles=/dev/null user@host. No meu caso, eu uso isshpara conectar-me a hosts nos quais sei que a chave do host é alterada.
Ecerulm # /

1
@ecerulm - apenas um pequeno erro de digitação: é UserKnownHostsFilenão UserKnownHostFiles.
Grey Panther

20

PARA SUA INFORMAÇÃO. Prefiro desativar a verificação de host apenas ao usar o cssh.

alias cssh='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'

csshou ssh?
kenorb

Talvez ele usa cssh.sourceforge.net
MarkHu

Estou errado ou o segundo é -odesnecessário?
Yckart

1
alias relay='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null 11086695@172.26.19.19 -p 2222'trabalhar para mim
arganzheng

9

Se você deseja desativar uma vez, use:

ssh -o UserKnownHostsFile=/dev/null

Isso funcionará também se a chave do host for alterada e garantirá que a chave não seja salva como confiável para maior segurança.


6

Pelo que parece ,

NoHostAuthenticationForLocalhost yes

pode ser bom o suficiente para você. E você ainda seria capaz de manter essa aparência de segurança.


2

https://askubuntu.com/a/87452/129227 sugerem modificar o arquivo de configuração que ajuda. Mas, em vez de abrir as coisas para qualquer host, eu queria que isso fosse feito por host. O script abaixo ajuda a automatizar o processo:

chamada de exemplo

./schcheck somedomain site1 site2 site3

script sshcheck

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    ;;
esac
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.