Another option is to tell cherokee-admin to only listen to localhost (passwordless) and then connect via SSH forwarding. However, if you take this approach, you'd have to trust every user that has SSH access to the server (which may or may not be doable in your situation).
I'd love the ability to use client-side SSL certificates (not sure what PGP certificates are or how they differ). On Tue, Jan 24, 2012 at 4:52 PM, pub crawler <[email protected]>wrote: > Umm, well, again, Cherokee-admin can be ran with the default generated > password behavior or one can use the -u to make it passwordless. There > isn't any safeguard to ask the user if they are sure of what they are > doing with a -u ran admin. :) That's the big potential opening > especially where people become more frustrated with Cherokee's good > intentioned, but hard on the admin random password. > > Affording manual password setting isn't unusual, it's how everything > else works :) > > I am all for a PGP or other crypto key based mechanism though. +1 > Unsure of the complexity for users and to implement. Doubt it's a > lunch hour project. > > I have a dozen machines running Cherokee actively. So the admin > stop/start/password copy and paste dance has me worn out :) I am > about to run the admin passwordless and put other protections in place > --- like a user and password security pop up standard validation with > whatever I have hard set. Yeah, reverse proxy will suffice :) > > Actually off now to test this way of hard setting password and leaving > the admin running permanent passwordless. > > On 1/24/12, M. David Peterson <[email protected]> wrote: > > On Mon, Jan 23, 2012 at 3:04 PM, pub crawler > > <[email protected]>wrote: > > > >> I support the ideas of both the cancel/undo. > >> > > > > Better still would be using a git-based versioning system that generates > a > > commit with every save, exposing the ability to revert back to a previous > > revision via a simple drop-down listing the sha1 of each of the previous > > commits. There are a ton of additional advantages to moving towards a > > git-based system (ease of deployment of configuration files to other > nodes > > via git push, etc.) but this particular capability would be reason > enough. > > > > Alvaro, your thoughts? > > > > > >> I also support the ability to set password for the cherokee-admin. > >> Constant annoyance for me to kill cherokee-admin and restart it just > >> to get a password to log-in.. > >> > > > > -1: Too many people will keep cherokee-admin up and running over a > > non-secure HTTP connection listening on 0.0.0.0. The last thing we need > > to have happen is for someones Cherokee instance to be compromised and > for > > some script kiddie to be given full control over its configuration. > > > > I do agree that making the login process less of a burden is a beneficial > > feature. Providing support for client-side PGP digital certificates* > that > > have been registered with a given Cherokee instance would be a MUCH more > > secure and in many ways easier to manage solution. > > > > I'm not sure what would be required to implement support for client side > > PGP certs, but at the moment the randomly generated password solution > works > > well enough to consider this a lower priority feature, I would think, if > it > > requires anything more than what can be added with minimal effort (read: > > over a typical lunch break) using existing OSS libraries. > > > > * http://www.pgptrustcenter.com/digital-certificate-solutions > > > > -- > > /M:D > > > > M. David Peterson > > Co-Founder & Chief Architect, 3rd&Urban, LLC > > Email: [email protected] > > Voice: (801) 742-1064 > > http://amp.fm | http://mdavidpeterson.com > > > _______________________________________________ > Cherokee mailing list > [email protected] > http://lists.octality.com/listinfo/cherokee >
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
