[MODULES-7613] Resource Type sshkey doesn't allow the declaration of multiple SSH host keys for one host Created: 2016/08/07  Updated: 2019/12/18

Status: Accepted
Project: Modules
Component/s: sshkeys_core
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Frédéric Lespez Assignee: Unassigned
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Epic Link: ssh_authorized_key Type/Provider Improvements
Team: Coremunity

 Description   

If you try to declare a RSA ssh host key and a DSA ssh host key for the same host like this:

sshkey {
      "${trusted['certname']}_DSA_KEY":
        ensure       => $ensure,
        name         => $trusted['certname'],
        host_aliases => [$trusted['hostname']],
        key          => "XXXX",
        type         => 'ssh-dss',
}
sshkey {
      "${trusted['certname']}_RSA_KEY":
        ensure       => $ensure,
        name         => $trusted['certname'],
        host_aliases => [$trusted['hostname']],
        key          => "YYYY",
        type         => 'ssh-rsa',
}

You end up with a duplicated resource since the 'name' attribute must be unique.

If you declare your resource like this :

sshkey {
      "${trusted['certname']}_DSA_KEY":
        ensure       => $ensure,
        host_aliases => [$trusted['certname'], $trusted['hostname']],
        key          => "XXXX",
        type         => 'ssh-dss',
}
sshkey {
      "${trusted['certname']}_RSA_KEY":
        ensure       => $ensure,
        host_aliases => [$trusted['certname'], $trusted['hostname']],
        key          => "YYYY",
        type         => 'ssh-rsa',
}

I works but the resource title (the default 'name' attribute value) ends up as a host alias... Not great.

Possible solution : Add a new attribute 'hostname' (to store "The host name that the key is associated with" - then the 'name' will no longer be the host name) or use the current 'host_aliases' attributes to store the host name and its aliases.



 Comments   
Comment by Björn Lässig [ 2016/10/20 ]

I have the same problem here.
I had expected this to work:

sshkey

{'myhost.mydomain_ecdsa': name => 'myhost.mydomain', key => 'AAA....', type => 'ecdsa-sha2-nistp256' }

sshkey

{'myhost.mydomain_rsa': name => 'myhost.mydomain', key => 'AAA....', type => 'ssh-rsa' }

but it is a duplicate decalaration.

Creating a new attribute 'hostname' would be fine to me

Comment by Peter Meier [ 2017/09/18 ]

I think the proper thing would be to make the type also a namevar and hence the uniqueness would come from `name` and `type`. I tried to adjust the type with that regard, but I'm failing as I need to convert the type property to a param so it can be a namevar. See https://github.com/duritong/puppet/commit/87cc784392d539c3a522604bed009b221f88ab57 for my WIP, but I lack some provider/type developments detals here.

Comment by James Ralston [ 2017/12/14 ]

Bump. This bug makes the sshkey resource type utterly unusable.

For any modern ssh implementation, a host may have rsa keys, ecdsa keys, and ed25519 keys. If we're going to publish a host's ssh public keys, we have to publish all of them. The fact that it is impossible to do this using the sshkey resource (unless you want to publish a bunch of fake host names, as per the description) means that there's no point in even attempting to use sshkey resources to manage ssh public keys.

(We tried using the sshkey resource years ago, but when we realized that it was broken by design, we abandoned it.)

I agree with Peter Meier: what makes a ssh public key unique is the combination of its name and its key type. Neither the name nor the key type by itself is unique. The sshkey resource should use the same uniqueness test.

Comment by Josh Cooper [ 2019/10/22 ]

Composite namevars are designed to solve this problem. As Peter Meier mentioned earlier, the type is currently a property and would need to be changed to a parameter (as type is part of the resources identity, not a property you would change about an existing resource). I pushed a branch to https://github.com/joshcooper/puppet/pull/new/sshkeys_composite_namevar which demonstrates how it might work. However, it isn't idempotent and the aliases for key types don't seem to work:

sshkey { 'foo.example.com@ssh-rsa':
  ensure => present,
  key    => 'XXX',
  target => '/tmp/id_rsa'
}
 
sshkey { 'foo.example.com@ssh-dss':
  ensure => present,
  key    => 'YYY',
  target => '/tmp/id_dsa'
}

Produces:

$ bx puppet apply manifest.pp
Notice: Compiled catalog for localhost in environment production in 0.04 seconds
Notice: /Stage[main]/Main/Sshkey[foo.example.com@ssh-rsa]/ensure: created
Notice: /Stage[main]/Main/Sshkey[foo.example.com@ssh-dss]/ensure: created
Notice: Applied catalog in 0.01 seconds
$ bx puppet apply manifest.pp
Notice: Compiled catalog for localhost in environment production in 0.04 seconds
Notice: /Stage[main]/Main/Sshkey[foo.example.com@ssh-rsa]/ensure: created
Notice: Applied catalog in 0.03 seconds

Comment by Eirik Øverby [ 2019/11/06 ]

Not sure why this isn't getting more attention, as someone else has pointed out - it makes the sshkey type pretty much useless. At the very least, name+type should be the unique identifier.

Also, collecting Sshkey resources multiple times (into different targets, e.g. different users' ~/.ssh/known_hosts) is currently not possible, from what I gather. This reduces the usefulness of the type further. Adding the target to the identifier and making sure overriding target on resource import results in a unique resource would perhaps work?

Comment by Russell Knighton [ 2019/12/18 ]

Just wanted to add my 2 cents on this ticket - I too now feel that the sshkey type as it exists is pretty darn useless.

We have one local system user that has an ssh key for pulling sources from github, so I've just tried to add another user (different key, different "target" known_hosts file, etc. - only thing that is the same is it is for github.com) and I couldn't believe I just hit this:

resource ["Sshkey", "github.com"] already declared

What's the hold-up with implementing the above suggested fixes? I'd like to add that the "uniqueness" has to definitely also incorporate the target attribute.

Generated at Sun Jan 19 19:32:03 PST 2020 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.