[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] incorrect permissions



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]