An open source alternative is in the works by the guys at Cloudbase.it in their cloudbase-init
https://review.openstack.org/#/c/127593/ -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Alireza Eskandari" <astro.alir...@yahoo.com.INVALID> > To: dev@cloudstack.apache.org > Sent: Wednesday, 3 December, 2014 04:44:33 > Subject: Re: A secure way to reset VMs password > A stupid question! > I can't find the source of windows version of password manager! Where is it? > > Sent from Samsung Mobile. > > <div>-------- Original message --------</div><div>From: Chiradeep Vittal > <chiradeep.vit...@citrix.com> </div><div>Date:03/12/2014 02:05 (GMT+03:30) > </div><div>To: dev@cloudstack.apache.org </div><div>Subject: Re: A secure way > to reset VMs password </div><div> > </div>You would need client-side certs as well since the password server needs > to be able to validate WHO is asking for the password. Currently it is based > on > the client's IP address. > Also the current scheme is a single-use password — as soon as the password is > retrieved, it is not available to anybody else (of course a MITM could sniff > the first exchange). > > You could eliminate a lot of MITM-style attacks by running the password server > locally on each hypervisor (hard for VMW), or by attaching an ISO (containing > the password) to the VM. > > From: John Kinsella <j...@stratosec.co<mailto:j...@stratosec.co>> > Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > Date: Tuesday, December 2, 2014 at 1:32 PM > To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > Subject: Re: A secure way to reset VMs password > > That password reset infrastructure has bigger issues than just SSL. The server > side works, but that’s about all I can say for it. This topic comes up every > 6-12 months. :) > > I thought there was a Jira entry but I can’t find it…personally I’d love to > see > the client and server sides both rewritten from scratch. > > John > > On Nov 28, 2014, at 11:33 AM, Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>> > wrote: > Jayapal, > Not necesarily, one could run stunnel or nginx as SSL proxy on some other port > (8443?), this way SSL and non-SSL connections will still work and give you > plenty of time to update your templates, if you so wish. > Am I missing any important bits here? > Lucian > -- > Sent from the Delta quadrant using Borg technology! > Nux! > www.nux.ro > ----- Original Message ----- > From: "Jayapal Reddy Uradi" > <jayapalreddy.ur...@citrix.com<mailto:jayapalreddy.ur...@citrix.com>> > To: "<dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>" > <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > Cc: "Alireza Eskandari" > <astro.alir...@yahoo.com<mailto:astro.alir...@yahoo.com>> > Sent: Friday, 28 November, 2014 09:34:02 > Subject: Re: A secure way to reset VMs password > Another point to note is all the vms in production has to update > with the new cloud-set-guest-password scripts because of the new password > reset > method. > Thanks, > Jayapal > On 28-Nov-2014, at 2:28 PM, Erik Weber > <terbol...@gmail.com<mailto:terbol...@gmail.com>> > wrote: > On Thu, Nov 27, 2014 at 3:54 PM, Alireza Eskandari < > astro.alir...@yahoo.com.invalid<mailto:astro.alir...@yahoo.com.invalid>> > wrote: > HiI viewed the bash script that resets Linux password ( > http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-password.in)It > seems that it doesn't use a secure way for transferring password string to > instance.Instances on a shared network can sniff password requests and > export requested password of other instances.I suggest to use SSL (https) > instead of plan text.Regards > I like the idea, but there's a couple of obstacles to overcome, namely > which SSL certificates to use. > - certificates need a subject name, ie. IP or hostname for web pages, you > could solve this by making the mgmt server a CA and have each VR get a > signed certificate by it, but it's complicated > - if the community bundle a pre generated certificate it is commonly known > and not to be trusted, also not sure how to handle subject name > - assuming everyone to supply a valid certificate is quite complicated (CA > must be on VR etc), and makes it considerably harder to get a working setup > - using self signed causes issues with validation > Don't get me wrong, I love the idea, but it's not just to flip a switch and > have (proper) SSL in place. > -- > Erik
