Jira (PUP-9812) With "root" account, Puppet "ssh_authorized_keys" create file "authorized_keys" & change the owner & group

[Maheswaran Shanmugam (JIRA)]

Maheswaran Shanmugam created an issue

Puppet / PUP-9812 With "root" account, Puppet "ssh_authorized_keys" create file "authorized_keys" & change the owner & group Issue Type: New Feature Assignee: Unassigned Components: Types and Providers Created: 2019/06/30 7:02 PM Environment: This case is tested with: PE: 2018.1.x v OS: RHEL 6.9 and Centos 7.0 Priority: Major Reporter: Maheswaran Shanmugam ``` ssh_authorized_key { 'eve...@magpie.example.com': ensure => present, user => 'everetv', type => 'ssh-rsa', key => 'AAAAB3Nza[...]qXfdaQ==', target => '/opt/sysadm/etc/ssh_keys/everetv/authorized_keys', } ``` By default, in this example, the resource type "ssh_authorized_key" looks for the file "authorized_keys" owned by the specific user "everetv" inside the directory "/opt/sysadm/etc/ssh_keys/everetv/". In the secure environment, this file can't be created as a specific user and end with following error. ``` Error: /Stage[main]/Main/Ssh_authorized_key[eve...@magpie.example.com]: Could not evaluate: Permission denied @ dir_s_mkdir - /opt/sysadm/etc/ssh_keys/everetv ``` Running agent service as root, there should be a feature to create the key file and change an owner and group as per property is given while defining the resource. This feature will be very handy to deal with the security requirement of the organization where the "non-root" account is not permitted to create the files. This case is raised in connection with customer ticket "https://puppetlabs.zendesk.com/agent/tickets/35293" Add Comment

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)

[Josh Cooper (JIRA)]

Josh Cooper updated an issue

Puppet / PUP-9812 With "root" account, Puppet "ssh_authorized_keys" create file "authorized_keys" & change the owner & group

Change By: Josh Cooper ``` {code:puppet}

ssh_authorized_key { 'eve...@magpie.example.com': ensure => present, user => 'everetv', type => 'ssh-rsa', key => 'AAAAB3Nza[...]qXfdaQ==', target => '/opt/sysadm/etc/ssh_keys/everetv/authorized_keys', }

``` {code}

By default, in this example, the resource type "ssh_authorized_key" looks for the file "authorized_keys" owned by the specific user "everetv" inside the directory "/opt/sysadm/etc/ssh_keys/everetv/". In the secure environment,  this file can't be created as a specific user and end with following error.

``` {noformat}

Error: /Stage[main]/Main/Ssh_authorized_key[eve...@magpie.example.com]: Could not evaluate: Permission denied @ dir_s_mkdir - /opt/sysadm/etc/ssh_keys/everetv

``` {noformat}

Running agent service as root, there should be a feature to create the key file and change an owner and group as per property is given while defining the resource. This feature will be very handy to deal with the security requirement of the organization where the "non-root" account is not permitted to create the files. This case is raised in connection with customer ticket "https://puppetlabs.zendesk.com/agent/tickets/35293"

Add Comment

[Jacob Helwig (JIRA)]

Jacob Helwig commented on PUP-9812

Re: With "root" account, Puppet "ssh_authorized_keys" create file "authorized_keys" & change the owner & group Writing the authorized_keys file as root is not really something we should be doing in the sshkeys_core module's ssh_authorized_key type. The provider intentionally drops root permissions as it is intended to be modifying a file in a user's home directory, where we can't trust that the file path hasn't been modified in a malicious way. For example, a user could point their .ssh directory to another user via a symlink in order to take over that authorized_keys file, and determining what would be "safe" for the entire file path leading up to where the authorized_keys file would be stored for that particular user is not really something that we can do for all cases. For operating in a controlled environment such as the one described, using the File type directly to manage the content of the authorized_keys file, or using the concat module to manage individual keys in a single file would be a much better fit.

Add Comment