System Operation & System Setting & System Software (系统操作 & 系统设置 & 系统软件) – Page 18

May 20, 2023November 22, 2024

[内容] Linux SSH ECDSA 码的管理

内容一：SSH ECDSA 码介绍

1.1 什么是 ECDSA 码

ECDSA 是 SSH 服务为自己生成的唯一识别，通常一旦生成便不会改变

当 SSH 客户端访问 SSH 服务端时会尝试识别此 SSH 服务端（以此 SSH 服务端的 IP 地址或者域名为判断依据）的 SSH ECDSA 码：

如果当 SSH 客户端没有记录过此 SSH 服务端的 SSH ECDSA 码时，SSH 客户端会给出提示并让用户选择是否信任并记录此 SSH ECDSA 码

如果当 SSH 客户端记录过此 SSH 服务端的 SSH ECDSA 码且和过去的记录匹配时，SSH 客户端会直接 SSH 登录此 SSH 服务端

如果当 SSH 客户端记录过此 SSH 服务端的 SSH ECDSA 码且和过去的记录不一致时，SSH 客户端会给出提示此 IP 地址或者域名的 SSH ECDSA 码已发生改变，此时 SSH 客户端无法通过密码 SSH 登录 SSH 客户端，但是可以通过密码登录 SSH 客户端

1.2 SSH ECDSA 码存放位置

/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ecdsa_key

内容二：管理 SSH ECDSA 码

2.1 查看 SSH 服务端的 SSH ECDSA 码

# ssh-keyscan -t ecdsa <SSH Server IP address>

或者：

# ssh-keyscan -t ecdsa <SSH Server IP domain>

2.2 将现在 SSH 服务端的 SSH ECDSA 码替换记录里的 SSH ECDSA 码

2.2.1 通过使用 ssh-keygen 命令将现在 SSH 服务端的 SSH ECDSA 码替换记录里的 SSH ECDSA 码

# ssh-keygen -R <SSH Server IP address>

或者：

# ssh-keygen -R <SSH Server IP domain>

2.2.2 通过修改 ~/.ssh/known_hosts 配置文件将现在 SSH 服务端的 SSH ECDSA 码替换记录里的 SSH ECDSA 码

# vim ~/.ssh/known_hosts

删除对应的记录：

（步骤略）

2.3 在本服务器上生成新的 SSH ECDSA 码

# ssh-keygen -t ecdsa -f ssh_host_ecdsa_key

May 20, 2023November 22, 2024

[步骤] Linux SSH 访问的限制（Rocky Linux 8 & RHEL 8 版）

步骤一：设置 SSH 访问限制

# vim /etc/ssh/sshd_config

添加以下内容：

......
AllowUsers *@192.168.0.1/32 *@192.168.1.0/255.255.255.0 zhumingyu mingyuzhu@192.168.1.1 *.eternalcenter.com
AllowGroups zhu
DenyUsers *
DenyGroups *

（
补充：这里以只允许
1) 来自 IP 地址 192.168.0.1 的用户可以 SSH 登录本服务器
2) 来自 IP 网段 192.168.1.0/255.255.255.0 的用户可以 SSH 登录本服务器
3) 用户 zhumingyu 可以 SSH 登录本服务器
4) 来自 192.168.1.1 的用户 mingyuzhu 可以 SSH 登录本服务器
5) 属于组 zhu 的用户可以 SSH 登录本服务器
6) 来自域名 *.eternalcenter.com 除了域名 attacker.eternalcenter.com 的用户可以 SSH 登录本服务器
为例
）

步骤二：重启 SSH 服务

# systemctl restart sshd

May 20, 2023November 22, 2024

[步骤] Linux SSH 访问的限制（openSUSE & SLES & CentOS 7 & RHEL 7 版）

正文：

步骤一：启用 UseTCPWrappers 参数

# vim /etc/ssh/sshd_config

将部分内容修改如下：

......
UseTCPWrappers yes
......

步骤二：设置 SSH 访问限制

2.1 禁止来自所有 IP 地址的所有用户可以 SSH 本服务器

# vim /etc/hosts.deny

添加以下内容：

......
sshd : ALL : deny

或者：

......
sshd : ALL

2.2 只允许某些用户可以 SSH 本服务器

# vim /etc/hosts.allow

添加以下内容：

......
sshd : 192.168.0.1/32: allow
sshd : 192.168.1.0/255.255.255.0: allow
sshd : zhumingyu:allow
mingyuzhu@192.168.1.1 : allow
sshd : *.eternalcenter.com EXCEPT attacker.eternalcenter.com

或者：

sshd : 192.168.0.1 : allow
sshd : 192.168.1. : allow
sshd : zhumingyu : allow
mingyuzhu@192.168.1.1 : allow
sshd : .eternalcenter.com EXCEPT attacker.eternalcenter.com

