Return-Path: 
 <cloudstack-dev-return-4604-apmail-incubator-cloudstack-dev-archive=incubator.apache.org@incubator.apache.org>
X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org
Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 64850DC97
	for <apmail-incubator-cloudstack-dev-archive@minotaur.apache.org>;
 Wed, 29 Aug 2012 11:43:55 +0000 (UTC)
Received: (qmail 54891 invoked by uid 500); 29 Aug 2012 11:43:55 -0000
Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org
Received: (qmail 54429 invoked by uid 500); 29 Aug 2012 11:43:50 -0000
Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cloudstack-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:cloudstack-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:cloudstack-dev@incubator.apache.org>
List-Id: <cloudstack-dev.incubator.apache.org>
Reply-To: cloudstack-dev@incubator.apache.org
Delivered-To: mailing list cloudstack-dev@incubator.apache.org
Received: (qmail 54360 invoked by uid 99); 29 Aug 2012 11:43:47 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 11:43:47 +0000
X-ASF-Spam-Status: No, hits=0.7 required=5.0
	tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [109.72.87.137] (HELO smtp01.mail.pcextreme.nl) (109.72.87.137)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Aug 2012 11:43:40 +0000
Received: from [IPv6:2a00:f10:113:0:2939:21f6:4c10:8fc2] (unknown
 [IPv6:2a00:f10:113:0:2939:21f6:4c10:8fc2])
	by smtp01.mail.pcextreme.nl (Postfix) with ESMTPSA id 669C17634F
	for <cloudstack-dev@incubator.apache.org>;
 Wed, 29 Aug 2012 13:43:19 +0200 (CEST)
Message-ID: <503E0056.9070208@widodh.nl>
Date: Wed, 29 Aug 2012 13:43:18 +0200
From: Wido den Hollander <wido@widodh.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: cloudstack-dev@incubator.apache.org
Subject: Re: ssh key process
References: 
 <CALFpzo5DLR4zdGjnaGHyAY_5H+O9NviimGTV0a74NQ3y9D4mWg@mail.gmail.com>
 <503BE876.7070409@widodh.nl>
 <CALFpzo5uFF0du1OriDWNJFg2Gvo7R6hTwAP1z41Yw=wZACrS1g@mail.gmail.com>
 <503CDB0C.6050804@widodh.nl>
 <CALFpzo4hf5CGyyKWyfuGM3Dv1PExevc72aHgfTKP0w-OtM1Ytg@mail.gmail.com>
In-Reply-To: 
 <CALFpzo4hf5CGyyKWyfuGM3Dv1PExevc72aHgfTKP0w-OtM1Ytg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <wido@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 <wido@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
>>
>>