Bug #5930
closed
sshKeyDistribution creates 0 byte authorized_keys file
Added by Florian Heigl almost 10 years ago.
Updated almost 10 years ago.
Description
Hi,
I'm only getting a 0 byte .ssh/authorized_keys for the users.
My suspicion is this is only happening since I added a second technique for user creation.
I can produce it on two different envs, running different versions.
Attaching the file sshKeyDistribution.cf from test client.
rudderc1:/var/rudder/cfengine-community/inputs/sshKeyDistribution/3.0
This one box is actually running a dated client
rudder-agent-2.11.3.release-1.SLES.11
But the other lab is on a more recent one, so I don't think there is a relation to the agent.
I checked, my technique on the server is == the one in git.
[FAR] workaround:
For people relying on that technique and not wanting to wait for a new release: the culprit is "ifvarclass => "key_parsed"" in sshKeyDistribution.st, and removing it fixes the issue.
See: https://github.com/ncharles/rudder-techniques/commit/ef19e241bc3de426a1ac0064b0d767057b8889b3
Files
|
k.txt (9.55 KB)
k.txt |
|
Florian Heigl, 2014-12-05 12:35
|
|
rudderc1:/var/rudder/cfengine-community/inputs/sshKeyDistribution/3.0 # cf-agent -v --debug -KI 2>&1 | grep -i key |grep -i ssh
R: @fileAlterationMonitoring@result_success@a0acd7e7-9bec-463f-bf53-4e77a5c41d87@33dca793-2f31-4d3a-8002-5e63378d2474@11@File or directory to monitor@/etc/ssh/ssh_host_rsa_key.pub@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#The content of /etc/ssh/ssh_host_rsa_key.pub is consistent
R: @fileAlterationMonitoring@result_success@a0acd7e7-9bec-463f-bf53-4e77a5c41d87@33dca793-2f31-4d3a-8002-5e63378d2474@11@File or directory to monitor@/etc/ssh/ssh_host_ecdsa_key.pub@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#The content of /etc/ssh/ssh_host_ecdsa_key.pub is consistent
R: @fileAlterationMonitoring@result_success@a0acd7e7-9bec-463f-bf53-4e77a5c41d87@33dca793-2f31-4d3a-8002-5e63378d2474@11@File or directory to monitor@/etc/ssh/ssh_host_dsa_key@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#The content of /etc/ssh/ssh_host_dsa_key is consistent
R: @fileAlterationMonitoring@result_success@a0acd7e7-9bec-463f-bf53-4e77a5c41d87@33dca793-2f31-4d3a-8002-5e63378d2474@11@File or directory to monitor@/etc/ssh/ssh_host_dsa_key.pub@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#The content of /etc/ssh/ssh_host_dsa_key.pub is consistent
R: @fileAlterationMonitoring@result_success@a0acd7e7-9bec-463f-bf53-4e77a5c41d87@33dca793-2f31-4d3a-8002-5e63378d2474@11@File or directory to monitor@/etc/ssh/ssh_host_rsa_key@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#The content of /etc/ssh/ssh_host_rsa_key is consistent
R: @fileAlterationMonitoring@result_success@a0acd7e7-9bec-463f-bf53-4e77a5c41d87@33dca793-2f31-4d3a-8002-5e63378d2474@11@File or directory to monitor@/etc/ssh/ssh_host_ecdsa_key@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#The content of /etc/ssh/ssh_host_ecdsa_key is consistent
R: @sshKeyDistribution@result_success@0cd4eae8-9b6b-44db-b5c7-cbb50fa4a814@38751969-b949-4769-9987-66fdb15c7728@25@SSH key@Flo key Eden@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#SSH key "Flo key Eden" for user floh was correct
R: @sshKeyDistribution@result_success@7b5e11f3-0836-45b4-9c2e-bf9b92a0c228@2f4296e8-b356-4fa8-b140-1aea42e1a219@15@SSH key@rudderc5 key@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#SSH key "rudderc5 key" for user admpaulo was correct
R: @sshKeyDistribution@result_success@7b5e11f3-0836-45b4-9c2e-bf9b92a0c228@2f4296e8-b356-4fa8-b140-1aea42e1a219@15@SSH key@rudderc5 key@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#SSH key "rudderc5 key" for user admflo was correct
R: @sshKeyDistribution@result_success@0cd4eae8-9b6b-44db-b5c7-cbb50fa4a814@38751969-b949-4769-9987-66fdb15c7728@25@SSH key@Flo key egal@2014-12-05 11:35:55+00:00##4ba9ccd6-5831-4daa-8f6b-647d6b3d5473@#SSH key "Flo key egal" for user floh was correct
If a key is removed, it'll repair it, but drop in a 0 byte one again.
- Assignee set to Nicolas CHARLES
Nico, could you take a look to that important bug ?
Ok, in #5561 we rewrote the complete technique, but left a condition in the edition, which is preventing actual file edition...
Oh, actually, this is a merge issue from 2.10 to 2.11,it worked before 12/11/2014
- Category set to Techniques
- Status changed from New to In progress
- Target version set to 2.11.6
- Status changed from In progress to Pending technical review
- Assignee changed from Nicolas CHARLES to Benoît PECCATTE
- Pull Request set to https://github.com/Normation/rudder-techniques/pull/618
- Description updated (diff)
- Description updated (diff)
- Status changed from Pending technical review to Pending release
- % Done changed from 0 to 100
Applied in changeset policy-templates:commit:ef19e241bc3de426a1ac0064b0d767057b8889b3.
Applied in changeset policy-templates:commit:81dad48eb32a5045786559a2246505f285737d7e.
- Target version changed from 2.11.6 to 2.11.7
- Status changed from Pending release to Released
This bug has been fixed in Rudder 2.11.7, which was released these days.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by