（
补充：这里以允许
1) 来自 IP 地址 192.168.0.1 的用户可以 SSH 登陆本服务器
2) 来自 IP 网段 192.168.1.0/255.255.255.0 的用户可以 SSH 登陆本服务器
3) 用户 zhumingyu 可以 SSH 登陆本服务器
4) 来自 192.168.1.1 的用户 mingyuzhu 可以 SSH 登陆本服务器
5) 来自域名 *.eternalcenter.com 除了域名 attacker.eternalcenter.com 的用户可以 SSH 登陆本服务器
为例
）

步骤三：重启 SSH 服务

# systemctl restart sshd

参考文献：

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sect-security_guide-tcp_wrappers_and_xinetd-tcp_wrappers_configuration_files

May 13, 2023November 22, 2024

[排错] Linux 解决启动时，某个盘挂不上或者报错 “Warning: dracut-initqueue timeout – starting timeout scripts”

报错代码

启动时某个盘挂不上

或者：

Warning: dracut-initqueue timeout - starting timeout scripts

分析

系统启动 initrd 的时间默认上限是 90 秒钟，如果 initrd 加载的时间超过 90 秒钟，则系统会报此错误。

导致 initrd 加载时间过多的原因有很多，例如系统根 “/” 目录需要加载的硬盘过多、系统根 “/” 目录的逻辑卷过多、根 “/” 目录的系统逻辑卷挂载格式是 /dev// （这是设备的链接文件，需要等待 udev 规则将其创建以后才能挂载）。

注意：当无法正常进入系统时可以进入救援模式后再使用可尝试的解决方法尝试解决问题

Linux 救援模式的进入

可尝试的解决方法一：系统根 “/” 目录不使用由多个硬盘组合而成的逻辑卷

（步骤略）

可尝试的解决方法二：将系统根 “/” 目录的挂载格式写成 /dev/mapper/<volume group>-<logical volume>

步骤一：将系统根 “/” 目录的挂载格式写成 /dev/mapper/<volume group>-<logical volume>

# vim /etc/fstab

（步骤略）

步骤二：重新制作 initrd，让修改后的挂载格式在 initrd（dracut）引导时生效

# mkinitrd

可尝试的解决方法三：延长系统等待 initrd 的时间上限

步骤一：修改 /ETC/DEFAULT/GRUB 配置文件

# vim /etc/default/grub

在这一行里：

GRUB_CMDLINE_LINUX="......"

添加：

GRUB_CMDLINE_LINUX="...... systemd.default_timeout_start_sec=500s"

（补充：这里以将系统等待 initrd 的时间限延长到 500 秒为例）

步骤二：使刚刚的修改生效

# grub2-mkconfig -o /boot/grub2/grub.cfg

参考文献：

Linux 启动顺序

May 13, 2023June 3, 2024

[步骤] Linux 救援模式的进入

步骤一：挂载官方镜像

（步骤略）

步骤二：登录拯救模式

2.1 选择通过光盘启动

（步骤略）

2.2 进入拯救模式

（步骤略）

2.3 登录拯救模式

rescue login:root

步骤三：在救援模式确定系统的根 “/” 目录分区

（步骤略）

（
补充：
1) 物理分区可以使用 lsblk 命令、fdisk -l 或 cat /proc/partitions 命令辅助确定
2) 逻辑分区还可以可以使用 pvs 命令、lvs 命令或 lvdisplay 命令辅助确定
）

步骤四：在救援模式将系统的分区挂载到救援模式的 /mnt 目录

4.1 在救援模式将系统的根 “/” 分区挂载到救援模式的 /mnt 目录

tty1:rescue:~ # mount <root spartition> /mnt

（
补充：
1) 如果是物理分区，系统的根 “/” 分区就在救援模式的 /dev/ 目录里，例如救援模式的 /dev/sda1
2) 如果是逻辑分区，Rocky Linux & RHEL 的系统根 “/” 分区就是救援模式里的 /dev// 例如救援模式里的 /dev/vg/lv，openSUSE & SLES 的系统 “/” 分区就是救援模式里的 /dev/mapper/- 例如救援模式里的 /dev/mapper/vg-lv
）

4.2 在救援模式将救援模式的 /dev 目录关联到救援模式的 /mnt/dev 目录

tty1:rescue:~ # mount --rbind /dev /mnt/dev

（
补充：
1) 此时所有对救援模式的 /mnt/dev 目录的访问都会变成对救援模式的 /dev 目录的访问
2) 步骤 4.2、步骤 4.3 和步骤 4.4 也可以用以下命令代替：

tty1:rescue:~ # for i in proc sys dev; do mount --rbind /$i /mnt/$i ; done

）

4.3 在救援模式将救援模式的 /proc 目录关联到救援模式的 /mnt/proc 目录

tty1:rescue:~ # mount --rbind /proc /mnt/proc

（
补充：
1) 此时所有对救援模式的 /mnt/proc 目录的访问都会变成对救援模式的 /proc 目录的访问
2) 步骤 4.2、步骤 4.3 和步骤 4.4 也可以用以下命令代替：

tty1:rescue:~ # for i in proc sys dev; do mount --rbind /$i /mnt/$i ; done

）

4.4 在救援模式将救援模式的 /sys 目录关联到救援模式的 /mnt/sys 目录

