Each "Project" needs to have it's own ssh private key
Reported by Deleted User | September 24th, 2010 @ 02:51 PM | in Rundeck 1.3 (closed)
Each project needs to have it's own private key to override the global framework properties ssh private key.
Comments and changes to this ticket
-
Deleted User September 24th, 2010 @ 03:12 PM
- Tag set to “customer request”
-
Deleted User September 27th, 2010 @ 12:37 PM
- Milestone set to “Rundeck 1.0”
- Milestone order changed from “2” to “0”
-
Deleted User September 27th, 2010 @ 12:39 PM
- State changed from “new” to “open”
-
-
Alex-SF November 2nd, 2010 @ 03:25 PM
- Milestone changed from “Rundeck 1.0” to “Rundeck 1.1”
- Milestone order changed from “1” to “0”
-
Alex-SF January 6th, 2011 @ 10:13 AM
- Milestone changed from “Rundeck 1.1” to “Rundeck 1.2”
- Milestone order changed from “5” to “0”
-
Craig Dunn January 10th, 2011 @ 01:12 AM
I agree having a global ssh private key is restrictive, particularly for something I'm working on right now. Is project based overrides the right place to do it though? A project might include nodes that require different keys. Would it be better to have the key and use this override set on in the resource parameters for the node? We already have the "username" attribute, so it would make sense to have key info here.
-
Deleted User January 10th, 2011 @ 08:16 AM
That might be the easiest to extend in the short term.
Sent from my iPhone
On Jan 10, 2011, at 1:12 AM, "Lighthouse" <no-reply@lighthouseapp.com>
wrote: -
Alex-SF February 16th, 2011 @ 08:10 AM
- Milestone cleared.
- Milestone order changed from “7” to “0”
-
Alex-SF July 9th, 2011 @ 02:03 PM
- Tag changed from “customer request” to “customer request, ssh”
A solution might be possible using 1.3 and your own SSH plugin. This plugin can be defaulted to use a project-specific key.
-
Greg Schueler July 11th, 2011 @ 09:39 AM
- Tag cleared.
currently the ssh plugin still uses only the framework level property for the keypath, but it would be easy to update it to look for project level key, and/or node-level attribute for the key.
I recommend we do this for 1.3 as it's a common request. either this issue or a new issue
-
-
Greg Schueler July 11th, 2011 @ 09:58 AM
- Milestone set to “Rundeck 1.3”
- Tag set to “enhancement, ssh”
- Assigned user set to “Greg Schueler”
- Milestone order changed from “37” to “0”
-
Greg Schueler July 11th, 2011 @ 12:14 PM
- Tag changed from “enhancement, ssh” to “customer request, enhancement, ssh”
I propose that the ssh keyfile is then identified in this way by the builtin ssh and scp plugin:
- look for node attribute "ssh-keypath", if it is present use the
file located at that path.
- look for project property "default.ssh.keypath", use it if
present
- look for framework property "default.ssh.keypath", use it if
present
- look for original framework property "framework.ssh.keypath"
-
Alex-SF July 12th, 2011 @ 10:35 AM
using the prefix "default" does not match up w/ existing property and config file naming convention.
Perhaps then:- project.ssh.keypath (project.properties)
- framework.ssh.keypath (framework.properties)
- node.ssh.keypath (resource model data for a node)
-
Greg Schueler July 12th, 2011 @ 10:44 AM
"node.ssh.keypath" won't work for xml..
also, it seems reduendant to prefix it with "framework" in the framework
properties file, and "project" in the project properties file.what about just "ssh.keypath" for the properties files?
-
Alex-SF July 12th, 2011 @ 10:52 AM
framework prefix may seem redundant but dropping it will create an inconsistency (which we often have too much of).
To keep the property naming somewhat closer would probably should change it to "ssh-keypath" across the board.
framework.ssh-keypath, project.ssh-keypath, and ssh-keypath for a node -
Greg Schueler July 12th, 2011 @ 10:52 AM
the purpose of naming the properties the same thing was that it is easier to just consider the scope, and you could cut and paste from one to the other in order to promote or demote the scope of the setting.
if we'd rather just maintain the consistency for naming then i suppose the redundancy is at least consistent
-
Greg Schueler July 12th, 2011 @ 10:54 AM
ok that's fine...how about
- node attribute "ssh-keypath"
- project property "project.ssh-keypath"
- framework prop "framework.ssh-keypath"
- (compatibility) framework prop "framework.ssh.keypath"
- node attribute "ssh-keypath"
-
-
-
Greg Schueler July 12th, 2011 @ 11:26 AM
the only problem is now we break consistency with framework properties "framework.ssh.timeout" and "framework.ssh.user"
-
Deleted User July 12th, 2011 @ 11:55 AM
- State changed from “new” to “needs_verification”
(from [8a6ebd38343cebab4fd09c70c0ef7b6337c557f6]) Add node/project/framework settings for ssh keypath [#3 state:needs_verification] https://github.com/dtolabs/rundeck/commit/8a6ebd38343cebab4fd09c70c...
-
Deleted User July 12th, 2011 @ 11:55 AM
(from [d82f95eab3508ba512fb9514891715d7daee071d]) Add documentation of ssh private key path configuration [#3] https://github.com/dtolabs/rundeck/commit/d82f95eab3508ba512fb95148...
-
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
(DEPRECATED) Please use github issues for issue tracking at http://github.com/dtolabs/rundeck/issues
Alex-SF
Greg Schueler