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?

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".

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é.

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

Ignorer l'hôte

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

ssh -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null [email protected]

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.

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

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