tty1:rescue:~ # mount --rbind /sys /mnt/sys

（
补充：
1) 此时所有对救援模式的 /mnt/sys 目录的访问都会变成对救援模式的 /sys 目录的访问
2) 步骤 4.2、步骤 4.3 和步骤 4.4 也可以用以下命令代替：

tty1:rescue:~ # for i in proc sys dev; do mount --rbind /$i /mnt/$i ; done

）

4.5 在救援模式将救援模式的 /run 目录关联到救援模式的 /mnt/run 目录（选做）

tty1:rescue:~ # mount --rbind /run /mnt/run

（补充：此时所有对救援模式的 /mnt/run 目录的访问都会变成对救援模式的 /run 目录的访问）

步骤五：将当前的根 “/” 目录从救援模式的根 “/” 目录切换到系统的根 “/” 目录

5.1 将当前的根 “/” 目录从救援模式的根 “/” 目录切换到系统的根 “/” 目录

tty1:rescue:~ # chroot /mnt

（补充：这里以 /mnt 作为系统根 “/” 目录为例）

5.2 在系统模式挂载所有需要开机自动挂载的目录

bash-4.3# mount -a

5.3 在系统模式确认当前根 “/” 目录下的目录

bash-4.3# ls
bin boot dev home lib lib64 mnt opt proc root run sbin selinux srv sys tmp usr var

（补充：这里显示的是常见的 Linux 根 “/” 目录下的目录）

步骤六：重启系统

6.1 从当前系统的根 “/” 目录切换回救援模式的根 “/” 目录

bash-4.3# exit

6.2 重启系统

tty1:rescue:~ # reboot

内容一：SSH ECDSA 码介绍

1.1 什么是 ECDSA 码

1.2 SSH ECDSA 码存放位置

内容二：管理 SSH ECDSA 码

2.1 查看 SSH 服务端的 SSH ECDSA 码

2.2 将现在 SSH 服务端的 SSH ECDSA 码替换记录里的 SSH ECDSA 码

2.2.1 通过使用 ssh-keygen 命令将现在 SSH 服务端的 SSH ECDSA 码替换记录里的 SSH ECDSA 码

2.2.2 通过修改 ~/.ssh/known_hosts 配置文件将现在 SSH 服务端的 SSH ECDSA 码替换记录里的 SSH ECDSA 码

2.3 在本服务器上生成新的 SSH ECDSA 码

步骤一：设置 SSH 访问限制

步骤二：重启 SSH 服务

正文：

步骤一：启用 UseTCPWrappers 参数

步骤二：设置 SSH 访问限制

2.1 禁止来自所有 IP 地址的所有用户可以 SSH 本服务器

2.2 只允许某些用户可以 SSH 本服务器

步骤三：重启 SSH 服务

参考文献：

报错代码

分析

注意：当无法正常进入系统时可以进入救援模式后再使用可尝试的解决方法尝试解决问题

可尝试的解决方法一：系统根 “/” 目录不使用由多个硬盘组合而成的逻辑卷

可尝试的解决方法二：将系统根 “/” 目录的挂载格式写成 /dev/mapper/<volume group>-<logical volume>

步骤一：将系统根 “/” 目录的挂载格式写成 /dev/mapper/<volume group>-<logical volume>

步骤二：重新制作 initrd，让修改后的挂载格式在 initrd（dracut）引导时生效

可尝试的解决方法三：延长系统等待 initrd 的时间上限

步骤一： 修改 /ETC/DEFAULT/GRUB 配置文件

步骤二：使刚刚的修改生效

参考文献：

步骤一：挂载官方镜像

步骤二：登录拯救模式

2.1 选择通过光盘启动

2.2 进入拯救模式

2.3 登录拯救模式

步骤三：在救援模式确定系统的根 “/” 目录分区

步骤四：在救援模式将系统的分区挂载到救援模式的 /mnt 目录

4.1 在救援模式将系统的根 “/” 分区挂载到救援模式的 /mnt 目录

4.2 在救援模式将救援模式的 /dev 目录关联到救援模式的 /mnt/dev 目录

4.3 在救援模式将救援模式的 /proc 目录关联到救援模式的 /mnt/proc 目录

4.4 在救援模式将救援模式的 /sys 目录关联到救援模式的 /mnt/sys 目录

4.5 在救援模式将救援模式的 /run 目录关联到救援模式的 /mnt/run 目录 （选做）

步骤五：将当前的根 “/” 目录从救援模式的根 “/” 目录切换到系统的根 “/” 目录

5.1 将当前的根 “/” 目录从救援模式的根 “/” 目录切换到系统的根 “/” 目录

5.2 在系统模式挂载所有需要开机自动挂载的目录

5.3 在系统模式确认当前根 “/” 目录下的目录

步骤六：重启系统

6.1 从当前系统的根 “/” 目录切换回救援模式的根 “/” 目录

6.2 重启系统

步骤一：修改 /ETC/DEFAULT/GRUB 配置文件

4.5 在救援模式将救援模式的 /run 目录关联到救援模式的 /mnt/run 目录（选做）