ssh_authorized_key not purged as expected

[anarcat]

Describe the Bug

Having the following setup:

File: /root/.ssh/authorized_keys

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQXXXXXXXXXXXXXXXXXXXXXXXXXXXCCnPvBi9gRCVPWHHaLtz3Df5iVDunsQ5JA5wk2YaK8AXfrvIzO+vZWj7maFEP8PIfoFPi8L3M83ELXBSVLp/FdAGf1q221kXeioOyia/HBewn857EpWBtagUwpbE1k/Lmrp7mDVJrXrPVVjdafV8VMLA84fTdastAbJEJEw8o6lemUavHedTslkUPEzOdqVbsT7dmEbYOg6cj9drxC6yOZMpR/jok8xbEmJbaa9iZTWJyHE8YWHesA2v2Afdy46oOJ8XeYSNR4CVjhF6eWjT9yMg6QhmlpmmoLfi9R9PUq1ymltP90Hi+EKYbOJUGQ== ssh-key-user

And the following manifest

user { 'user':
  ensure => present,
  home => '/home/user',
  purge_ssh_keys => true,
}
user { 'root':
  ensure => present,
  home => '/root',
  purge_ssh_keys => true,
}
ssh_authorized_key { 'ssh-key-user':
  type => 'ssh-rsa',
  user => 'user',
  key => 'ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQXXXXXXXXXXXXXXXXXXXXXXXXXXXCCnPvBi9gRCVPWHHaLtz3Df5iVDunsQ5JA5wk2YaK8AXfrvIzO+vZWj7maFEP8PIfoFPi8L3M83ELXBSVLp/FdAGf1q221kXeioOyia/HBewn857EpWBtagUwpbE1k/Lmrp7mDVJrXrPVVjdafV8VMLA84fTdastAbJEJEw8o6lemUavHedTslkUPEzOdqVbsT7dmEbYOg6cj9drxC6yOZMpR/jok8xbEmJbaa9iZTWJyHE8YWHesA2v2Afdy46oOJ8XeYSNR4CVjhF6eWjT9yMg6QhmlpmmoLfi9R9PUq1ymltP90Hi+EKYbOJUGQ=='
}

Expected Behavior

The key in /root/.ssh/authorized_keys is not purged, altought it should be according to the catalog.

Environment

• Version: first reported on Puppet 4.8.2, confirmed on 5.5.14/5.3.8, needs to be verified on Puppet 7 and later
• Platform: Centos7, Debian, etc

Additional Context

When deploying servers, we hand over the server with a ssh key of the ordering person added to the root user's ssh key file. Once the server is attached to puppet, the server is "provissioned" - meaning we add personal accounts with sudo and want to use puppet to purge all unmanaged ssh keys in the root users.

This was originally filed as MODULES-7596 and has been mostly ignored for 7 years at this point.

This is possibly an issue with the built-in User type as well, mind you.

[anarcat]

So I have filed this thinking this was actually still an issue, but here on a Puppet 7 agent (and Puppet 5 server), I do not see that behavior anymore, so i think this is actually fixed, phew!