cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: ssh key process
Date Wed, 29 Aug 2012 11:43:18 GMT
On 08/28/2012 09:02 PM, Marcus Sorensen wrote:
> 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.

The SSH key gets injected into the System VM when it is being deployed 
by the Agent. Just before launching a new System VM it injects the key.

This is done by: scripts/vm/hypervisor/kvm/

That script is called by LibvirtComputingResource by the method 

It's on my whishlist to do all this with libguestfs on the longer run :)


> On Tue, Aug 28, 2012 at 8:51 AM, Wido den Hollander <> wrote:
>> On 08/28/2012 12:18 AM, Marcus Sorensen wrote:
>>> Yes, thanks, this helps a lot.
>>> Should cloud-agent write .ssh/ 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, and it's called via
>>> injectSshKeysIntoSystemVmIsoPatch as " <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/
>>> /var/lib/cloud/management/.ssh/
>>> /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 <>
>>> wrote:
>>>> On 08/27/2012 11:26 PM, Marcus Sorensen wrote:
>>>>> Guys,
>>>>>      In development/testing, I occasionally run into issues with the
>>>>> 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
>>>>> 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 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
>>>> and file through the ModifySshKeysCommand command. It
>>>> stores these keys in /root/.ssh
>>>> Now, when you deploy a System VM the 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

View raw message