Mixing
Why is puppet trying to make changes to user's files using another user's credentials and failing?
On some servers puppet tries to enact changes to a user's files and directories using the wrong user's credentials and fails.
I am using puppet on 8 servers, some with Ubuntu OS (puppet 6.0.4 on 18.04, puppet 5.5.8 on 16.04) and some with Debian 9 (puppet 5.5.8). On three of the Ubuntu servers (not on all of them) one with puppet 5.5.8 and two with 6.04, puppet does something strange:
When running puppet agent --test --debug, the output looks like this (pseudonymized, of course):
Notice:
/Stage[main]/User/Ssh_authorized_key[user1@computer1]/ensure:
removed
Info: Computing checksum on file /home/user1/.ssh/authorized_keys
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user1@computer1]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Notice:
/Stage[main]/User/Ssh_authorized_key[user3@computer3]/ensure:
removed
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user3@computer3]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Please note, that puppet agent is running as root and user1, user2 and user3 are normal users.
Puppet was installed from the official puppetlabs-repository, following the current documentation.
The thing that I noticed is that while in the puppet manifest the users are identified by and their groups are only referenced by their username which is identical on all servers (user1 is user1 on all servers), the uid and gid are not managed by puppet and do differ (user1 has uid 1001 on one server and 1003 on another). As fas as I know, puppet should not use the uid if it is not set in the manifest, though.
Any ideas?
ubuntu puppet
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
add a comment |
On some servers puppet tries to enact changes to a user's files and directories using the wrong user's credentials and fails.
I am using puppet on 8 servers, some with Ubuntu OS (puppet 6.0.4 on 18.04, puppet 5.5.8 on 16.04) and some with Debian 9 (puppet 5.5.8). On three of the Ubuntu servers (not on all of them) one with puppet 5.5.8 and two with 6.04, puppet does something strange:
When running puppet agent --test --debug, the output looks like this (pseudonymized, of course):
Notice:
/Stage[main]/User/Ssh_authorized_key[user1@computer1]/ensure:
removed
Info: Computing checksum on file /home/user1/.ssh/authorized_keys
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user1@computer1]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Notice:
/Stage[main]/User/Ssh_authorized_key[user3@computer3]/ensure:
removed
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user3@computer3]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Please note, that puppet agent is running as root and user1, user2 and user3 are normal users.
Puppet was installed from the official puppetlabs-repository, following the current documentation.
The thing that I noticed is that while in the puppet manifest the users are identified by and their groups are only referenced by their username which is identical on all servers (user1 is user1 on all servers), the uid and gid are not managed by puppet and do differ (user1 has uid 1001 on one server and 1003 on another). As fas as I know, puppet should not use the uid if it is not set in the manifest, though.
Any ideas?
ubuntu puppet
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
Further analysis shows that this only happens ifpurge_ssh_keysis set to "true" for user2 and/or user3 and the ssh-keys for users 2 and 3 are present in the authorized_keys of user1. According to the documentation puppet only looks in the .ssh/authorized_keys file in the user’s home directory whenpurge_ssh_keysis set to "true".
– Joachim_42he
Jan 2 at 15:19
If you want anyone here to essay an answer then we will need a Minimal, Complete, and Verifiable example. It seems that that will need to involve not just manifest code, but sufficient information about the initial state of the target machine to reproduce the problem.
– John Bollinger
Jan 3 at 1:30
add a comment |
On some servers puppet tries to enact changes to a user's files and directories using the wrong user's credentials and fails.
I am using puppet on 8 servers, some with Ubuntu OS (puppet 6.0.4 on 18.04, puppet 5.5.8 on 16.04) and some with Debian 9 (puppet 5.5.8). On three of the Ubuntu servers (not on all of them) one with puppet 5.5.8 and two with 6.04, puppet does something strange:
When running puppet agent --test --debug, the output looks like this (pseudonymized, of course):
Notice:
/Stage[main]/User/Ssh_authorized_key[user1@computer1]/ensure:
removed
Info: Computing checksum on file /home/user1/.ssh/authorized_keys
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user1@computer1]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Notice:
/Stage[main]/User/Ssh_authorized_key[user3@computer3]/ensure:
removed
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user3@computer3]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Please note, that puppet agent is running as root and user1, user2 and user3 are normal users.
Puppet was installed from the official puppetlabs-repository, following the current documentation.
The thing that I noticed is that while in the puppet manifest the users are identified by and their groups are only referenced by their username which is identical on all servers (user1 is user1 on all servers), the uid and gid are not managed by puppet and do differ (user1 has uid 1001 on one server and 1003 on another). As fas as I know, puppet should not use the uid if it is not set in the manifest, though.
Any ideas?
ubuntu puppet
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
On some servers puppet tries to enact changes to a user's files and directories using the wrong user's credentials and fails.
I am using puppet on 8 servers, some with Ubuntu OS (puppet 6.0.4 on 18.04, puppet 5.5.8 on 16.04) and some with Debian 9 (puppet 5.5.8). On three of the Ubuntu servers (not on all of them) one with puppet 5.5.8 and two with 6.04, puppet does something strange:
When running puppet agent --test --debug, the output looks like this (pseudonymized, of course):
Notice:
/Stage[main]/User/Ssh_authorized_key[user1@computer1]/ensure:
removed
Info: Computing checksum on file /home/user1/.ssh/authorized_keys
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user1@computer1]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Notice:
/Stage[main]/User/Ssh_authorized_key[user3@computer3]/ensure:
removed
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user3@computer3]: Could
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Please note, that puppet agent is running as root and user1, user2 and user3 are normal users.
Puppet was installed from the official puppetlabs-repository, following the current documentation.
The thing that I noticed is that while in the puppet manifest the users are identified by and their groups are only referenced by their username which is identical on all servers (user1 is user1 on all servers), the uid and gid are not managed by puppet and do differ (user1 has uid 1001 on one server and 1003 on another). As fas as I know, puppet should not use the uid if it is not set in the manifest, though.
Any ideas?
ubuntu puppet
ubuntu puppet
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
edited Jan 2 at 15:06
Joachim_42he
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
asked Jan 2 at 14:29
Joachim_42heJoachim_42he
204
204
Further analysis shows that this only happens ifpurge_ssh_keysis set to "true" for user2 and/or user3 and the ssh-keys for users 2 and 3 are present in the authorized_keys of user1. According to the documentation puppet only looks in the .ssh/authorized_keys file in the user’s home directory whenpurge_ssh_keysis set to "true".
– Joachim_42he
Jan 2 at 15:19
If you want anyone here to essay an answer then we will need a Minimal, Complete, and Verifiable example. It seems that that will need to involve not just manifest code, but sufficient information about the initial state of the target machine to reproduce the problem.
– John Bollinger
Jan 3 at 1:30
add a comment |
Further analysis shows that this only happens ifpurge_ssh_keysis set to "true" for user2 and/or user3 and the ssh-keys for users 2 and 3 are present in the authorized_keys of user1. According to the documentation puppet only looks in the .ssh/authorized_keys file in the user’s home directory whenpurge_ssh_keysis set to "true".
– Joachim_42he
Jan 2 at 15:19
If you want anyone here to essay an answer then we will need a Minimal, Complete, and Verifiable example. It seems that that will need to involve not just manifest code, but sufficient information about the initial state of the target machine to reproduce the problem.
– John Bollinger
Jan 3 at 1:30
Further analysis shows that this only happens if
purge_ssh_keys is set to "true" for user2 and/or user3 and the ssh-keys for users 2 and 3 are present in the authorized_keys of user1. According to the documentation puppet only looks in the .ssh/authorized_keys file in the user’s home directory when purge_ssh_keys is set to "true".– Joachim_42he
Jan 2 at 15:19
Further analysis shows that this only happens if
purge_ssh_keys is set to "true" for user2 and/or user3 and the ssh-keys for users 2 and 3 are present in the authorized_keys of user1. According to the documentation puppet only looks in the .ssh/authorized_keys file in the user’s home directory when purge_ssh_keys is set to "true".– Joachim_42he
Jan 2 at 15:19
If you want anyone here to essay an answer then we will need a Minimal, Complete, and Verifiable example. It seems that that will need to involve not just manifest code, but sufficient information about the initial state of the target machine to reproduce the problem.
– John Bollinger
Jan 3 at 1:30
If you want anyone here to essay an answer then we will need a Minimal, Complete, and Verifiable example. It seems that that will need to involve not just manifest code, but sufficient information about the initial state of the target machine to reproduce the problem.
– John Bollinger
Jan 3 at 1:30
add a comment |
1 Answer
1
active
oldest
votes
My above comment was correct, I include this for others having the same problem:
It seems that contrary to the puppet doumentation here purge_ssh_keys if set under "user1" does not only
"... look for keys in the .ssh/authorized_keys file in the user’s home
directory. Purge any keys that aren’t managed as ssh_authorized_key
resources."
and removes all keys not set as "ssh_authorized_key" for "user1".
But also tries to remove any occurrence of the key set as "ssh_authorized_key" for "user1" in any other user's "authorized_keys"-file.
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
I verified this by manually removing the offending key of "user1" from the "authorized_keys"-file of "user2". A subsequent puppet run only reported the above error for the "authorized_keys"-file of "user3". After I manually removed the key from "user3"'s "authorized_keys"-file, a further puppet run completed without error.
– Joachim_42he
Jan 2 at 16:27
Trying to reproduce this on a Virtual-Box Ubuntu 18.04 server, I was not able to reproduce this strange behaviour. On that server it all worked as intended.
– Joachim_42he
Jan 2 at 17:10
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54008120%2fwhy-is-puppet-trying-to-make-changes-to-users-files-using-another-users-creden%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
My above comment was correct, I include this for others having the same problem:
It seems that contrary to the puppet doumentation here purge_ssh_keys if set under "user1" does not only
"... look for keys in the .ssh/authorized_keys file in the user’s home
directory. Purge any keys that aren’t managed as ssh_authorized_key
resources."
and removes all keys not set as "ssh_authorized_key" for "user1".
But also tries to remove any occurrence of the key set as "ssh_authorized_key" for "user1" in any other user's "authorized_keys"-file.
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
I verified this by manually removing the offending key of "user1" from the "authorized_keys"-file of "user2". A subsequent puppet run only reported the above error for the "authorized_keys"-file of "user3". After I manually removed the key from "user3"'s "authorized_keys"-file, a further puppet run completed without error.
– Joachim_42he
Jan 2 at 16:27
Trying to reproduce this on a Virtual-Box Ubuntu 18.04 server, I was not able to reproduce this strange behaviour. On that server it all worked as intended.
– Joachim_42he
Jan 2 at 17:10
add a comment |
My above comment was correct, I include this for others having the same problem:
It seems that contrary to the puppet doumentation here purge_ssh_keys if set under "user1" does not only
"... look for keys in the .ssh/authorized_keys file in the user’s home
directory. Purge any keys that aren’t managed as ssh_authorized_key
resources."
and removes all keys not set as "ssh_authorized_key" for "user1".
But also tries to remove any occurrence of the key set as "ssh_authorized_key" for "user1" in any other user's "authorized_keys"-file.
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
I verified this by manually removing the offending key of "user1" from the "authorized_keys"-file of "user2". A subsequent puppet run only reported the above error for the "authorized_keys"-file of "user3". After I manually removed the key from "user3"'s "authorized_keys"-file, a further puppet run completed without error.
– Joachim_42he
Jan 2 at 16:27
Trying to reproduce this on a Virtual-Box Ubuntu 18.04 server, I was not able to reproduce this strange behaviour. On that server it all worked as intended.
– Joachim_42he
Jan 2 at 17:10
add a comment |
My above comment was correct, I include this for others having the same problem:
It seems that contrary to the puppet doumentation here purge_ssh_keys if set under "user1" does not only
"... look for keys in the .ssh/authorized_keys file in the user’s home
directory. Purge any keys that aren’t managed as ssh_authorized_key
resources."
and removes all keys not set as "ssh_authorized_key" for "user1".
But also tries to remove any occurrence of the key set as "ssh_authorized_key" for "user1" in any other user's "authorized_keys"-file.
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
My above comment was correct, I include this for others having the same problem:
It seems that contrary to the puppet doumentation here purge_ssh_keys if set under "user1" does not only
"... look for keys in the .ssh/authorized_keys file in the user’s home
directory. Purge any keys that aren’t managed as ssh_authorized_key
resources."
and removes all keys not set as "ssh_authorized_key" for "user1".
But also tries to remove any occurrence of the key set as "ssh_authorized_key" for "user1" in any other user's "authorized_keys"-file.
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
answered Jan 2 at 16:22
Joachim_42heJoachim_42he
204
204
I verified this by manually removing the offending key of "user1" from the "authorized_keys"-file of "user2". A subsequent puppet run only reported the above error for the "authorized_keys"-file of "user3". After I manually removed the key from "user3"'s "authorized_keys"-file, a further puppet run completed without error.
– Joachim_42he
Jan 2 at 16:27
Trying to reproduce this on a Virtual-Box Ubuntu 18.04 server, I was not able to reproduce this strange behaviour. On that server it all worked as intended.
– Joachim_42he
Jan 2 at 17:10
add a comment |
I verified this by manually removing the offending key of "user1" from the "authorized_keys"-file of "user2". A subsequent puppet run only reported the above error for the "authorized_keys"-file of "user3". After I manually removed the key from "user3"'s "authorized_keys"-file, a further puppet run completed without error.
– Joachim_42he
Jan 2 at 16:27
Trying to reproduce this on a Virtual-Box Ubuntu 18.04 server, I was not able to reproduce this strange behaviour. On that server it all worked as intended.
– Joachim_42he
Jan 2 at 17:10
I verified this by manually removing the offending key of "user1" from the "authorized_keys"-file of "user2". A subsequent puppet run only reported the above error for the "authorized_keys"-file of "user3". After I manually removed the key from "user3"'s "authorized_keys"-file, a further puppet run completed without error.
– Joachim_42he
Jan 2 at 16:27
I verified this by manually removing the offending key of "user1" from the "authorized_keys"-file of "user2". A subsequent puppet run only reported the above error for the "authorized_keys"-file of "user3". After I manually removed the key from "user3"'s "authorized_keys"-file, a further puppet run completed without error.
– Joachim_42he
Jan 2 at 16:27
Trying to reproduce this on a Virtual-Box Ubuntu 18.04 server, I was not able to reproduce this strange behaviour. On that server it all worked as intended.
– Joachim_42he
Jan 2 at 17:10
Trying to reproduce this on a Virtual-Box Ubuntu 18.04 server, I was not able to reproduce this strange behaviour. On that server it all worked as intended.
– Joachim_42he
Jan 2 at 17:10
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54008120%2fwhy-is-puppet-trying-to-make-changes-to-users-files-using-another-users-creden%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Further analysis shows that this only happens if
purge_ssh_keysis set to "true" for user2 and/or user3 and the ssh-keys for users 2 and 3 are present in the authorized_keys of user1. According to the documentation puppet only looks in the .ssh/authorized_keys file in the user’s home directory whenpurge_ssh_keysis set to "true".– Joachim_42he
Jan 2 at 15:19
If you want anyone here to essay an answer then we will need a Minimal, Complete, and Verifiable example. It seems that that will need to involve not just manifest code, but sufficient information about the initial state of the target machine to reproduce the problem.
– John Bollinger
Jan 3 at 1:30