On Wed, Nov 14, 2012 at 07:50:25AM +0530, Dave Cahill wrote:
> 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:
>
> Line 592:
> File privkeyfile = new File(homeDir + "/.ssh/id_rsa");
>
> Line 600:
> Script.runSimpleBashScript("if [ -f " + privkeyfile + " ]; then rm
> -f " + privkeyfile + "; fi; ssh-keygen -t rsa -N '' -f " + privkeyfile + "
> -q");
>
> In other words, the user who is running the management server will have
> their *default* public / private keys deleted and recreated.
>
> I know that many people run the management server as the "cloud" user, so
> perhaps they don't mind their SSH keys being overwritten in this case.
> However, when developing, it's handy to run as one's usual user, and having
> your default SSH keys blown away seems like really bad (and unexpected)
> behaviour - any servers (e.g. GitHub) where you have your public key
> registered will become inaccessible to you.
This is exactly what happen to me this morning. Couldn't push to
github because the mvn run erased my keys which IMO is a *very* bad
idea.
>
> I can see a few possibilities:
> * The management server should never, even in development, be run as a user
> other than cloud
> - In this case, we need to make this very clear in dev docs - current
> development mode docs mention nothing about creating a special user to run
> as
> - We need to remove the developer mode option, which is currently on by
> default if you deploy the db using mvn -P developer -pl developer -Ddeploydb
The developer profile is useful for some bootstrapping. Opening up
debug symbols, ports etc. I don't think we should get rid of it. But
should document what it does.
> - 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
Agree. Prod environments running as cloud makes perfect sense. But dev
environments will always run as dev user.
> * 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 I remember was possible before when ant was being used.
> - 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
+1 for non-default key names - under no circumstances should we
affect the keys of the user. My keys were connected to tons of
instances before this happened. :(
--
Prasanna.,
