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=incubator-cloudstack.git;a=blobdiff;f=server/src/com/cloud/server/ConfigurationServerImpl.java;h=23d24a1df6b46185c481b0f2ab793453e2dc12c2;hp=3a6243b64822321fd5ae18c3f606c7245fed80e6;hb=cc0ed77feed5e5adc7cfdf9e8babe58d696e148e;hpb=fd081dc5e74671ba7e5f8dae799443dd5b24d90f 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.vit...@citrix.com> wrote: > > > On 11/14/12 6:11 PM, "Satoshi Kobayashi" <satosh...@stratosphere.co.jp> > wrote: > > >Hi Dave, > > > >2012/11/14 Dave Cahill <dcah...@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. > > -- Thanks, Dave.
