ssh: accepte automatiquement les clés

218

J'ai écrit ce petit script utilitaire:

for h in $SERVER_LIST; do ssh $h "uptime"; done

Lorsqu'un nouveau serveur est ajouté à $SERVER_LIST, le script est arrêté avec:

The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established.
RSA key fingerprint is a4:d9:a4:d9:a4:d9a4:d9:a4:d9a4:d9a4:d9a4:d9a4:d9a4:d9.
Are you sure you want to continue connecting (yes/no)?

J'ai essayé yes:

for h in $SERVER_LIST; do yes | ssh $h "uptime"; done

sans chance.

Existe-t-il un moyen de paramétrer sshpour accepter automatiquement toute nouvelle clé?

ssh scripts openssh

— Adam Matan
source

6

La réponse de Lekensteyn est excellente et correcte, mais je voulais simplement noter que, puisque ssh attend "oui" et yesgénère "y", vous auriez peut-être eu plus de chance avec for h in $SERVER_LIST; do yes yes | ssh $h "uptime"; done(notez l'extra oui, qui dit oui quoi dire à la place de "y ").

— Chazomaticus

240

Utilisez l'option StrictHostKeyChecking, par exemple:

ssh -oStrictHostKeyChecking=no $h uptime

Cette option peut également être ajoutée à ~ / .ssh / config, par exemple:

Host somehost
    Hostname 10.0.0.1
    StrictHostKeyChecking no

Notez que lorsque les clés de l'hôte ont changé, vous recevez un avertissement, même avec cette option:

$ ssh -oStrictHostKeyChecking=no somehost uptime
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
31:6f:2a:d5:76:c3:1e:74:f7:73:2f:96:16:12:e0:d8.
Please contact your system administrator.
Add correct host key in /home/peter/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/peter/.ssh/known_hosts:24
  remove with: ssh-keygen -f "/home/peter/.ssh/known_hosts" -R 10.0.0.1
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
ash: uptime: not found

Si vos hôtes ne sont pas souvent réinstallés, vous pouvez rendre cette opération moins sécurisée (mais plus pratique pour les clés d’hôte souvent modifiées) avec cette -oUserKnownHostsFile=/dev/nulloption. Cela supprime toutes les clés d’hôte reçues afin qu’il ne génère jamais l’avertissement.

Avec 18,04, il y a une nouvelle possibilité: StrictHostKeyChecking=accept-new. De man 5 ssh_config:

If this flag is set to “accept-new” then ssh will automatically
add new host keys to the user known hosts files, but will not
permit connections to hosts with changed host keys.  If this flag
is set to “no” or “off”, ssh will automatically add new host keys
to the user known hosts files and allow connections to hosts with
changed hostkeys to proceed, subject to some restrictions.

— Lekensteyn
source

10

Ce n'est pas la meilleure solution car elle contourne les outils de sécurité intégrés. ssh-keyscanest préférable, si elle est disponible sur votre système.

— Stefan Lasiewski

2

@StefanLasiewski Il permet des attaques de type homme du milieu si vous êtes sur des réseaux non fiables. Pour accepter de nouvelles clés sur des hôtes fixes, l' ssh-keyscanapproche est plus saine. Pour les machines virtuelles locales et les autres hôtes des réseaux sécurisés avec des adresses IP dynamiques / réutilisées, l'approche décrite est suffisante.

— Lekensteyn

8

Juste pour clarifier la différence entre les deux solutions: La ssh-keyscansolution n’est sujette à une attaque de type "man-in-the-middle" ssh-keyscan. La -oStrictHostKeyChecking=nosolution est sujette à une attaque de type homme du milieu à chaque sshexécution.

— Erik Sjölund

121

Vous pouvez utiliser la commande suivante pour ajouter l'empreinte digitale d'un serveur à votre hôte connu.

ssh-keyscan -H <ip-address> >> ~/.ssh/known_hosts
ssh-keyscan -H <hostname> >> ~/.ssh/known_hosts

REMARQUE: remplacez <adresse ip> et <nomhôte> par les noms IP et DNS du serveur que vous souhaitez ajouter.

Le seul problème avec ceci est que vous allez vous retrouver deux fois avec certains serveurs de votre unknown_hosts. Ce n'est pas vraiment un gros problème, juste mentionner. Pour vous assurer qu'il n'y a pas de doublons, vous pouvez d'abord supprimer tous les serveurs en lançant d'abord les éléments suivants:

ssh-keygen -R <ip-address>
ssh-keygen -R <hostname>

Pour que vous puissiez courir:

for h in $SERVER_LIST; do
    ip=$(dig +search +short $h)
    ssh-keygen -R $h
    ssh-keygen -R $ip
    ssh-keyscan -H $ip >> ~/.ssh/known_hosts
    ssh-keyscan -H $h >> ~/.ssh/known_hosts
done

Une chose à garder à l'esprit lorsque vous effectuez une suppression pour ajouter à nouveau, vous supprimez essentiellement la sécurité de la vérification de l'empreinte digitale. Donc, vous ne voudrez certainement pas exécuter ce script avant chaque exécution de votre script utilitaire.

— mhost
source

1

l'exécuter à travers le tri | uniq puis la recherche d'hôte en double en utilisant awk après rendrait le script capable de détecter les hôtes modifiés et avertir les utilisateurs que sur ceux -ci , car même hôte avec des clés différentes pourrait signifier des problèmes

— Lennart Rolland

2

Vous voudrez peut-être ajouter une note qui -Hhache les noms d’hôte et les adresses.

— David Cullen

25

Je suis un peu en retard avec cette réponse, mais la solution sensée serait de faire un scan ssh-keys sur la nouvelle machine avant de lancer la collecte de la disponibilité.

ssh-keyscan  <newhost> >> ~/.ssh/known_hosts

Désactiver le contrôle d'intégrité pour des raisons de commodité sonne comme un mauvais plan, même si vous pensez que vous maîtrisez totalement l'environnement.

— tink
source

L'exécution de la commande ci-dessus et le fait de ne pas vérifier les clés de l'hôte contre les empreintes digitales acquises hors du groupe sont vulnérables de la même manière queStrictHostKeyChecking no

— code_monk

3

@code_monk: non. J'ouvre une occasion unique d'échec (accepter qu'une clé d'un hôte incorrect soit ajoutée à des hôtes connus). StrictHostKeyChecking non autorisera les acceptations répétées pour d'autres machines.

— tink

0

Pour ajouter automatiquement une liste de serveurs, nous pouvons faire ci-dessous:

Ajouter des serveurs IP dans la liste de serveurs de fichiers

Les adresses IP doivent être ajoutées au format ci-dessous.

Sortie de cat servers-list

123.1.2.3
124.1.2.4
123.1.2.5

Changez d'IP ci-dessus en remplaçant le vôtre.

La commande ci-dessous ajoutera tous les serveurs de la liste.

ssh-keyscan -p61 -H "`cat servers-list`" >> ~/.ssh/known_hosts

— Waqas Khan
source