ssh-key declaration with same key name

[tabletick]

Hi,

when declaring two users with the same key name, an error is returned

users_maintenance:
  user1:
    ensure: present
    uid: 398        
    groups: 
    comment: User 1
    managehome: true
    ssh_authorized_keys:
      rundeck-key:
        type: 'ssh-rsa'
        mykey:  'key-data'
  user2:
    ensure: present
    uid: 399
    groups:
    comment: User 2
    managehome: true
    ssh_authorized_keys:
      automate-key:
        type: 'ssh-rsa'
        mykey: 'key-data'

Error:

    Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate declaration: Users::Ssh_authorized_keys[mykey] is already declared in file [...]/manifests/setup.pp at line 42; cannot redeclare on node localhost.localdomain

Changing this to different names for the keys fixes the issue. But since this isn't pointed out in the documentation, I wonder if this is on purpose.

[mthibaut]

Hi,

Key names need to be unique, because they are setup in puppet using the "ssh_authorized_key" resource. And all resources need a unique name. I guess I could name the keys using the user and the key name, which would ensure that the resource name is unique.

So yes this is on purpose, but not necessarily a good idea. For now, please keep using different names until I get a chance to fix this and update the documentation...

maarten

On 20 Aug 2013, at 15:06, tabletick [email protected] wrote:

Hi,

when declaring two users with the same key name, an error is returned

users_maintenance:
user1:
ensure: present
uid: 398
groups:
comment: User 1
managehome: true
ssh_authorized_keys:
rundeck-key:
type: 'ssh-rsa'
mykey: 'key-data'
user2:
ensure: present
uid: 399
groups:
comment: User 2
managehome: true
ssh_authorized_keys:
automate-key:
type: 'ssh-rsa'
mykey: 'key-data'
Error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate declaration: Users::Ssh_authorized_keys[mykey] is already declared in file [...]/manifests/setup.pp at line 42; cannot redeclare on node localhost.localdomain

Changing this to different names for the keys fixes the issue. But since this isn't pointed out in the documentation, I wonder if this is on purpose.

—
Reply to this email directly or view it on GitHub.

[tabletick]

Hi,

I thought you've already done that: When you configured `key1= 'foofoo', I end up with

~/.ssh/authorized_keys
foofoo key1-key1key

I'm not sure why the module produces key1-key1key. From what I could quickly see was that you've used the username as well, therefore I got puzzled when you've mentioned you haven't done that yet.
Changing the keynames to something unique works so far.

[mthibaut]

Ah yes so that's why I did that ;). I guess I could make the resource unique by using this mechanism and still use the key name provided by the user. This would cause less confusion perhaps?

On 22 Aug 2013, at 15:58, tabletick [email protected] wrote:

Hi,

I thought you've already done that: When you configured `key1= 'foofoo', I end up with

~/.ssh/authorized_keys
foofoo key1-key1key
I'm not sure why the module produces key1-key1key. From what I could quickly see was that you've used the username as well, therefore I got puzzled when you've mentioned you haven't done that yet.
Changing the keynames to something unique works so far.

—
Reply to this email directly or view it on GitHub.

[tabletick]

Yes, I guess so. Alternatively you could mention it in your documentation. I guess that's why I made the mistake of choosing the same keyname in the first place.

[noemif]

I guess I could make the resource unique by using this mechanism and still use the key name provided by the user.

Definitely better :-) I needed that for our setup, having the module use the resource name as the key name was too restrictive. I modified the ssh_authorized_keys.pp manifest, adding the line below to the ssh_authorized_keys resource definition:

name     => $hash[$name]['name'],

and in my hiera file added the 'name' parameter:

    users_sysadmins:
        john:
            ensure: present
            uid: 1000
            gid: staff
            groups: - wheel
            comment: John Doe
            managehome: true
            ssh_authorized_keys:
                    mykey:
                            name: 'some_key_name'
                            type: 'ssh-rsa'
                            key:  'mykeydata=='

This way you can deploy the same key to more than one user, with the same key name (i.e. key comment in authorized_keys file).

[luis-alen]

Forgive my ignorance as I'm just starting with puppet and I've been trying to use the module without success :(

I have the same issue (deploy the same key to different users) and I think that the key should always be unique, since the resource name includes both the user and the key name in ssh_authorized_keys.pp:

ssh_authorized_key { "${user}-${name}" :
...
}

However, it seems to me that the problem is actually not with the resource 'ssh_authorized_key' but with 'users::ssh_authorized_keys' in setup.pp and I'm unable to make it work. I tried the suggestion given by @noemif but it didn't work too. I guess there's more somewhere. I'm sure I'm missing something...

Duplicate declaration: Users::Ssh_authorized_keys[luis.alen] is already declared in file /etc/puppet/modules/users/manifests/setup.pp:42; cannot redeclare at /etc/puppet/modules/users/manifests/setup.pp:42

This is how my yaml looks like now (I've tried it in different ways though. Different values for the key 'name', without the key 'name' and so on... The only thing that actually worked was changing the key name to something unique):

users_admins:
  adm:    
    ensure: present
    comment: Admin
    uid: 45001
    managehome: true
    ssh_authorized_keys:
      luis.alen:
        name: 'luis.alen'
        ensure: present
        type: 'ssh-rsa'
        key:  'mykeydata=='

users_developers:
  dev:
    ensure: present
    uid: 45000
    comment: Developer
    managehome: true
    ssh_authorized_keys:
      luis.alen:
        name: 'luis.alen'
        ensure: present        
        type: 'ssh-rsa'
        key:  'mykeydata=='

@noemif, was the ssh_authorized_keys resource definition all you changed to make it work?

[gtmtech]

+1 for fixing this

[law]

+1, running into this same issue as well