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.
