Decent idea…
> On Dec 3, 2014, at 8:24 AM, Alireza Eskandari
> <astro.alir...@yahoo.com.INVALID> wrote:
>
> It is possible if we provide password service on port 8080 with current
> insecure method and on port 8443 with secure method.
> with this solution we can use both old and new password reset service.
>
> -------- Original message --------
> From: Logan Barfield <lbarfi...@tqhosting.com>
> Date: 03/12/2014 19:32 (GMT+03:30)
> To: dev@cloudstack.apache.org
> Subject: Re: A secure way to reset VMs password
>
> Passwords are most definitely a necessity, but not having SSH Keys in the
> GUI at this point just doesn't make any sense.
>
> To clarify my thoughts on the current password system: I think a re-write
> would be great, but it should include an "insecure/legacy" option (probably
> as a global setting) that would continue to function with the current reset
> scripts.
>
>
> Thank You,
>
> Logan Barfield
> Tranquil Hosting
>
> On Wed, Dec 3, 2014 at 10:55 AM, Andrija Panic <andrija.pa...@gmail.com>
> wrote:
>
>> +1 what Nux said - I'm aware of many web developers NOT knowing what the
>> SSH keys are at all, and thus not using them... most of them relly on
>> passwords... but nice to have ssh keys for rest of us.
>>
>> On 3 December 2014 at 16:52, Nux! <n...@li.nux.ro> wrote:
>>
>>> 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
>>>>>
>>>
>>
>>
>>
>> --
>>
>> Andrija Panić
>>
