Come disabilitare il controllo rigoroso della chiave host in ssh?


223

Vorrei disabilitare il controllo rigoroso della chiave host sshper Ubuntu 11.04. Come farlo?


10
Ciao karthick87, spero che tu capisca le implicazioni di sicurezza di fare quel cambiamento;)
Pantera

1
Va notato, tuttavia, che si desidera sapere se una chiave host è stata modificata . Questa è una grande bandiera rossa che qualcuno potrebbe falsificare l'host. Quindi UserKnownHostFile / dev / null è una pessima idea.

4
Sai, SSH non viene utilizzato solo per le connessioni remote. Tutti gli host a cui mi sto connettendo sono in heap sul mio tavolo e condividono lo stesso IP, quindi ho sempre il nuovo avviso host.
Barafu Albino,

Se desideri solo rimuovere il messaggio per un determinato host, elimina la riga corrispondente ~ / .ssh / known_hosts.
stackexchanger

2
Se devi solo effettuare una connessione singola senza errori:ssh -o UserKnownHostsFile=/dev/null
odinho - Velmont,

Risposte:


227

Nel tuo ~/.ssh/config(se questo file non esiste, crealo):

Host *
    StrictHostKeyChecking no

Questo lo disattiverà per tutti gli host a cui ti connetti. È possibile sostituire il *modello con un nome host se si desidera che si applichi solo ad alcuni host.

Assicurati che le autorizzazioni sul file limitino l'accesso solo a te stesso:

sudo chmod 400 ~/.ssh/config

1
Non ci sono file nominati confignella mia directory home.
karthick87,

4
Creane uno - l'intero contenuto del file è nella mia citazione sopra. Nota che si trova anche nella .sshsottodirectory del tuo homedir.
Cesio

È richiesto il rientro? Le mie voci sembrano blocchi divisi da una riga vuota.
Andi Giga,

4
Questo non è saggio in molti casi, spesso vuoi solo disabilitarlo una volta:ssh -o UserKnownHostsFile=/dev/null
odinho - Velmont

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

189

Invece di aggiungerlo al tuo ~/.ssh/configfile per tutti gli host *, sarebbe più sicuro specificare un determinato host.

Puoi anche passare un parametro dalla riga di comando in questo modo:

ssh -o StrictHostKeyChecking=no yourHardenedHost.com

Si noti che in genere è necessario eseguire questa operazione una sola volta per host poiché lo dice la prima volta:Warning: Permanently added 'frxxx.blaps.net,10.11.12.13' (RSA) to the list of known hosts.
MarkHu

24
Non funzionerà Dovrebbe essere ssh -o UserKnownHostsFile=/dev/nullinvece.
qwertzguy,

1
@qwertzguy Funziona. La tua opzione farà in modo che la chiave host venga persa ogni volta, il che è utile e più sicuro, ma non quello che la domanda ha posto.
Jon Bentley,

@qwertzguy Potresti aggiungere questo come risposta, il tuo è davvero il migliore per quick'n'dirty "connettiti, so cosa sto facendo"? Non volevo che il ninja rubasse la tua risposta.
odinho - Velmont,

@ odinho-velmont done
qwertzguy,

106

Vale la pena sottolineare questa impostazione nella tua configurazione SSH:

StrictHostKeyChecking no

Significa che le hostkey vengono ancora aggiunte a .ssh / known_hosts - semplicemente non ti verrà chiesto se ti fidi di loro, ma se gli host cambiano, sono disposto a scommettere che riceverai il grande avviso a riguardo. È possibile aggirare questo problema aggiungendo un altro parametro:

UserKnownHostsFile /dev/null

Ciò aggiungerà tutti questi host "appena scoperti" al cestino. Se una chiave host cambia, nessun problema.

Non vorrei dimenticare che eludere questi avvisi sulle hostkeys ha evidenti implicazioni di sicurezza: dovresti stare attento a farlo per le giuste ragioni e che ciò a cui ti stai connettendo in realtà è ciò che intendi connettere e non un host dannoso, poiché a questo punto hai eroso gran parte della sicurezza in ssh come soluzione.

Ad esempio, se dovessi provare a impostarlo con la riga di comando, il comando completo sarebbe:

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

Sarebbe sciocco però - dato che gli esempi di lavoro sopra per i file di configurazione ssh avranno probabilmente più senso in tutti i casi.


1
Hai ragione, ricevi il grosso avvertimento
Freedom_Ben

1
Penso che questa sia la risposta giusta. Funziona bene per la connessione agli host su una rete locale privata.
Steve Davis

4
Potrebbe essere conveniente avere un alias ssh -o StrictHostKeyChecking=no -o UserKnownHostFiles=/dev/null user@host. Nel mio caso, mi isshcollego agli host in cui so che la chiave dell'host cambia.
ecerulm

1
@ecerulm - solo un piccolo errore di battitura: non lo UserKnownHostsFileè UserKnownHostFiles.
Pantera grigia il

20

PER TUA INFORMAZIONE. Preferisco disabilitare il controllo host solo quando si usa cssh.

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

cssho ssh?
Kenorb,


Sbaglio o il secondo -onon è necessario?
yckart,

1
alias relay='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null 11086695@172.26.19.19 -p 2222'lavoro per me
arganzheng

9

Se vuoi disabilitare una volta sola usa:

ssh -o UserKnownHostsFile=/dev/null

Funzionerà anche se la chiave host cambia e farà in modo di non salvare la chiave come attendibile per una maggiore sicurezza.


6

Da quello che sembra ,

NoHostAuthenticationForLocalhost yes

potrebbe essere abbastanza buono, per te. E saresti ancora in grado di mantenere quella parvenza di sicurezza.


2

https://askubuntu.com/a/87452/129227 suggerisce di modificare il file di configurazione che aiuta. Ma invece di aprire le cose per qualsiasi host, volevo che fosse fatto per host. Lo script seguente aiuta ad automatizzare il processo:

chiamata di esempio

./sshcheck 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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.