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