The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Feature #1581

Ability to purge .ssh/authorized_keys

Added by Lars Volker over 7 years ago. Updated over 2 years ago.

Status:AcceptedStart date:09/19/2008
Priority:NormalDue date:
Assignee:eric sorenson% Done:

0%

Category:ssh
Target version:-
Affected Puppet version:0.24.4 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-1174


Description

As I’m new to puppet i’ll try to describe this as good as i can.

I wanted to use the ssh_authorized_key type to add keys to ssh. After a discussion on irc i was suggested to use virtual resources and realize each key for each class needed. This worked well for me.

However i am not able to purge all other keys from the authorized_keys file without either specifying the comment or by copying an empty file there before adding the keys, which causes the system to lock up until the update is done.

I tried using resources{} type, but as ssh_authorized_key doesn’t support “self.instances” this was also of no success.

The feature i’d like to have is an implementation of “instances” so resources{} works for authorized_keys.


Related issues

Related to Puppet - Bug #7009: Puppet ssh_authorized_keys fails on one account if key wi... Accepted 04/07/2011

History

#1 Updated by James Turnbull over 7 years ago

  • Category set to ssh
  • Status changed from Unreviewed to Accepted
  • Assignee set to Puppet Community
  • Target version set to 4

#2 Updated by Francois Deppierraz over 7 years ago

  • Assignee changed from Puppet Community to Francois Deppierraz

#3 Updated by Paul Lathrop over 6 years ago

Well, I tried to dig into this one today and I think the OP’s analysis is incorrect. ssh_authorized_keys derives from ParsedFile, which does have instances defined. AFAICT, ssh_authorized_keys should be able to be purged; it doesn’t do anything all that differently from the hosts provider.

#4 Updated by Francois Deppierraz over 6 years ago

Hi Paul,

Yes, ParsedFile has support for purging resources. But, for this to work with that particular type, it needs prior knowledge of all authorized_keys files present on the system.

#5 Updated by Ioannis Aslanidis over 4 years ago

Can we see this happening in 2.6.x?

#6 Updated by James Turnbull over 4 years ago

  • Target version deleted (4)

#7 Updated by Justin Lambert over 4 years ago

This would be a very nice feature to have to help ensure that nobody has added a key without our knowledge. Currently we push out a file to ensure that, but managing the resource would be preferred.

#8 Updated by Job Snijders over 4 years ago

Justin Lambert wrote:

This would be a very nice feature to have to help ensure that nobody has added a key without our knowledge. Currently we push out a file to ensure that, but managing the resource would be preferred.

I agree. This bug affects me too. (puppet 2.7.6-1 from debian unstable)

#9 Updated by David Schmitt about 4 years ago

As a first step, it might be enough to purge only the keys of users who have any key managed by puppet. This way it would avoid having to look at all users (which, admittedly might be way to many).

#10 Updated by Chris Hozian about 4 years ago

A temporary workaround bypassing the ssh_authorized_key resource is shown at http://serverfault.com/questions/316062/using-puppet-to-remove-ssh-keys-not-explicitly-allowed.

#11 Updated by Nathaniel Cook almost 4 years ago

Has there been any progress on fixing this? The workaround suggested could work but would require a large refactor to our system.

#12 Updated by Jo Rhett almost 4 years ago

A lot of comments in this ticket keep talking about “all users”. The description of the ticket doesn’t indicate this.

I believe that having a purge feature for only the ssh resource in question would be a huge improvement. In short, if puppet manages keys for user XYZ, then purge any key that puppet doesn’t know. This should be possible on a per-user basis, and globally the same way you set global defaults for all resources. (capitalized default)

Nothing in this ticket (except in the comments) talks about going through all users on the system and purging every key puppet can find.

#13 Updated by Nathaniel Cook almost 4 years ago

I agree with Jo Rhett. There is no need to manage all keys for all users, only users that puppet manages. This makes the implementation much simpler.

#14 Updated by Ioannis Aslanidis almost 4 years ago

This ticket has been going on for too long.

#15 Updated by eric sorenson almost 4 years ago

  • Assignee changed from Francois Deppierraz to eric sorenson

#16 Updated by Joshua Hoblitt over 3 years ago

This functionality came up in #puppet again today. Is anyone actively working on this feature?

#17 Updated by eric sorenson over 3 years ago

I had a long plane trip and spent some time poking at this — would love to hear from any of the watchers if this sounds right to you:

It’s easy to say if the current key is the only one that should be installed for a user, purge the rest. But a user should be able to have multiple keys, meaning we need to search for other ssh_authorized_keys resources with the same :user attribute as the current one, and delete any that aren’t managed. And I think that means every key for a user will end up doing that for the other keys, which is kind of crappy.

