You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Expected Behavior
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.
Steps to Reproduce
N/A
Environment
N/A
Additional Context
This was originally filed as MODULES-7604. It is similar to #95
The text was updated successfully, but these errors were encountered:
Describe the Bug
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.
Expected Behavior
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.
Steps to Reproduce
N/A
Environment
N/A
Additional Context
This was originally filed as MODULES-7604. It is similar to #95
The text was updated successfully, but these errors were encountered: