[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] incorrect permissions
- From: Stef Walter <stef-list thewalter net>
- To: Scott Collier <emailscottcollier gmail com>, atomic-devel projectatomic io
- Subject: Re: [atomic-devel] incorrect permissions
- Date: Fri, 15 May 2015 08:39:16 +0200
On 14.05.2015 15:33, Scott Collier wrote:
>
>
> On 04/08/2015 10:30 AM, Dusty Mabe wrote:
>> On Fri, Apr 03, 2015 at 12:34:38AM -0500, Scott Collier wrote:
>>> I was testing cockpit on the F22 Atomic image and ran into this issue.
>>> Cockpit would start, but I could not connect to it because SSH was
>>> having a
>>> problem. The error cockpit gave after trying to login to the web
>>> interface
>>> was:
>>>
>>> "Couldn't connect or authenticate: no-host"
>>>
>>> This may have been brought up before, I didn't dig into existing issues.
>>>
>>> The problem was permissions on these two files:
>>>
>>> /etc/ssh/ssh_host_ecdsa_key
>>> /etc/ssh/ssh_host_rsa_key
>>>
>>> The message from "systemctl status sshd" was:
>>>
>>> # systemctl status sshd
>>> ??? sshd.service - OpenSSH server daemon
>>> Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled;
>>> vendor
>>> preset: enabled)
>>> Active: active (running) since Fri 2015-04-03 05:27:21 UTC; 7s ago
>>> Docs: man:sshd(8)
>>> man:sshd_config(5)
>>> Main PID: 5183 (sshd)
>>> Memory: 844.0K
>>> CGroup: /system.slice/sshd.service
>>> ??????5183 /usr/sbin/sshd -D
>>>
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]:
>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: @ WARNING:
>>> UNPROTECTED PRIVATE KEY FILE! @
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]:
>>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: Permissions 0640 for
>>> '/etc/ssh/ssh_host_rsa_key' are too open.
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: It is required that
>>> your
>>> private key files are NOT accessible by others.
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: This private key
>>> will be
>>> ignored.
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: key_load_private: bad
>>> permissions
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: Could not load host
>>> key:
>>> /etc/ssh/ssh_host_rsa_key
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: Server listening on
>>> 0.0.0.0 port 22.
>>> Apr 03 05:27:21 atomic-00.localdomain sshd[5183]: Server listening on ::
>>> port 22.
>>>
>>> So, I changes the permissions on both files to 600 and restarted
>>> sshd, then
>>> cockpit was able to connect.
>> So what I get by default if I start ssh and those files don't exist is:
>>
>> -bash-4.3# ls -l ssh_host_rsa_key
>> -rw-r-----. 1 root ssh_keys 1679 Apr 8 15:26 ssh_host_rsa_key
>>
>> So the perms can be 640 as long as the group is 'ssh_keys'. If I
>> change the group
>> to 'root' then I get the warning when starting sshd.
>>
>> When I start up an instance on openstack I get the
>> permissions/ownership as shown
>> above which means I don't get any errors. What environment are you
>> using? Does it
>> inject the keys into the image?
>
> OK. Sorry for the delay here. I was / am able to reproduce this
> issue. It has nothing to do with cockpit. Steps to reproduce:
>
> 1. Download F22 image with the intention of launching on a F21 host
> running KVM.
>
> wget
> https://dl.fedoraproject.org/pub/alt/stage/22_TC3/Cloud_Images/x86_64/Images/Fedora-Cloud-Atomic-22_TC3-20150507.x86_64.raw.xz
>
>
> 2. Extract the image.
>
> xz -d Fedora-Cloud-Atomic-22_TC3-20150507.x86_64.raw.xz
>
> 3. Launch the image with virt-manager
>
> 4. At this point, I CAN log into the VM via SSH.
>
> 5. Issue an "atomic host upgrade" and then reboot.
>
> 6. At this point, I CAN NOT log into the VM via SSH. Same permissions
> issue as noted above.
>
> The tree that I am on that introduces this issue:
>
> 22.68 / 666454d859
>
>
> 7. If I do an "atomic host rollback", I can SSH into the VM and it puts
> me back at the original tree:
>
> $ atomic host status
> TIMESTAMP (UTC) VERSION ID OSNAME REFSPEC
> * 2015-05-07 22:20:16 22.61 65dfa805d0 fedora-atomic
> fedora-atomic:fedora-atomic/f22/x86_64/docker-host
> 2015-05-14 12:47:39 22.68 666454d859 fedora-atomic
> fedora-atomic:fedora-atomic/f22/x86_64/docker-host
>
> 8. Then, if I do another "atomic host upgrade" the problem comes back.
The last time I highlighted this problem, the answer was that I was
doing an unsupported upgrade ... and that things had changed incompatibily.
Given that OSTree's whole raison d'etre is coherent atomic
updates/rollback ... it seems there should be a facility to refuse to
upgrade to an incompatible tree.
There's the break comming up with UID/GID as well which will again cause
this same issue for pepole.
Stef
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]