Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Chiradeep.Vittal@citrix.com
 designates 66.165.176.89 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: CloudStack DeveloperList <cloudstack-dev@incubator.apache.org>
Date: Wed, 14 Nov 2012 19:08:47 -0800
Subject: Re: [DISCUSS] SSH keys overwritten for user running management
 server
Thread-Topic: [DISCUSS] SSH keys overwritten for user running management
 server
Thread-Index: Ac3C3ogdlOILGF3SQZCC2Y6PeLs+sQ==
Message-ID: <CCC99B0B.36FE3%chiradeep.vittal@citrix.com>
In-Reply-To: 
 <CALytfWagAKGz__5=WuTpKRgOJ3u5zonGZVTLF-ctiFCY9faYDA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hmm, this commit (26e78bd0) introduces the devel flag.
Previously if the user was not cloud then the ssh keys would be left
intact.

Certainly the upgrade case for production management servers will be
impacted.=20

On 11/14/12 6:48 PM, "Dave Cahill" <dcahill@midokura.jp> wrote:

>Hi Chiradeep,
>
>I had a poke through commit logs, and my understanding was that this
>commit
>from January 2011 is where the code went from reusing existing keys to
>removing and updating them, but I may easily be missing something.
>
>"bug 8199: always update the keypairs on disk to account for multiple
>management servers"
>https://git-wip-us.apache.org/repos/asf?p=3Dincubator-cloudstack.git;a=3Db=
lobd
>iff;f=3Dserver/src/com/cloud/server/ConfigurationServerImpl.java;h=3D23d24=
a1df
>6b46185c481b0f2ab793453e2dc12c2;hp=3D3a6243b64822321fd5ae18c3f606c7245fed8=
0e
>6;hb=3Dcc0ed77feed5e5adc7cfdf9e8babe58d696e148e;hpb=3Dfd081dc5e74671ba7e5f=
8dae
>799443dd5b24d90f
>
>If we changed the filename, what would be the effects on the upgrade path?
>For example, if someone has an existing management server with keys named
>id_rsa but not id_rsa.systemvm keys, I guess we could copy id_rsa and
>id_rsa.pub to id_rsa.systemvm and id_rsa.systemvm.pub?
>
>Thanks,
>Dave.
>
>
>
>On Thu, Nov 15, 2012 at 11:33 AM, Chiradeep Vittal <
>Chiradeep.Vittal@citrix.com> wrote:
>
>>
>>
>> On 11/14/12 6:11 PM, "Satoshi Kobayashi" <satoshi-k@stratosphere.co.jp>
>> wrote:
>>
>> >Hi Dave,
>> >
>> >2012/11/14 Dave Cahill <dcahill@midokura.jp>:
>> >> Hi,
>> >>
>> >> I've recently been running the management server from source using
>>mvn
>> >>-pl
>> >> :cloud-client-ui jetty:run, and I've come across an issue.
>> >>
>> >> If the "ssh.privatekey" configuration entry is not present in the
>> >> management server db, then in ConfigurationServerImpl
>> [snip]
>> >>     - Given what I know so far, I disagree with this option; the
>> >>behaviour
>> >> seems weird even for the "cloud" user, and someone will certainly
>>try to
>> >> run as their own user even if we recommend against it
>> >> * The management server should back up old ssh keys before deleting
>>them
>> >> - Better than nothing, but non-ideal; unless the user realizes what
>> >> happened, this will not help them
>> >> * The management server should use existing ssh keys if available,
>> >>instead
>> >> of recreating
>> >> - This sounds like a good option - may cause issues if the existing
>> >>keypair
>> >> is password-protected?
>> >> * The management server should use a non-default filename for the ssh
>> >>keys,
>> >> e.g. id_rsa.systemvm and id_rsa.pub.systemvm, to avoid damaging
>>existing
>> >> SSH keys
>> >> - This option seems ideal from my point of view, but may involve
>>extra
>> >>work
>> >
>> >+1 for a non-default filename ssh key idea.
>> >I think that it is dangerous that a default ssh key is overwritten
>> >even if it adopts other ideas.
>>
>> +1 for non-default filename. As Prasanna said, in the ant mode, it never
>> deleted the old key, it just reused it.
>> Not sure how it got borked.
>>
>>
>
>
>--=20
>Thanks,
>Dave.