Thanks. I've submitted a patch for the aforementioned permissions issue. I'm still curious as to how the keys get on the systemvm if the injectkeys only changes the iso on the management server, but that's not a big deal.
On Tue, Aug 28, 2012 at 8:51 AM, Wido den Hollander <w...@widodh.nl> wrote: > On 08/28/2012 12:18 AM, Marcus Sorensen wrote: >> >> Yes, thanks, this helps a lot. >> >> Should cloud-agent write .ssh/id_rsa.cloud on every startup if >> necessary? Or perhaps just on joining the cluster? >> > > It's almost the same. When the Agent itself starts (joins the cluster again) > it receives the key from the management server. > > As long as you don't restart the Agent it won't receive the new keys. > > >> I only see one reference to injectkeys.sh, and it's called via >> injectSshKeysIntoSystemVmIsoPatch as "injectkeys.sh <public key> >> <private key> systemvm.iso" >> >> 2012-08-27 16:06:20,949 DEBUG [cloud.server.ConfigurationServerImpl] >> (main:null) Executing: >> /usr/lib64/cloud/agent/scripts/vm/systemvm/injectkeys.sh >> /var/lib/cloud/management/.ssh/id_rsa.pub >> /var/lib/cloud/management/.ssh/id_rsa >> /usr/lib64/cloud/agent/vms/systemvm.iso >> >> So it only seems to run on the management server itself, and indeed it >> does update the systemvm.iso on the management server. Is this >> pointless? >> > > As far as I know the systemvm.iso is never transferred from the management > server to the Agent. I'm not sure if that is still relevant. > > Wido > > >> >> >> On Mon, Aug 27, 2012 at 3:36 PM, Wido den Hollander <w...@widodh.nl> >> wrote: >>> >>> >>> >>> On 08/27/2012 11:26 PM, Marcus Sorensen wrote: >>>> >>>> >>>> Guys, >>>> In development/testing, I occasionally run into issues with the ssh >>>> keys on the system VMs. Today specifically, I've been trying to hunt >>>> down issues most of the day and still only have a hunch about the >>>> process. Most of what I'm finding are the default authorized_keys >>>> (anthony@mobl-ant), but I've got a variety; one generated on a test >>>> management server that has long been decommissioned, one that was >>>> generated on the current management server. I've got keys in the VMs >>>> on /root/.ssh/authorized_keys, /var/cache/cloud/authorized_keys, in >>>> the systemvm.iso, in the systemvm template qcow2, in the systemvm >>>> template copied to local storage, in the patch disk, I have an >>>> id_rsa.pub.cloud on some of my hosts. I'm not quite sure how to >>>> recover, short of hunting down absolutely every one of these >>>> authorized_keys files and changing them to a known good keypair. I've >>>> found the injectkeys.sh script that seems to be intended to update the >>>> systemvm.iso, but even in working clusters the systemvm.iso just has >>>> the default anthony auth key. >>>> >>>> If someone could even briefly describe how the private keys end up on >>>> the host and how the public key ends up on the system VM it would help >>>> me dramatically. As it is I think some of this stuff I've been digging >>>> through is either unused or unnecessary, which just confuses things. >>>> >>> >>> The management server has a private key stored in the homedirectory of >>> the >>> user "cloud", this is also stored in the MySQL table "configuration" with >>> the name "ssh.privatekey" and "ssh.publickey". >>> >>> Whenever the Agent starts up it receives the public and private >>> id_rsa.cloud >>> and id_rsa.cloud.pub file through the ModifySshKeysCommand command. It >>> stores these keys in /root/.ssh >>> >>> Now, when you deploy a System VM the injectkeys.sh script will be used to >>> inject this key prior to deploying the System VM. >>> >>> So, this key is not inserted in systemvm.iso, but it is injected into the >>> SystemVM when it is created. >>> >>> The default anthony key should be there, that should have been removed >>> already. >>> >>> Does this help? >>> >>> Wido > >
