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:
>
> 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.
>
> 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
> - 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.
>
> Does anyone have an opinion on this?
>
> Thanks,
> Dave.
