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
