Ungültiger Ssh-Schlüsselfehler in Juju bei Verwendung mit Maas?

Dies ist die Ausgabe von juju von einer sauberen Installation mit 2 Knoten, auf denen alle 12.04 juju Bootstrap ausführen – endet ohne Fehler und weist die Maschine dem Benutzer zu, aber immer noch keine Freude nach der Zerstörung der Juju-Umgebung und der Neuerstellung mit verschiedenen Benutzern und verschiedenen Knoten. P>

[email protected]:/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):[email protected][email protected]: Client environment:zookeeper.version=zookeeper C client 3.3.5
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:host.name=cloudcontrol
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:os.name=Linux
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:os.arch=3.2.0-23-generic
2012-06-07 11:19:52,426:18541(0x7feb13b58700):[email protected][email protected]: Client environment:os.version=#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: Client environment:user.name=sysadmin
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: Client environment:user.home=/root
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: Client environment:user.dir=/storage
2012-06-07 11:19:52,428:18541(0x7feb13b58700):[email protected][email protected]: 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):[email protected][email protected]: 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):[email protected][email protected]: Socket [127.0.0.1:57004] zk retcode=-4, errno=111(Connection refused): server refused to accept the client

• Ich habe zahlreiche Möglichkeiten zum Erstellen der Schlüssel mit ssh-keygen -t rsa -b 2048, ssh-keygen -t rsa, ssh-keygen ausprobiert, und ich habe versucht, diese zur MAAS-Webkonfigurationsseite hinzuzufügen, bekomme aber immer die gleiches Ergebnis.
• Ich habe den passenden öffentlichen Schlüssel nachträglich zu ~/.ssh/authorized_keys hinzugefügt
• Ich kann auch per ssh auf den Knoten zugreifen, aber da ich nicht aufgefordert wurde, ihm einen Benutzernamen oder ein Passwort zu geben oder irgendein Konto einzurichten, kann ich nicht manuell auf den Knoten per ssh zugreifen. Die Einrichtung des Knotens wird vollständig vom Maas-Server durchgeführt. Es scheint ein einfacher Fehler zu sein, auf den falschen Schlüssel zu schauen oder an den falschen Stellen zu suchen, nur andere Vorschläge, die ich finden kann, sind, die Umgebung zu zerstören und neu zu erstellen (aber das hat jetzt x-mal nicht funktioniert) oder es zu verlassen, um die Instanz zu erstellen sobald der Knoten hochgefahren ist, aber ich bin für ein paar Stunden gegangen und bin über Nacht gegangen, um ohne Glück zu bauen.

Akzeptierte Antwort:

Die Lösung, die ich mir ausgedacht habe, besteht darin, ein Passwort für die neu gestarteten Knoten festzulegen und dann manuell SSH-Schlüssel in jeden von ihnen einzufügen. Um ein Boot-Passwort für den Ubuntu-Benutzer festzulegen, stellen Sie sicher, dass die folgenden Zeilen in /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>

Sobald dies erledigt ist, können Sie ssh [E-Mail-geschützt] senden und das in der verschlüsselten Passwortzeichenfolge angegebene Passwort verwenden (am einfachsten ist es, eines aus einer /etc/shadow-Datei zu verwenden, die Sie bereits kennen), um sich anzumelden. Sie können dann Ihre SSH-Adresse einfügen öffentliche Schlüssel unter ~ubuntu/.ssh/authorized_keys und ~root/.ssh/authorized keys.

Verwandte:Probleme mit Nvidia GPU und Ubuntu 16.04?

Beachten Sie, dass dies eine Problemumgehung ist – sobald Sie ssh-keygen ausführen, sollte MaaS entweder die id_rsa.pub aus Ihrem .ssh-Verzeichnis oder aus der MaaS-WebUI abrufen, wo der Benutzer einen öffentlichen Schlüssel in seinem Profil angeben kann. Egal, was ich versucht habe, diese Schlüssel werden nicht weitergegeben, also habe ich mir die Problemumgehung ausgedacht.

Ein weiterer Cheat besteht darin, den .pub-Schlüssel einfach zu den .ssh/authorized_keys Ihres MaaS-Knotens hinzuzufügen und ihn dann an jeden der Knoten im MaaS zu scpen:

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 [email protected]${j}:.ssh/authorized_keys;
done

Dadurch können Sie die SSH-Zertifikatsfehler einfach wiederholt akzeptieren und das Passwort in die verschlüsselte Zeichenfolge eingeben, um Ihr gesamtes MaaS mit dem öffentlichen SSH-Schlüssel zu füllen.