=== cpaelzer_ is now known as cpaelzer === jrm2 is now known as jrm [15:17] https://bugs.launchpad.net/cloud-init/+bug/1853470 i think this can be closed [15:17] -ubottu:#cloud-init- Launchpad bug 1853470 in cloud-init "parse_timestamp_from_date requires GNU coreutils' date" [Undecided, Triaged] [18:24] Hi, I use cloud-init to generate my host-key provided by Terraform. I have an issue that the access rights getting changed from 0644 to 0600. Is this intended or a bug? [18:58] Mazorius: how are you writing this file? [19:00] @mee [19:01] meena I setting it up via the cloud.init sshd module: [19:01] disable_root: true [19:02] ssh_deletekeys: true [19:02] ssh_genkeytypes: [] [19:02] ssh_keys: [19:02]   ed25519_private: | [19:02]     ${indent(4, host_key.private_key_openssh)} [19:02]   ed25519_public: ${host_key.public_key_openssh} [19:02] it is a Terraform template [19:04] private key. [19:04] private key, 0644. sounds very wrong [19:06] Mazorius: please be more specific. what are you seeing and why do you think it is not correct? [19:09] Mazorius: why are you creating a host key in Terraform? cloud-init can create that itself. Normally a host private key should be created on-device and never leave the device [19:10] minimal for a git remote installation you need to provide a fixed host key and can not simply use always a new generated. So that is not possible in this case. [19:11] waldi the git server is not able to read the Host-key as it is only readable by root (0600) when I change it to (0644) which is ne normal case everything works as expected. [19:12] Mazorius: the host key is supposed to be not readable [19:12] meena for a private key you are completely right. Sorry. It is only about the public key [19:12] sorry, but this is a xy-problem, not a cloud-init problem [19:13] generally speaking a host's SSH private key should only be readable by the SSH server [19:13] of course but not the public key and this is also 0600 instead of 0644 which would be correct. [19:13] Sorry for the mistake with the private key.;) [19:17] well, it is because the cloud-init is told to do that: [19:17] f"{k}_private": (KEY_FILE_TPL % k, 0o600), [19:17] f"{k}_public": (f"{KEY_FILE_TPL % k}.pub", 0o600), [19:17] nothing wrong with that, nothing apart sshd needs to read even the public key [19:19] Mazorius: what software on your host needs access to the host public key? [19:26] minimal GitLab [19:26] so it is intended and is not possible to be changed in anyway? waldi [19:29] as a workaround you could use a "runcmd:" entry to change the permissions [19:31] I did that but want to be sure if this is the only solution. Thanks all of you. [19:31] not being familiar with Gitlab installation I still do not see why a specific priv/pub host key set have to be provided rather than using an autogenerated set [19:33] Mazorius: well it may well make sense to change cc_ssh.py to use 644 rather than 600 for the *public* host key, the way to (potentially) change that would be for someone to submit a PR [19:35] actually looking on a cloud-init configured VM here I see the public host key *IS* -rw-r--r-- [19:38] minimal: you did not supply the key, but let cloud-init generate it? [19:38] yes that's cloud-init generated [19:38] that's the difference [19:39] ok, I still understand why Mazorius cannot use a c-i generated key during his gitlab installation - no info has been provided as to why that won't work [19:42] waldi: ah, here's where it is set for autogenerated public key: https://github.com/canonical/cloud-init/blob/9c7502a801763520639c66125eb373123d1e4f44/cloudinit/config/cc_ssh.py#L282 [19:44] Mazorius: what group does Gitlab run under? you can change the group, and give the group read access to the key: 0640 [19:45] meena: no, he can't, as cloud-init sets the permission to 0600 [19:46] but if he uses the autogenerated public key then every user on the system has read access to it...... [19:49] or use install / chmod + chgrp in runcmd [20:03] meena it runs by default under the gitlab_rails group which is generated by the package installation [20:05] Mazorius: which runs well after cloud-init? does it have a fixed GID? [20:07] interesting is that cloud-init seems to generate a pub key if provided with 0600: https://github.com/canonical/cloud-init/blob/9c7502a801763520639c66125eb373123d1e4f44/cloudinit/config/cc_ssh.py#L190 [20:07] but if not provided and simply generate it by itself with 0644: https://github.com/canonical/cloud-init/blob/9c7502a801763520639c66125eb373123d1e4f44/cloudinit/config/cc_ssh.py#L282 [20:07] And the private key with 0600 if provided and if not 0640 … so it somehow inconsistent in cloud-init or I am wrong? [20:08] Do not know that inside of the omnibus installation meena [20:08] we already discussed this difference in permissions [20:11] were was this discussed? As all tools I know use 0600 for private and 0644 for public: [20:11] e.g.: https://www.tenable.com/audits/items/CIS_Google_Container_Optimized_OS_v1.0.0_L1_Server.audit:7f016cd406100a1ee2ad94834111f005 [20:11] https://www.tenable.com/audits/items/CIS_Google_Container_Optimized_OS_v1.0.0_L1_Server.audit:6225b8224fbd4f360ebdc72c56f3eae9 [20:12] Mazorius: 30 minutes ago here when I said: [20:12] > "waldi: ah, here's where it is set for autogenerated public key: https://github.com/canonical/cloud-init/blob/9c7502a801763520639c66125eb373123d1e4f44/cloudinit/config/cc_ssh.py#L282" [20:13] ah you mean this:)  If it is only changing this line I can of course create a PR for that. [20:14] and also 40 mins ago when I said: [20:14] "Mazorius: well it may well make sense to change cc_ssh.py to use 644 rather than 600 for the *public* host key, the way to (potentially) change that would be for someone to submit a PR" [20:34] minimal the PR: https://github.com/canonical/cloud-init/pull/1971 [20:34] -ubottu:#cloud-init- Pull 1971 in canonical/cloud-init "Fix permission of SSH host keys" [Open]