[MODULES-7604] ssh_authorized_keys should not use the key 'comment' as a unique identifier (name) Created: 2014/05/20  Updated: 2018/11/27

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

Type: Bug Priority: Major
Reporter: redmine.exporter Assignee: Unassigned
Resolution: Unresolved Votes: 7
Labels: help_wanted, redmine, ssh, ssh_authorized_key, tse, type_and_provider
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
blocks MODULES-7598 User {purge_ssh_keys => true, } not r... Needs Information
is duplicated by PUP-1175 Puppet ssh_authorized_keys fails on o... Closed
relates to PUP-3357 Unexpected error with multiple SSH ke... Closed
relates to MODULES-7614 user resource does not remove duplica... Accepted
Team: Platform OS


Currently the ssh authorized keys provider uses the 'comment' section from an SSH public key as the 'name'. However, this implies that these comment strings must be unique, while SSH itself imposes no such restriction: in fact, it often happens that users generate both an RSA and a DSA key, which by default will have the same comment.

A better 'name' for a key would perhaps be its fingerprint. There is a very small chance of collisions, but using the comment as 'name' is certain to generate collisions (for me it already has). Otherwise, the key-string itself should perhaps be the 'name' as this is certainly unique.

If a user just changes the 'name' of the key in the Puppet manifest, then the other problem is that Puppet (only looking at the 'name', not the contents of the key) fails to realize that a key is already in place so you end up with duplicates. The current implementation doesn't really manage authorized_keys, it only manages the comment section and has no knowledge of the actual key.
Using the key fingerprint would require Puppet to be able to actually extract the fingerprint from the key and would be a non-trivial change.

Comment by Paul Tötterman [ 2014/05/20 ]

I ran into problems with this as well, trying to enable access using the same ssh key to different accounts:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Cannot alias Ssh_authorized_key[ldap_ssh_key_username_0] to ["username@domain.com"] at /etc/puppet/production/modules/users/manifests/admin.pp:22; resource ["Ssh_authorized_key", "username@domain.com"] already declared at /etc/puppet/production/modules/users/manifests/admin.pp:22 at /etc/puppet/production/modules/users/manifests/admin.pp:22 on node hostname

Comment by Elisiano Petrini [ 2014/12/02 ]

I am (well was, I had to fix it manually) by the inverse problem.

We had a specific keys into multiple users (with the same comments) and that messed up with what seemed a different error ( it looked like: http://projects.puppetlabs.com/issues/19994 ).

Comment by Alan Stebbens [ 2015/01/02 ]

This misfeature also prevents from being able to add the same sshkey to different authorized_keys files. For example, if user joe need to have ssh access to a utility ops account, then joe's public key needs to be added to his own ~joe/.ssh/authorized_keys file, as well as to the ~ops/.ssh/authorized_keys file.

Currently, the key names under the ssh_authorized_keys: stanza need to be made unique. So, when inserting joe's public key for his own account, the ssh key name might be "joe@mydomain.com". But, to use the same ssh key under the ops account, that same key name cannot currently be used, even though the public key is, in fact, the same key.

Instead, there should be a single, "master" definition of a given public key, and then there should be a way to reference (for insertion) copies of that same key.

The current syntax for defining an ssh key is:

     key_name: joe@mydomain.com
       type: ssh-rsa
       key: .... SSHKEYSTRING ...

then, to reference a key already defined, perhaps allow a new attribute: use_key to mean something similar to key_name:

    - use_key: joe@mydomain.com
    - use_key: sally@mydomain.com

Comment by Robin Bowes [ 2015/03/20 ]

For me, the ssh_authorized_key resource is unusable because of this issue.

Is there any enthusiasm for a change to this resource, or even a new one that works?

Comment by Branan Riley [ 2017/05/15 ]

Thank you for filing this issue. We agree it is likely an improvement, but due to other issues demanding precedence, we don’t anticipate being able to address this any time soon. If you are interested in submitting a patch to the repository for this project at https://github.com/puppetlabs, please open a pull request and re-open this ticket.

Generated at Sat Aug 08 08:29:26 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.