Linux笔记系统经验菜鸟

故障排查：解决由于错误的SELinux安全上下文Context属性导致无法启动SSHD的问题【原创文章】

Posted 安迪克斯

场景：客户描述一台RedHat 7 VM无法使用SSH登录，最近一次只是更改了/etc/fstab并重启了VM结果问题就出现了。在随后的故障排查中发现并不是由于fstab修改的无法SSH问题，而是由于SELinux检测到异常的Context因此阻止SSHD服务启动。接下来请跟随本文将一步一步的剖析此类场景。

[本文为AndyX.Net原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明!]

故障排查：解决由于错误的SELinux安全上下文Context属性导致无法启动SSHD的问题【原创文章】插图

[本文为AndyX.Net原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明!]

[如果您认为本文章帮助到了您，请在文章末尾“打赏”作者，感谢！]

 

症状

无法使用SSH连接到VM。

 

故障排查

1.在Windows下尝试使用psping/tcpping检测公共IP的端口22, 结果显示端口不可用。

PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 1xx.xxx.xxx.xxx:22:
5 iterations (warmup 1) ping test:
Connecting to 1xx.xxx.xxx.xxx:22 (warmup): from 0.0.0.0:61319:
This operation returned because the timeout period expired.
Connecting to 1xx.xxx.xxx.xxx:22: from 0.0.0.0:61321:
This operation returned because the timeout period expired.
Connecting to 1xx.xxx.xxx.xxx:22: from 0.0.0.0:61325:
This operation returned because the timeout period expired.
Connecting to 1xx.xxx.xxx.xxx:22: from 0.0.0.0:61326:
This operation returned because the timeout period expired.
Connecting to 1xx.xxx.xxx.xxx:22: from 0.0.0.0:61328:
This operation returned because the timeout period expired.

TCP connect statistics for 1xx.xxx.xxx.xxx:22:
Sent = 4, Received = 0, Lost = 4 (100% loss),
Minimum = 0.00ms, Maximum = 0.00ms, Average = 0.00ms

 

2. 进一步检查到受影响的VM上检查防火墙配置，发现允许的22端口入站通信规则，没有流量阻挡的问题。

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

关于更多iptabls的配置，请参见站内文章：经验技巧：系统管理员必备的16个经典iptables使用技巧 – AndyX.Net – 安迪克斯

 

3.检查SSHD服务是否启用，结果显示为服务没有启动。

systemctl status sshd

● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sun 2022-xx-xx 17:xx:xx UTC;

 

4. 检查/var/log/message日志，显示如下关键信息：

Dec 14 17:25:31 AndyX.Net-002 systemd: Starting OpenSSH server daemon...
Dec 14 17:25:31 AndyX.Net-002 sshd: /etc/ssh/sshd_config: Permission denied
Dec 14 17:25:31 AndyX.Net-002 systemd: sshd.service: main process exited, code=exited, status=1/FAILURE
Dec 14 17:25:31 AndyX.Net-002 systemd: Failed to start OpenSSH server daemon.
Dec 14 17:25:31 AndyX.Net-002 systemd: Unit sshd.service entered failed state.
Dec 14 17:25:31 AndyX.Net-002 systemd: sshd.service failed.

结果很明显，是由于SSH配置文件”/etc/ssh/sshd_config”因为Permission denied导致的SSHD服务运行失败，接下来我们将检查为何会出现Permission denied的问题。

 

5. 检查SSH配置文件”/etc/ssh/sshd_config”的权限：

ls -al /etc/ssh/sshd_config
-rw-------. 1 root root 3954 Jan 14 05:17 /etc/ssh/sshd_config

结果显示：默认为600权限并且属主和属组都是默认的root，没有权限方面的问题。

 

6. 由于这是RedHat环境，因此有必要考虑SELinux的可能性，检查SELinux是否启用，以及具体状态：

# Check if Selinux enabled:
getenforce
==>> Enforcing

# Check the Selinux indetails:
sestatus -v

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      31

Process contexts:
Current context:                unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Init context:                   system_u:system_r:init_t:s0

File contexts:
Controlling terminal:           unconfined_u:object_r:user_tty_device_t:s0
/etc/passwd                     system_u:object_r:passwd_file_t:s0
/etc/shadow                     system_u:object_r:shadow_t:s0
/bin/bash                       system_u:object_r:shell_exec_t:s0
/bin/login                      system_u:object_r:login_exec_t:s0
/bin/sh                         system_u:object_r:bin_t:s0 -> system_u:object_r:shell_exec_t:s0
/sbin/agetty                    system_u:object_r:getty_exec_t:s0
/sbin/init                      system_u:object_r:bin_t:s0 -> system_u:object_r:init_exec_t:s0
/usr/sbin/sshd                  system_u:object_r:sshd_exec_t:s0

 

7. 故障排查SELinux权限方面的问题最佳方法是查看审计日志(路径 /var/log/audit/)：

