Each "Project" needs to have it's own ssh private key
Reported by Deleted User | 2010-09-24 14:51:24 UTC | 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 2010-09-24 15:12:10 UTC
- Tag set to “customer request”
-
Deleted User 2010-09-27 12:37:28 UTC
- Milestone set to “Rundeck 1.0”
- Milestone order changed from “2” to “0”
-
Deleted User 2010-09-27 12:39:12 UTC
- State changed from “new” to “open”
-
-
Alex-SF 2010-11-02 15:25:12 UTC
- Milestone changed from “Rundeck 1.0” to “Rundeck 1.1”
- Milestone order changed from “1” to “0”
-
Alex-SF 2011-01-06 10:13:55 UTC
- Milestone changed from “Rundeck 1.1” to “Rundeck 1.2”
- Milestone order changed from “5” to “0”
-
Craig Dunn 2011-01-10 01:12:37 UTC
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 2011-01-10 08:16:53 UTC
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 2011-02-16 08:10:53 UTC
- Milestone cleared.
- Milestone order changed from “7” to “0”
-
Alex-SF 2011-07-09 14:03:26 UTC
- 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 2011-07-11 09:39:46 UTC
- 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 2011-07-11 09:58:31 UTC
- 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 2011-07-11 12:14:56 UTC
- 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 2011-07-12 10:35:36 UTC
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 2011-07-12 10:44:51 UTC
"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 2011-07-12 10:52:04 UTC
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 2011-07-12 10:52:42 UTC
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 2011-07-12 10:54:28 UTC
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 2011-07-12 11:26:31 UTC
the only problem is now we break consistency with framework properties "framework.ssh.timeout" and "framework.ssh.user"
-
Deleted User 2011-07-12 11:55:02 UTC
- 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 2011-07-12 11:55:04 UTC
(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