SSH: Unable to get valid context for [name]

TL;DR For the Savvy Sysadmin:
1. Boot into rescue
2. mkdir /mnt && mount /dev/DEVICE /mnt
3. touch /mnt/.autorelabel
4. Boot back into normal


Recently we upgraded a "cloud" (read: normal VPS with a fancy name) server instance, which involved creating a snapshot of the original VM and restoring it on a new hypervisor. After the migration, everything seemed to be working well. That is, until trying to ssh to the server:

$ ssh skh@example.com
  Unable to get valid context for skh 
  Last login: ... 
  Connection to example.com closed.

Yikes! Being a cloud server, there was no physical access to the box. The words context and label are dead giveaways for the issue having something to do with SELinux. In this case, it seemed that some of the labels had been corrupted during the transfer, which is why SSH couldn't run. Labels are the fourth column when running ls -Z, and should look similar to the following:

$ ls -Z /
dr-xr-xr-x. root root system_u:object_r:bin_t:s0       bin
dr-xr-xr-x. root root system_u:object_r:boot_t:s0      boot
...

Rebuilding SELinux Labels (CentOS / RHEL 6)

First, boot your server into rescue mode (your host should have an option for this. If not, contact them). Among other things, rescue mode loads a small linux flavour independent of your OS and allows you to manipulate the disk on which your normal OS resides.

Once in rescue mode, find the available physical mediums using fdisk:

$ fdisk -l
Disk /dev/vda: 85.9 GB, 85899345920 bytes
...

Locate your drive containing the OS as listed above (in this case, /dev/vda) and mount it:

$ mkdir mnt
$ mount /dev/vda mnt

As menitoned, we want to rebuild the SELinux labels, and RHEL flavours have a handy way of doing this. When the system loads and SELinux is not disabled, it looks for an /.autorelabel file. If it's present, SELinux will rebuild the labels of the entire filesystem, which is what was causing the errors after migration. So, we just need to create the file and unmount the drive:

$ touch mnt/.autorelabel
$ umount mnt

Boot your server back into normal mode, keeping in mind it could take some time for the relabelling process, especially if you have a large filesystem.

When it's complete, you should be able to regain access to you server via SSH.

What if relabelling didn't work?

Although this worked in my case, if it does not in yours: go back into rescue mode, mount the drive, and disable SELinux completely by setting SELINUX=disabled in mnt/etc/selinux/config.

Try booting back into normal mode. Although this isn't a solution as you won't have SELinux anymore, it will likely allow you to regain access for further investigation.

View more on the CentOS wiki.

SEO Plug: Article - SSH: Unable to get valid context for root

Comments

Jimmy Chu's picture

Jimmy Chu

Thanks for this post. I enabled SELinux, restored from my snapshot, and encountered your situation. And your solution save my day!