Je souhaite désactiver l'enregistrement strict de la clé d'hôte ssh pour Ubuntu 11.04. Comment faire?
Dans votre ~/.ssh/config (si ce fichier n'existe pas, il suffit de le créer):
Host * StrictHostKeyChecking noCela le désactivera pour tous les hôtes auxquels vous vous connectez. Vous pouvez remplacer le * avec un modèle de nom d'hôte si vous souhaitez qu'il ne s'applique qu'à certains hôtes.
Assurez-vous que les autorisations sur le fichier restreignent l'accès à vous-même uniquement:
sudo chmod 400 ~/.ssh/configPlutôt que de l'ajouter à votre ~/.ssh/config fichier pour tous les hôtes *, il serait plus sûr de spécifier un hôte particulier.
Vous pouvez également passer un paramètre sur la ligne de commande comme ceci:
ssh -o StrictHostKeyChecking=no yourHardenedHost.comCela ajoutera automatiquement la clé d'hôte à votre fichier known_hosts si elle n'est pas déjà là.
S'il y a une incompatibilité, il affichera un grand avertissement et ne mettra pas à jour known_hosts. Il désactivera également l'authentification par mot de passe pour empêcher les attaques MITM. L'authentification par clé privée passera toujours automatiquement, ce que vous ne voudrez peut-être pas.
Cela vaut la peine de souligner ce paramètre dans votre configuration ssh:
StrictHostKeyChecking noCela signifie que les clés d'hôte sont toujours ajoutées à .ssh / known_hosts - vous ne serez tout simplement pas invité à savoir si vous leur faites confiance, mais si les hôtes changent, je suis prêt à parier que vous obtiendrez le grand avertissement à ce sujet. Vous pouvez contourner ce problème en ajoutant un autre paramètre:
UserKnownHostsFile /dev/nullCela ajoutera tous ces hôtes "nouvellement découverts" à la corbeille. Si une clé hôte change, aucun problème.
Je m'en voudrais de ne pas mentionner que le contournement de ces avertissements sur les clés d'hôte a des ramifications évidentes en matière de sécurité - vous devez faire attention à ce que vous le fassiez pour les bonnes raisons et à ce à quoi vous vous connectez réellement être ce que vous voulez dire se connecter à et non à un hôte malveillant, car à ce stade, vous avez érodé une grande partie de la sécurité de ssh en tant que solution.
Par exemple, si vous deviez essayer de le définir avec la ligne de commande, la commande complète serait:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@hostCe serait idiot cependant-étant donné que les exemples de travail ci-dessus pour les fichiers de configuration ssh sont susceptibles d'avoir plus de sens dans tous les cas.
Pour info. Je préfère désactiver la vérification de l'hôte uniquement lors de l'utilisation de cssh.
alias cssh='ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'Si vous souhaitez désactiver sur une base unique, utilisez:
ssh -o UserKnownHostsFile=/dev/nullCela fonctionnera également si la clé de l'hôte change et s'assurera de ne pas enregistrer la clé comme approuvée pour plus de sécurité.
De ce qu'il on dirait,
NoHostAuthenticationForLocalhost yespeut être assez bien, pour toi. ET vous seriez toujours en mesure de maintenir ce semblant de sécurité.
https://askubuntu.com/a/87452/129227 suggérer de modifier le fichier de configuration qui aide. Mais au lieu d'ouvrir les choses à n'importe quel hôte, je voulais que cela soit fait par hôte. Le script ci-dessous aide à automatiser le processus:
exemple d'appel
./ 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.htmlblue='\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 displayerror() { 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" fidone}## 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/configcase $# in 0) usage ;; 1) usage ;; *) domain=$1 shift color_msg $blue "checking ssh configuration for domain $domain sites $*" checkconfig checkservers $* ;;esacSalut karthick87, j’espère que vous comprenez les implications de sécurité de ce changement 
SSH n’est pas seulement utilisé pour les connexions à distance, vous savez. Tous les hôtes auxquels je me connecte sont en tas sur ma table et partagent la même adresse IP, donc j’ai toujours l’avertissement du nouvel hôte.
Si vous avez juste besoin de faire une connexion unique sans erreur: 'ssh-o UserKnownHostsFile= / dev / null`
Il convient toutefois de noter que vous * * voulez * * savoir si une clé d’hôte a changé. C’est un gros drapeau rouge que quelqu’un peut usurper l’hôte. Donc UserKnownHostFile / dev / null est une très mauvaise idée.
Si vous souhaitez simplement supprimer le message pour un hôte particulier, supprimez la ligne correspondante~/.ssh / known_hosts.
Merci @odinho-Velmont, j’avais besoin de le faire lors du tunneling inverse de plusieurs hôtes différents vers le même port local (un à la fois, bien sûr). Sans cela, le serveur se plaint lors de la connexion en utilisant les mêmes informations d’identification aux différents serveurs.
Bien sûr, il y a des raisons valables à cette question, mais l’avertissement bien visible aide à protéger les gens lorsqu’ils accèdent à cette page pour la mauvaise raison.