incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cahill <dcah...@midokura.jp>
Subject Re: [DISCUSS] SSH keys overwritten for user running management server
Date Thu, 15 Nov 2012 03:19:18 GMT
Ah, interesting.

Judging from the initial commit I sent on, it seems like the intent of the
"delete existing SSH key and recreate" logic was for the multiple
management server case. Would it make sense to use "reuse existing SSH key"
in developer mode, since users would be unlikely to run a multiple
management server setup in development mode? This would have less impact on
the production management server upgrade path.


On Thu, Nov 15, 2012 at 12:08 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:

> 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.
>
> 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=incubator-cloudstack.git;a=blobd
> >iff;f=server/src/com/cloud/server/ConfigurationServerImpl.java;h=23d24a1df
> >6b46185c481b0f2ab793453e2dc12c2;hp=3a6243b64822321fd5ae18c3f606c7245fed80e
> >6;hb=cc0ed77feed5e5adc7cfdf9e8babe58d696e148e;hpb=fd081dc5e74671ba7e5f8dae
> >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.
> >>
> >>
> >
> >
> >--
> >Thanks,
> >Dave.
>
>


-- 
Thanks,
Dave.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message