You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Dave Cahill <dc...@midokura.jp> on 2012/11/14 03:20:25 UTC
[DISCUSS] SSH keys overwritten for user running management server
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.
RE: [DISCUSS] SSH keys overwritten for user running management
server
Posted by Edison Su <Ed...@citrix.com>.
> -----Original Message-----
> From: Dave Cahill [mailto:dcahill@midokura.jp]
> Sent: Wednesday, November 14, 2012 7:19 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] SSH keys overwritten for user running management
> server
>
> 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.
+1 reuse the existing ssh key in developer mode.
>
>
> 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" <dc...@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=b
> > lobd
> > >iff;f=server/src/com/cloud/server/ConfigurationServerImpl.java;h=23d2
> > >4a1df
> >
> >6b46185c481b0f2ab793453e2dc12c2;hp=3a6243b64822321fd5ae18c3f606c72
> 45f
> > >ed80e
> >
> >6;hb=cc0ed77feed5e5adc7cfdf9e8babe58d696e148e;hpb=fd081dc5e74671b
> a7e5
> > >f8dae
> > >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"
> > >> <sa...@stratosphere.co.jp>
> > >> wrote:
> > >>
> > >> >Hi Dave,
> > >> >
> > >> >2012/11/14 Dave Cahill <dc...@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.
Re: [DISCUSS] SSH keys overwritten for user running management server
Posted by Dave Cahill <dc...@midokura.jp>.
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" <dc...@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" <sa...@stratosphere.co.jp>
> >> wrote:
> >>
> >> >Hi Dave,
> >> >
> >> >2012/11/14 Dave Cahill <dc...@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.
Re: [DISCUSS] SSH keys overwritten for user running management
server
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <dc...@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" <sa...@stratosphere.co.jp>
>> wrote:
>>
>> >Hi Dave,
>> >
>> >2012/11/14 Dave Cahill <dc...@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.
Re: [DISCUSS] SSH keys overwritten for user running management server
Posted by Dave Cahill <dc...@midokura.jp>.
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=blobdiff;f=server/src/com/cloud/server/ConfigurationServerImpl.java;h=23d24a1df6b46185c481b0f2ab793453e2dc12c2;hp=3a6243b64822321fd5ae18c3f606c7245fed80e6;hb=cc0ed77feed5e5adc7cfdf9e8babe58d696e148e;hpb=fd081dc5e74671ba7e5f8dae799443dd5b24d90f
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" <sa...@stratosphere.co.jp>
> wrote:
>
> >Hi Dave,
> >
> >2012/11/14 Dave Cahill <dc...@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.
Re: [DISCUSS] SSH keys overwritten for user running management
server
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 11/14/12 6:11 PM, "Satoshi Kobayashi" <sa...@stratosphere.co.jp>
wrote:
>Hi Dave,
>
>2012/11/14 Dave Cahill <dc...@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.
Re: [DISCUSS] SSH keys overwritten for user running management server
Posted by Satoshi Kobayashi <sa...@stratosphere.co.jp>.
Hi Dave,
2012/11/14 Dave Cahill <dc...@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.
Re: [DISCUSS] SSH keys overwritten for user running management server
Posted by Prasanna Santhanam <pr...@citrix.com>.
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.,