ok, so one little part I found, the reason why my /root/.ssh files weren't being updated, is that I was getting:
2012-08-27 16:35:40,227 DEBUG [cloud.agent.Agent] (agentRequest-Handler-4:null) Processing command: com.cloud.agent.api.ModifySshKeysCommand 2012-08-27 16:35:40,228 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Failed to create file: java.io.IOException: Permission denied This seems to be a bug, as /root/.ssh is created by the agent with 600 permissions if it doesn't exist. Which, even though jsvc is running as root it seems to care that it can't chdir into '/root/.ssh'. Doing a 'chmod u+x /root/.ssh' fixed this part and the keys came down. I'll submit a patch. On Mon, Aug 27, 2012 at 4:18 PM, Marcus Sorensen <shadow...@gmail.com> 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? > > 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? > > > > 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
