running rhel 7.6 (or centos 7.6)

With selinux = enforcing doing an ssh in to or out of the system works, but doing a scp to the RHEL selinux system does not work.

On the RHEL system if I do setenforce 0 to put selinux to permissive, then a scp to it works.

How do I make it so RHEL/CentOS 7.x with selinux=enforcing allows incoming scp ?

  • What are the related AVC denial entries in audit log (/var/log/audit/audit.log)? What does audit2why suggest? – sebasth Sep 17 at 14:20
  • never heard of audit2why – ron Sep 17 at 15:15
  • man audit2why – sebasth Sep 17 at 15:29

There's probably lots of reasons why this happens. I can tell you what worked for me when I had the same (or a very similar) problem. My password-less scp command was failing:

-bash-4.2$ scp postgres@ .
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

I ran "setenforce 0" on the source machine and my scp worked, I ran "setenforce 1" and it failed again.

My problem turned out to be the "SeLinux File Context" of my "/.ssh/authorized_keys" file on the remote ( machine:

-bash-4.2$ pwd /var/lib/pgsql -bash-4.2$ cd .ssh -bash-4.2$ ls -Z authorized_keys -rw-------. postgres postgres unconfined_u:object_r:postgresql_db_t:s0 authorized_keys -bash-4.2$

The stuff with the three colons in it is this "Selinux File Context" thingy, and Selinux is very picky about it (much like Selinux is about everything else). I suppose it's in four pieces, and the SeLinux documentation explaining what/why/how WRTO each part is as clear and easy-to-understand as (I'm sure) "man audit2why" was for you (if you looked at it).

Anyway, my problem had to do with the stuff between the 2nd and 3rd ":"'s, the "postgresql_db_t" part. SeLinux just didn't like that. Over on another machine, from which I could password-lessly successfully scp stuff with the blessing of Selinux, that same portion of the "Selinux File Context" was "ssh_home_t", which seemed much more promising.

So, how to change the "Selinux File Context" ?? Googling "selinux change file context" led me to the "semanage" and "restorecon" commands. Now, "semanage" was a rabbit-hole down which I happily did not have to crawl. "restorecon" did the trick for me.

It turns out (and this is a very little-publicized thing about SeLinux), the proper approved sanctified default "Selinux File Contexts" for all sorts of common files on Unix/Linux SeLinux inplementations are defined, somehow, (on Centos anyway) within the directory tree "/etc/selinux/targeted/contexts/files/"! Here's what restorecon did for me:

[root@srcbox ~]# /sbin/restorecon -v /var/lib/pgsql/.ssh/authorized_keys /sbin/restorecon reset /var/lib/pgsql/.ssh/authorized_keys context unconfined_u:object_r:postgresql_db_t:s0->unconfined_u:object_r:ssh_home_t:s0 [root@psrcbox ~]# . . . . -bash-4.2$ pwd /var/lib/pgsql/.ssh -bash-4.2$ ls -Z authorized_keys -rw-------. postgres postgres unconfined_u:object_r:ssh_home_t:s0 authorized_keys -bash-4.2$

I did not define any new "SeLinux File Contexts" via semanage. The existing definitions were enough to tell the "restorecon" command what the third field of the "SeLinux File Context" of my "authorized_keys" file was supposed to be. And then, I could keep SeLinux in enforcing mode on my source machine and successfully scp.

Now, there is probably some official approved way of creating and updating the "authorized_keys" file that gets the "SeLinux File Context" right in the first place, but I couldn't tell you what it is. All I can say is creating the file with "vi" after manually creating the ".ssh" directory, and then cutting-pasting the public key from the machine and user where I was running my scp command, is likely not it.

So try running restorecon on various files within the relevant ".ssh" directories, and maybe on the directory itself. Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.