Bug 1466410 - M->N upgrade causes losing ssh access to undercloud
M->N upgrade causes losing ssh access to undercloud
Status: ON_DEV
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo (Show other bugs)
10.0 (Newton)
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Sofer Athlan-Guyot
Marius Cornea
: Triaged, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-29 10:16 EDT by Yolanda Robla
Modified: 2017-08-28 09:06 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1711564 None None None 2017-08-18 06:23 EDT
OpenStack gerrit 495157 None None None 2017-08-18 06:23 EDT

  None (edit)
Description Yolanda Robla 2017-06-29 10:16:47 EDT
Description of problem:


After doing the major upgrade in the undercloud from 9 to 10, i cannot enter by ssh to the undercloud anymore.
The issue is caused by selinux, because there is a wrong context for /home/stack/.ssh/authorized_keys:

cd /home/stack/.ssh/
[root@undercloud .ssh]# ls -lZ authorized_keys 
-rw-------. stack stack system_u:object_r:unlabeled_t:s0 authorized_keys
[root@undercloud .ssh]# restorecon authorized_keys
Full path required for exclude: net:[4026532200].
Full path required for exclude: net:[4026532200].
[root@undercloud .ssh]# ls -lZ authorized_keys 
-rw-------. stack stack system_u:object_r:ssh_home_t:s0  authorized_keys

After properly restoring the context, that needs to be ssh_home_t (not unlabeled_t), i can ssh to the undercloud again.
Comment 1 Yolanda Robla 2017-07-12 06:11:33 EDT
To clarify, i come from previous versions, upgrading from 8->9 then 9->10. When i upgrade to 9, i see that the authorized_keys is also labeled incorrectly, with system_u:object_r:unlabeled_t:s0 .
But it works, because selinux in 9 is set to Permissive. When going to 10, it's set to Enforcing, and this bad labeling is causing to loose access.

Note You need to log in before you can comment on or make changes to this bug.