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/rundomrpre.sh
That script is called by LibvirtComputingResource by the method
patchSystemVm()
It's on my whishlist to do all this with libguestfs on the longer run :)
Wido
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
