Keys are not for everyone. Passwords are still used a lot. -- Sent from the Delta quadrant using Borg technology!
Nux! www.nux.ro ----- Original Message ----- > From: "Carlos Reategui" <create...@gmail.com> > To: dev@cloudstack.apache.org > Sent: Wednesday, 3 December, 2014 05:19:07 > Subject: Re: A secure way to reset VMs password > Why do passwords at all? Why not just use ssh keys like AWS does. The > functionality is already there just not in the ACS UI. Cloud-init already > supports it which is available in most distros and therefore would not require > CS specific scripts. At least not for linux. On windows I'm not exactly sure > how AWS does it but I think it is also some kind of terminal services > certificates so I think it could be made to work too. > > -Carlos > > > >> On Dec 2, 2014, at 2:35 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> >> wrote: >> >> 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 >>
