SELinux Context For SSH Host Keys?

Home » CentOS » SELinux Context For SSH Host Keys?
CentOS 5 Comments

I generated a new host key for one of our systems using:

ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key_4096

I then ran ‘ls -Z on the keys’

ll -Z *key*
-rw——-. root root system_u:object_r:sshd_key_t:s0 ssh_host_dsa_key
-rw-r–r–. root root system_u:object_r:sshd_key_t:s0
-rw——-. root root system_u:object_r:sshd_key_t:s0 ssh_host_key
-rw-r–r–. root root system_u:object_r:sshd_key_t:s0
-rw——-. root root system_u:object_r:sshd_key_t:s0 ssh_host_rsa_key
-rw——-. root root unconfined_u:object_r:sshd_key_t:s0
-rw-r–r–. root root unconfined_u:object_r:sshd_key_t:s0
-rw-r–r–. root root system_u:object_r:sshd_key_t:s0

As it seems odd, to me, that all the other files had a system_u user while the new had unconfined_u. So, I decided to run restorecon -v to presumably set the SELinux user correctly for the new keys: But that is not what happened:

restorecon -v *

restorecon reset /etc/ssh/ssh_host_rsa_key_4096 context unconfined_u:object_r:sshd_key_t:s0->unconfined_u:object_r:etc_t:s0

restorecon reset /etc/ssh/ context unconfined_u:object_r:sshd_key_t:s0->unconfined_u:object_r:etc_t:s0

As you can see, not only did the user not get set to system_u but the type was changed to etc_t.

Why were the new key files changed from sshd_key_t types to the generic etc_t types? Why was the user not changed in either case from unconfined_u to system_u or vice versa?

There is no REQUIREMENT that a host key have a particular file name is there? The sshd_config provides for setting one explicitly and doing so seems to cause no problems with SSH connections that I have yet encountered.

5 thoughts on - SELinux Context For SSH Host Keys?

  • The “system_u” vs. “unconfined_u” is inconsequential. That just comes from process that set the label.

    Looking at the file labeling rules, only the 7 specific file names get a type of “sshd_key_t”, and, strangely, not the /etc/ssh directory itself, so /restorecon/ will just make any other file there inherit the type of the directory, which is “etc_t”. At first glance that looks like a bug, but perhaps there is come reason for that.

    Ask about it on the selinux list at

  • If you want to use a non-default filename for something, so that the pre-defined regexes which restorecon uses won’t match on it, you can either add a new regex to the policy which will be persistent or just use chcon to set the type manually.

    Mark Tinberg

  • Why are you putting your SSH key in /etc/ ?

    With SELinux its normally better to go with the flow. find out which directories have the desired label and keep your objects in there.

    I’m guessing in this case ~/.ssh/

  • By mistake. Sorry for the otherwise empty quoted reply. I have no idea what I pressed that sent it off while I was reading.

    And, since I am committed to writing anyway, recall that a host key goes into /etc/ssh. Personal keys go into ~/.ssh.

    As to why I am not using the default name for the rsa host key. That is because I am testing and I would rather not disturb things too much given my ignorance of SSH matters.

    I am startled to learn, if it is a fact, that existing SELinux policy is tied to the default file names. Given that the host key file names are user configurable in in sshd_config one would think that a slightly more flexible approach is called for.

  • If you choose names that aren’t part of the policy, you can always supplement the policy with your own rules. The existing policy in CentOS7 is pretty flexible, it should mark files with the following patterns as sshd_key_t:

    In CentOS6, the policy is for:

    … which is a bit less flexible.

    If you want to supplement the policy, you can run:

    semanage fcontext -a -t sshd_key_t “/etc/ssh/whatever_keyname_I_want”

    … to update the local policy with your own rules. Then a
    `restorecon` will choose the correct type.