grep -i denied /var/log/audit/*

type=AVC msg=audit(1639990850.095:529761): avc: denied { read } for pid=66329 comm="sshd" name="sshd_config" dev="dm-6" ino=3153938 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
  • type=AVC : It is the default policy type related to Selinux feature 【AVC是默认的Selinux规则标记】
  • avc: denied { read } : This means that the permission denied while reading file(s) 【读取访问被拒绝】
  • comm=”sshd” : This means that the process name 【来源为sshd进程】
  • name=”sshd_config” : This means that the SSHD config file name 【访问的文件名为sshd_config】
  • scontext : This means that the source(/usr/sbin/sshd) file Selinux context property is system_u:system_r:sshd_t:s0-s0:c0.c1023 【访问源文件sshd上下文为sshd_t】
  • tcontext : This means that the target(/etc/ssh/sshd_config) file Selinux context property is system_u:object_r:unlabeled_t:s0 【目标文件sshd_config上下文为unlabeled】
  • permissive=0 : This means that the current Selinux status is not in permissive mode 【此标记意味着SELinux并不处于permissive模式】

在这里就能很明显的看到问题根源了：拒绝读取访问因为不正确的tcontext。

 

8. 接下来需要验证/etc/ssh/sshd_config的Selinux context是否异常，我们使用 ls -Z的命令来查看Selinux context (我喜欢 ls -alZ 连用)

ls -alZ /etc/ssh/

drwxr-xr-x. root root     system_u:object_r:etc_t:s0       .
drwxr-xr-x. root root     system_u:object_r:etc_t:s0       ..
drwxr-xr-x. root root     unconfined_u:object_r:etc_t:s0   backup_key
-rw-r--r--. root root     system_u:object_r:etc_t:s0       moduli
-rw-r--r--. root root     system_u:object_r:etc_t:s0       ssh_config
-rw-------. root root     ?                                sshd_config
-rw-------. root root     system_u:object_r:etc_t:s0       sshd_config.bak
-rw-r-----. root ssh_keys system_u:object_r:sshd_key_t:s0  ssh_host_ecdsa_key
-rw-r--r--. root root     system_u:object_r:sshd_key_t:s0  ssh_host_ecdsa_key.pub
-rw-r-----. root ssh_keys system_u:object_r:sshd_key_t:s0  ssh_host_ed25519_key
-rw-r--r--. root root     system_u:object_r:sshd_key_t:s0  ssh_host_ed25519_key.pub
-rw-r-----. root ssh_keys system_u:object_r:sshd_key_t:s0  ssh_host_rsa_key
-rw-r--r--. root root     system_u:object_r:sshd_key_t:s0  ssh_host_rsa_key.pub

结果验证了我们的猜测：“sshd_config”默认Selinux context应当与“ssh_config”相同为“system_u:object_r:etc_t:s0”，但是在这里sshd_config配置文件的Selinux context竟然是个问号。

 

问题根源

修改fstab之后重启操作系统会导致SSHD服务也被重启。

但此时由于“sshd_config”异常的Selinux contex属性导致了SELinux阻止了SSHD服务的运行，这进而导致了SSHD服务启动失败从而因此了无法ssh的问题。

 

解决方法

1. 若要修正“sshd_config”的Selinux contex属性，可以运行chcon进行手动修正(适用于修正单个文件的SELinux Context问题)：

chcon system_u:object_r:default_t:s0 /etc/ssh/sshd_config

2. 或者尝试运行restorecon命令进行自动修复(适用于批量修复SELinux Context问题)：

restorecon -v /etc/ssh/sshd_config

restorecon reset /etc/ssh/sshd_config context system_u:xxxxx:s0->system_u:object_r:etc_t:s0


# 命令restorecon支持使用-R参数以递归的方式恢复整个目录的SELinux Context属性

 

其他建议

安装setroubleshoot包将会有助于快速故障排查SElinux相关问题，并且提供一些可用的建议在/var/log/message中。

 

参考文献

 

(全文完)

 

文章撰写：作者AndyX，来自AndyX.Net。

文章遵循 CC 4.0 BY-SA 版权协议，若需转载本文，请标注来源与链接：原创内容AndyX.Net版权所有

本文链接：故障排查：解决由于错误的SELinux安全上下文Context属性导致无法启动SSHD的问题 – AndyX.Net – 安迪克斯

浏览量: 171
打赏分享

相关文章:

  1. 故障排查：解决红帽Redhat/CentOS8的systemd-resolved.service不定期启动失败的问题
  2. 分享用于内嵌式Nested Hyper-V虚拟机的NMI触发脚本，以便收集完全内存转储【原创文章】
  3. 为 Stable Diffusion WebUI 创建 Linux 下自动启动服务【原创文章】
  4. 微软Azure云 IAAS故障排除与实战101：扩展含有LVM结构的OS系统磁盘(RHEL8.2)