Comment éviter que SSH demande sa permission?


59

Nous essayons d'accélérer l'installation des nœuds Oracle pour l'installation de RAC. ssh doit être installé et configuré de manière à ne pas demander de mot de passe.

Le problème est le suivant: lors de la première utilisation, nous sommes invités à

RSA key fingerprint is 96:a9:23:5c:cc:d1:0a:d4:70:22:93:e9:9e:1e:74:2f.
Are you sure you want to continue connecting (yes/no)? yes

Y a-t-il un moyen d'éviter cela ou sommes-nous condamnés à nous connecter manuellement au moins une fois sur chaque serveur?

Réponses:


92

Définissez StrictHostKeyChecking nodans votre /etc/ssh/ssh_configfichier, où ce sera une option globale utilisée par tous les utilisateurs du serveur. Ou définissez-le dans votre ~/.ssh/configfichier, où ce sera la valeur par défaut pour l'utilisateur actuel uniquement. Ou vous pouvez l'utiliser sur la ligne de commande:

ssh -o StrictHostKeyChecking=no -l "$user" "$host"

Voici une explication de la façon dont cela fonctionne man ssh_config (ou voir cette version plus récente ):

StrictHostKeyChecking

      Si cet indicateur est défini sur «yes», ssh n’ajoutera jamais automatiquement de clé d’hôte au $HOME/.ssh/known_hostsfichier et refuse de se connecter aux hôtes dont la clé d’hôte a changé. Ceci fournit une protection maximale contre les attaques de chevaux de Troie, mais peut être gênant lorsque le /etc/ssh/ssh_known_hostsfichier est mal géré ou que des connexions à de nouveaux hôtes sont fréquemment établies. Cette option oblige l'utilisateur à ajouter manuellement tous les nouveaux hôtes. Si cet indicateur est défini sur «non», sshajoutera automatiquement de nouvelles clés d’hôte aux fichiers hôtes connus de l’utilisateur. Si cet indicateur est défini sur «ask», les nouvelles clés d’hôte seront ajoutées aux fichiers d’hôte connus de l’utilisateur uniquement après que celui-ci aura confirmé ce qu’il souhaite vraiment faire, et ssh refusera de se connecter aux hôtes dont la clé d’hôte a changé. . Les clés d'hôtes des hôtes connus seront vérifiées automatiquement dans tous les cas. L'argument doit être «oui», «non» ou «demander». La valeur par défaut est "demander".


1
+1, j'ai aussi ceci pour mes serveurs. Et juste pour être clair, le message dans la question provient du client ssh sur l'ordinateur client se connectant et non du serveur.
Patkos Csaba

3
Cette réponse ressemble à un problème de sécurité en gestation.
SunSparc

25

ssh-keyscan - Rassemblez les clés publiques ssh

Si vous connaissez déjà la liste des hôtes auxquels vous allez vous connecter, vous pouvez simplement émettre:

ssh-keyscan host1 host2 host3 host4

Vous pouvez donner l' -Hoption de hacher les résultats comme ssh par défaut

Vous pouvez aussi donner -t keytypeété keytype est dsa, rsaou ecdsasi vous avez une préférence quant à quel type de clé pour saisir au lieu de la valeur par défaut.

Une fois que vous avez exécuté, ssh-keyscanvotre fichier hosts-connus sera pré-rempli et ssh ne vous demandera pas la permission d'ajouter une nouvelle clé.


1
Je suis un peu perplexe à propos du commentaire "aura pré-rempli" ... known_hosts n'est ni créé ni modifié après avoir exécuté cela. Vous voulez dire que le contenu peut être redirigé vers le fichier pour le remplir?
Rschwieb

4
Confirmation avec techrepublic.com/article/… . ssh-keyscan -H myhost >> ~/.ssh/known_hosts, ou pour l'ensemble du serveur,/etc/ssh/ssh_known_hosts
cole

12

Vous pouvez ajouter l'empreinte digitale aux hôtes connus de chaque serveur. Pour un utilisateur unique:

cat ~/.ssh/known_hosts
echo "$SERVER,$PORT ssh-rsa $SERVER_KEY_FINGERPRINT" >> ~/.ssh/known_hosts

3
Ce n’est plus la bonne façon de le faire depuis l’introduction du hachage.
Deim0s

10

Ignorer l'hôte

Ignorer le HostKeyChecking. Pour cela j'utilise par exemple:

ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null user@example.net

Ajouter un hôte

Ajoutez l'empreinte de l'hôte / serveur à .ssh/known_hostsavant votre première connexion. C'est le moyen le plus sûr.


Salut. Oracle lance la commande ssh, je n'ai donc aucun contrôle sur la manière dont il l'exécute.
Nicolas de Fontenay

Upvote. La plupart des réponses que j'ai vues manquent la mention de dev qui annule le fichier hosts connu. Cela rend la commande beaucoup plus utilisable et ne gâchera aucune configuration existante.
Alex

(2) Bien sûr, ajouter l’empreinte digitale au fichier hosts connu est l’approche idéale, mais comment le fait-on? (1) Pourquoi est-il avantageux de définir le fichier hôtes connu de l'utilisateur sur  /dev/null? Ne serait-il pas préférable de faire ssh -oStrictHostKeyChecking=no user@example.netune fois pour $HOME/.ssh/known_hostsenregistrer l'empreinte du serveur dans le fichier, afin que les connexions suivantes se poursuivent sans demande de confirmation?
G-Man dit 'Réintégrez Monica' le

3

Exécutez l'extrait suivant avant d'essayer.

mkdir -p ~/.ssh     
echo "Host *" > ~/.ssh/config     
echo " StrictHostKeyChecking no" >> ~/.ssh/config

ps: strictement pas pour les serveurs de production, méfiez-vous de ManInMiddle


0

J'aime la réponse de Tim pour certaines choses, cependant, s'il s'agit d'un hôte sur lequel vous souhaitez vous connecter régulièrement, je créerais une entrée dans votre ~ / .ssh / config (créez-la si le fichier n'existe pas).

# this example shows wildcard for IP
# you can even use more than one wildcard 10.0.*.* for example
Host 192.168.56.*
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
# you can even alias it, which is really useful when scp'ing/rsyncing foo:/path/to/remote
Host foo
    HostName foo-long-192-10-135-55.hostname.not-going-to-remember.doh
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.