Another approach might be to use the resources resource to purge all unmanaged ssh keys at once. To implement this, ssh_authorized_key needs to implement the instances method, which enumerates all the ssh keys for all users on the system. Then the resources purge matches those up against the ones in the catalog and deletes any that don’t line up. This could be problematic too, in two ways:

  1. some of the requests suggest that only unmanaged keys for users who have at least one managed key ought to be purged (i.e. users with no keys under puppet’s control should be left alone); to implement instances it seems I’d need to enumerate every local user on the system which seems at odds with that requirement.
  2. ssh_authorized_key uses the comment field in each ssh key as the namevar, which must be globally unique but I am not confident about making clean round-trips with the regexp parsing code.

#18 Updated by Jo Rhett over 3 years ago

  1. We could add a second value which identifies which users to purge: all, managed, etc.

I would think that the most intuitive value would be for it to manage/purge keys associated with all identified users == all users that puppet manages, and to ignore users that puppet has no resources for.

  1. This piece of code is actually broken today and needs refactoring. The part which names keys logs the name of a completely different user when it fails to update a key, and will wipe out keys in other user’s files with similar names. It is unfortunate, but I feel that the right thing to do is completely rewrite that section of the code.

#19 Updated by Justin Dow over 3 years ago

I agree that this should be tied to users. It makes sense to me that one should manage an ssh key for a user only if also managing that user. Another alternative would be to have to explicitly need a purge statement per user, something like:

resources { ssh_authorized_key:

user => "root",
purge => true

}

I’m not familiar with the code, but I think having something like this would solve all my problems, since I purge unmanaged non-system users already and have scripts to enumerate the non-system users that I need to keep, my scripts could easily also populate a resources resource with the same list of users that need their keys purged. I’m not sure how others are doing user management, but having a per-user key purging setup would work for me and enable me to use puppet to keep my security requirements regarding key management.

#20 Updated by Garrett Honeycutt over 3 years ago

We should not require that a user be managed, in order to manage ssh_authorized_keys. They are very distinct resources and should not be tightly coupled.

A real world example, you manage users with a directory, not your puppet code, but still want to ensure state of given keys.

#21 Updated by Joshua Hoblitt over 3 years ago

I agree with Garrett that ssh_authorized_keys and user should not be tightly coupled. As an example from my site, I typically don’t declare a resource for the root user but I do install ssh keys into that account.

I very much want to only purge unmanaged ssh keys for select user accounts (user in the sense of system account, not puppet resource). Justin’s suggested syntax looks good to me. The gotcha is if you have conflicting purge values for ssh_authorized_key types that apply to the same user account. Eg.

ssh_authorized_key { 'bob100':
  key => '...', 
  type => 'ssh-rsa',
  user => 'bob',
  purge => true,
}
ssh_authorized_key { 'bob200':
  key => '...',
  type => 'ssh-dss',
  user => bob'
  purge => false,
}

And how would this work if some of the ssh_authorized_key resources were virtual with conflicting purge values?

#22 Updated by Joshua Hoblitt over 3 years ago

I’d also like to suggest that ssh_authorized_key isn’t a special case of managing multiple things associated with a single system account. I very much desire the ability to purge all unmanaged cron jobs associated with a given account. In particular, because the user* utilities on Linux won’t remove the crontab when removing an account. The ssh_authorized_key type doesn’t have this problem as userdel can remove the user’s home dir.

#23 Updated by James Patterson about 3 years ago

Sorry to be a pain, but any chance of an update on this?

me: “hey look, puppet can manage your ssh keys!” them: “oh wow, so when an employee leaves we can remove his key from everywhere” me: “errr, yeah kind of! but that’s really ugly and you you need a whole block of code for every employee who leaves”

#24 Updated by Dolf Schimmel almost 3 years ago

Is there any suggested workaround? Right now there only seems to be a way to add keys to the authorized_keys file, but not to revoke any. Not wanting to put too fine a point on it, but if I tell my boss he won’t like it ;)

#25 Updated by Nathan Huisman almost 3 years ago

Any way we can get some traction on this to add it to 3.x?

#26 Updated by Alex Cline almost 3 years ago

As a workaround, I’m using the concat module to manage the authorized_keys file for the users that require full key addition and deletion. Here’s an example for root’s authorized_keys file:

concat { '/root/.ssh/authorized_keys':
  owner => root,
  group => root,
  mode  => '0600',
}

concat::fragment { 'Header for root authorized_keys':
  target  => '/root/.ssh/authorized_keys',
  content => "# This file is managed by puppet.  Any changes will be discarded\n\n",
  order   => 01,
}

$username = 'joeuser'
$key      = 'ssh-rsa AAAAB3NzaC1...snip...qgEyqw== joeuser@example.com'
concat::fragment { "root authorized_key for ${username}":
  target  => '/root/.ssh/authorized_keys',
  content => "${key}\n",
}

This workaround assumes that all keys in the target file are managed by puppet and any others can be discarded. Obviously, the same could be used for individual user authorized_keys files.

#27 Updated by Varac Anero almost 3 years ago

Please include this ability into puppet 3.x ! greetings, varac

#28 Updated by James Patterson over 2 years ago

@Varac: then upvote this bug, only 38 so far!

#29 Updated by Rodney Beede over 2 years ago

Redmine Issue #1581 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-1174

Also available in: Atom PDF