Erreur de clé SSH non valide dans juju lors de son utilisation avec MAAS
Ceci est la sortie de juju à partir d'une installation propre avec 2 nœuds exécutant tous 12.04 juju bootstrap - se termine sans erreur et alloue la machine à l'utilisateur, mais toujours sans joie après l'environnement juju - détruit et reconstruit avec différents utilisateurs et différents nœuds.
root@cloudcontrol:/storage# juju -v status
2012-06-07 11:19:47,602 DEBUG Initializing juju status runtime
2012-06-07 11:19:47,621 INFO Connecting to environment...
2012-06-07 11:19:47,905 DEBUG Connecting to environment using node-386077143930...
2012-06-07 11:19:47,906 DEBUG Spawning SSH process with remote_user="ubuntu" remote_Host="node-386077143930" remote_port="2181" local_port="57004".
The authenticity of Host 'node-386077143930 (10.5.5.113)' can't be established.
ECDSA key fingerprint is 31:94:89:62:69:83:24:23:5f:02:70:53:93:54:b1:c5.
Are you sure you want to continue connecting (yes/no)? yes
2012-06-07 11:19:52,102 ERROR Invalid SSH key
2012-06-07 11:19:52,426:18541(0x7feb13b58700):Zoo_INFO@log_env@658: Client environment:zookeeper.version=zookeeper C client 3.3.5
2012-06-07 11:19:52,426:18541(0x7feb13b58700):Zoo_INFO@log_env@662: Client environment:Host.name=cloudcontrol
2012-06-07 11:19:52,426:18541(0x7feb13b58700):Zoo_INFO@log_env@669: Client environment:os.name=Linux
2012-06-07 11:19:52,426:18541(0x7feb13b58700):Zoo_INFO@log_env@670: Client environment:os.Arch=3.2.0-23-generic
2012-06-07 11:19:52,426:18541(0x7feb13b58700):Zoo_INFO@log_env@671: Client environment:os.version=#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
2012-06-07 11:19:52,428:18541(0x7feb13b58700):Zoo_INFO@log_env@679: Client environment:user.name=sysadmin
2012-06-07 11:19:52,428:18541(0x7feb13b58700):Zoo_INFO@log_env@687: Client environment:user.home=/root
2012-06-07 11:19:52,428:18541(0x7feb13b58700):Zoo_INFO@log_env@699: Client environment:user.dir=/storage
2012-06-07 11:19:52,428:18541(0x7feb13b58700):Zoo_INFO@zookeeper_init@727: Initiating client connection, Host=localhost:57004 sessionTimeout=10000 watcher=0x7feb11afc6b0 sessionId=0 sessionPasswd=<null> context=0x2dc7d20 flags=0
2012-06-07 11:19:52,429:18541(0x7feb0e856700):Zoo_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
2012-06-07 11:19:55,765:18541(0x7feb0e856700):Zoo_ERROR@handle_socket_error_msg@1579: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
- J'ai essayé de nombreuses manières de créer les clés avec ssh-keygen -t rsa -b 2048, ssh-keygen -t rsa, ssh-keygen, et j'ai essayé de les ajouter à la page de configuration Web de MAAS, mais le résultat est toujours identique.
- J'ai ensuite ajouté la clé publique appropriée au
~/.ssh/authorized_keys - Je peux aussi ssh sur le nœud, mais comme on ne m'a pas demandé de lui donner un nom d'utilisateur ou un mot de passe, ni de configurer un compte, je ne peux pas ssh manuellement dans le nœud. La configuration du nœud est entièrement gérée par le serveur maas. Cela ressemble à une simple erreur de regarder la mauvaise clé ou au mauvais endroit, seules les autres suggestions que je peux trouver sont de détruire l'environnement et de le reconstruire (mais cela n'a pas fonctionné jusqu'à maintenant) ou de le laisser pour créer l'instance. une fois que le nœud a été mis sous tension, mais je suis parti pendant quelques heures et je suis parti du jour au lendemain pour construire sans succès.
La solution que j'ai proposée consiste à définir un mot de passe pour les nœuds récemment démarrés, puis à insérer manuellement des clés SSH dans chacun d'entre eux. Pour définir un mot de passe de démarrage pour l'utilisateur Ubuntu, assurez-vous que les lignes suivantes sont définies sur /var/lib/cobbler/kickstarts/maas.preseed:
d-i passwd/make-user boolean true
d-i passwd/user-fullname ubuntu
d-i passwd/username string ubuntu
d-i passwd/user-password-crypted password <CRYPTED PASSWORD>
Une fois cela fait, vous pouvez ssh ubuntu @ et utiliser le mot de passe spécifié dans la chaîne de mot de passe cryptée (la méthode la plus simple consiste à utiliser celui d'un fichier/etc/shadow que vous connaissez déjà) pour vous connecter. Vous pouvez ensuite insérer vos clés publiques SSH. sous ~ ubuntu/.ssh/registered_keys et ~ racine/.ssh/clés autorisées.
Notez qu'il s'agit d'une solution de contournement. Une fois que vous avez ssh-keygen, MaaS doit extraire id_rsa.pub de votre répertoire .ssh ou de l'interface Web MaaS, où l'utilisateur peut spécifier une clé publique dans son profil. Peu importe ce que j'ai essayé, ces clés ne sont pas propagées, alors j'ai trouvé la solution de contournement.
Une autre astuce consiste simplement à ajouter la clé .pub à .ssh/registered_keys de votre nœud MaaS, puis à la transmettre à chacun des nœuds du système MaaS:
for i in `cobbler system list |grep -v default`;
do j=`cobbler system dumpvars --name "${i}" | grep hostname |grep -v duplicate |cut -f 2 -d \:`;
scp ~/.ssh/authorized_keys ubuntu@${j}:.ssh/authorized_keys;
done
Cela vous permet d’accepter à plusieurs reprises les erreurs de certificat SSH et de saisir le mot de passe dans la chaîne cryptée pour renseigner l’ensemble de votre MaaS avec la clé publique SSH.
Assurez-vous de générer vos clés SSH sur le même hôte que celui sur lequel vous utilisez juju et ajoutez la moitié publique de votre/vos clé (s) SSH de cette machine dans MAAS (essayez: ls ~/.ssh/*.pub pour les trouver tous. ). Il ne devrait pas être nécessaire de mettre manuellement les clés dans ~/.ssh/authorized_keys.
Le guide démarrer avec Juj peut vous aider si vous ne l'avez pas déjà vu.
Je suis confronté au même problème. Il y a deux jours, j'ai commencé à chercher une réponse et la chose la plus importante que j'ai découverte est la suivante:
Lorsque vous exécutez "état juju", vous pouvez rencontrer une erreur indiquant "Clé SSH non valide"
La source la plus probable de cette erreur est que les noeuds démarrés par juju n'ont pas encore fini de démarrer et de s'installer. Cela peut se produire lorsque l'horloge sur le nœud est trop désynchronisée pour que la vérification OAuth fonctionne, ce qui entraîne l'expiration du nœud lors d'une tentative de téléchargement à partir du service de métadonnées et continue finalement à démarrer à partir d'une connexion. Invite sans exécuter la préconfiguration Juju.
Essayez de vérifier l'horloge sur le nœud et réinitialisez-le s'il est très différent de l'horloge du serveur MAAS.
Cela a vraiment résolu ce problème. J'ai exécuté ntpdate sur mon serveur MAAS et installé le nouveau nœud, fonctionne maintenant très bien!
Assurez-vous de laisser suffisamment de temps au nœud pour l'installation après le démarrage. l’installation d’Ubuntu peut prendre 10 minutes. Les messages d'erreur semblent indiquer que juju tente de se connecter à une machine qui n'exécute pas encore sshd, ce qui pour moi indique que le programme d'installation est probablement toujours en cours d'exécution.