当前位置：首页 > article >正文

RHCE笔记-SSH服务

article 2024/10/24 1:35:07

一.对称加密与非对称加密

1.1对称加密

1. 原理

对称加密是指加密和解密使用相同的密钥。也就是说，发送方和接收方在通信之前需要共享一个秘密密钥，使用这个密钥对数据进行加密和解密。

2. 常见算法

AES (Advanced Encryption Standard)：广泛使用的对称加密标准。
DES (Data Encryption Standard)：较老的标准，现已被 AES 替代。
3DES (Triple DES)：对 DES 的改进版，通过三次加密增加安全性。
RC4：一种流加密算法，速度快但存在安全漏洞。

3. 优点

速度快：对称加密的加密和解密速度较快，适合处理大量数据。
实现简单：相对容易实现和部署。

4. 缺点

密钥分发问题：密钥必须安全地传递给通信双方，如何安全地分发密钥是一个难题。
密钥管理复杂：随着用户数量的增加，需要管理的密钥数量也急剧增加，容易出现安全隐患。

5. 应用场景

数据库加密：保护存储在数据库中的敏感数据。
硬盘加密：对整个硬盘或特定文件进行加密保护。
通信协议：如 SSL/TLS 中的会话加密。

1.2非对称加密

1. 原理

非对称加密使用一对密钥：公钥和私钥。公钥可以公开，任何人都可以使用它来加密数据；而私钥则必须保密，只有密钥的拥有者才能使用它解密数据。加密后的数据只能用相应的私钥解密。

2. 常见算法

RSA (Rivest-Shamir-Adleman)：最广泛使用的非对称加密算法。
DSA (Digital Signature Algorithm)：主要用于数字签名。
ECC (Elliptic Curve Cryptography)：基于椭圆曲线数学，提供更高的安全性和效率。

3. 优点

密钥分发安全：公钥可以公开，避免了密钥分发的风险。
身份验证：非对称加密可以用来验证发送者的身份（数字签名）。

4. 缺点

速度慢：非对称加密的加密和解密速度较慢，不适合大量数据的加密。
计算复杂：相较于对称加密，非对称加密的计算开销更大。

5. 应用场景

数字签名：确保数据的完整性和来源。
安全邮件：如 PGP（Pretty Good Privacy）等邮件加密工具。
SSL/TLS 握手：用于安全网站的证书交换和密钥协商。

1.3对称加密与非对称加密的结合

在实际应用中，对称加密和非对称加密常常结合使用，以发挥各自的优势。例如，在 SSL/TLS 协议中，非对称加密用于安全地交换对称加密密钥，而后续的实际数据传输则使用对称加密，以提高效率。

总结

对称加密适合大规模数据的快速加密，但密钥管理和分发是其主要挑战。
非对称加密则解决了密钥分发的问题，提供了身份验证的能力，但速度较慢，适合少量数据或密钥交换。

二.SSH-client连接SSH-server过程

版本号协商阶段，SSH目前包括 SSH1和SSH2两个版本，双方通过版本协商确定使用的版本
密钥和算法协商阶段，SSH支持多种加密算法，双方根据本端和对端支持的算法，协商出最终使用的算法
认证阶段，SSH客户端向服务器端发起认证请求，服务器端对客户端进行认证
会话请求阶段，认证通过后，客户端向服务器端发送会话请求
交互会话阶段，会话请求通过后，服务器端和客户端进行信息的交互

2.1 版本号协商阶段

服务器打开端口 22，等待客户端连接。
客户端向服务器端发起 TCP初始连接请求，TCP连接建立后，服务器向客户端发送第一个报文，包括版本标志字符串，格式为“SSH－<主协议版本号>.<次协议版本号>－<软件版本号>”，协议版本号由主版本号和次版本号组成，软件版本号主要是为调试使用。
客户端收到报文后，解析该数据包，如果服务器端的协议版本号比自己的低，且客户端能支持服务器端的低版本，就使用服务器端的低版本协议号，否则使用自己的协议版本号。
客户端回应服务器一个报文，包含了客户端决定使用的协议版本号。服务器比较客户端发来的版本号，决定是否能同客户端一起工作。
如果协商成功，则进入密钥和算法协商阶段，否则服务器端断开 TCP连接。

Note：版本号协商阶段报文都是采用明文方式传输的。

2.2密钥和算法协商阶段

服务器端和客户端分别发送算法协商报文给对端，报文中包含自己支持的公钥算法列表、加密算法列表、MAC（Message Authentication Code，消息验证码）算法列表、压缩算法列表等;
服务器端和客户端根据对端和本端支持的算法列表得出最终使用的算法。
服务器端和客户端利用 DH交换（Diffie-Hellman Exchange）算法、主机密钥对等参数，生成会话密钥和会话 ID。

通过以上步骤，服务器端和客户端就取得了相同的会话密钥和会话ID。

对于后续传输的数据，两端都会使用会话密钥进行加密和解密，保证了数据传送的安全
在认证阶段，两端会使用会话 ID用于认证过程。

Note：

在协商阶段之前，服务器端已经生成 RSA或 DSA密钥对，他们主要用于参与会话密钥的生成。

2.3 认证阶段

客户端向服务器端发送认证请求，认证请求中包含用户名、认证方法、与该认证方法相关的内容（如：password认证时，内容为密码）。
服务器端对客户端进行认证，如果认证失败，则向客户端发送认证失败消息，其中包含可以再次认证的方法列表。
客户端从认证方法列表中选取一种认证方法再次进行认证。
该过程反复进行，直到认证成功或者认证次数达到上限，服务器关闭连接为止。

SSH提供两种认证方式：

password认证：客户端向服务器发出 password认证请求，将用户名和密码加密后发送给服务器；

服务器将该信息解密后得到用户名和密码的明文，与设备上保存的用户名和密码进行比较，并返回认证成功或失败的消息。

publickey 认证：采用数字签名的方法来认证客户端。

目前，设备上可以利用RSA和 DSA两种公共密钥算法实现数字签名。

客户端发送包含用户名、公共密钥和公共密钥算法的 publickey 认证请求给服务器端。

服务器对公钥进行合法性检查，如果不合法，则直接发送失败消息；

否则，服务器利用数字签名对客户端进行认证，并返回认证成功或失败的消息

2.3.1数字签名

注:如何利用数字签名认证,服务器使用协商的对称密钥,以及客户端发送的公钥加密一段随机字符串,发送给客户端,客户端解密后发送给服务器端,相同则通过,不相同则失败,直到达到次数上限断开连接

SSH2.0还提供了 password-publickey 认证和 any 认证:

password-publickey 认证：指定该用户的认证方式为 password 和 publickey认证同时满足。

客户端版本为 SSH1的用户只要通过其中一种认证即可登录；客户端版本为 SSH2的用户必须两种认证都通过才能登录。

any认证：指定该用户的认证方式可以是 password，也可以是 publickey。

2.4会话请求阶段

服务器等待客户端的请求；
认证通过后，客户端向服务器发送会话请求；
服务器处理客户端的请求。请求被成功处理后，服务器会向客户端回应 SSH_SMSG_SUCCESS包，SSH进入交互会话阶段；否则回应 SSH_SMSG_FAILURE包，表示服务器处理请求失败或者不能识别请求。

2.5交互会话阶段

在这个模式下，数据被双向传送：

客户端将要执行的命令加密后传给服务器;
服务器接收到报文，解密后执行该命令,将执行的结果加密发还给客户端;
客户端将接收到的结果解密后显示到终端上.

三.SSH服务配置

3.1开启root用户登录权限

1.修改ssh配置文件

[root@server ~]# vim /etc/ssh/sshd_config

2.修改下列配置行,改为yes,并开启

PermitRootLogin yes

3.重启ssh服务

[root@server ~]# systemctl restart ssh

注:在rhel-9以后版本安装时若未开启,该选项的默认设置是禁止,Ubuntu中则相同,禁止登录

3.2修改使用端口

1.修改配置文件

[root@server ~]# vim /etc/ssh/sshd_config

2.修改下列行为对应端口行

Port 22

3.修改selinux状态

Enforcing：强制执行策略，阻止不符合策略的操作。
Permissive：不阻止任何操作，但记录违反策略的行为。
Disabled：完全禁用 SELinux。

临时更改状态

setenforce 1  # 设置为 Enforcing
setenforce 0  # 设置为 Permissive

永久更改模式（重启后生效）：编辑 SELinux 配置文件：

sudo vi /etc/selinux/config

找到以下行并修改为所需模式：

SELINUX=enforcing # 或 permissive 或 disabled

查看当前seLinux状态

setatus

使用命令查看对应服务的规则

getsebool -a | grep httpd

3.3开启密码认证+密钥认证+修改密钥存储路径

1.开启密钥认证

PubkeyAuthentication yes

2.开启密码认证

PasswordAuthentication yes

3.修改密钥存储路径

AuthorizedPrincipalsFile %h/.ssh/authorized_keys

注;这里%h取代了~,表示工作主目录

~是一个shell特性,可能不会被ssh_config所理解,所以这里是运用了一个宏规则,类似的还有

常见的 OpenSSH 宏

%u：
- 表示当前用户的用户名。
- 示例：AuthorizedKeysFile %h/.ssh/authorized_keys 可以用 %u 表示用户名，例如 user。
%h：
- 表示当前用户的主目录.
%d：
- 表示用户的家目录的完整路径（与 %h 相同）。
- 用法类似于 %h。
%p：
- 表示当前连接的端口号。
- 可以在特定配置中使用，例如限制某个用户在特定端口上的登录。
%r：
- 表示当前连接的远程主机名或 IP 地址。
- 可用于日志记录或访问控制。
%l：
- 表示当前连接的主机名。
- 在多主机环境下特别有用。

总的来说,宏规则的出现就像是编程语言中的变量,当一些反复会出现的量出现更改时,可以极大的减少工作量.

3.4关于~/.ssh/下的配置文件

[root@server .ssh]# ls -al
总用量 24
drwx------.  2 root root  103 10月 19 11:42 .
dr-xr-x---. 16 root root 4096 10月 20 16:59 ..
-rw-------.  1 root root 1145 10月 19 11:43 authorized_keys
-rw-------.  1 root root 2602 10月 19 11:42 id_rsa
-rw-r--r--.  1 root root  565 10月 19 11:42 id_rsa.pub
-rw-------.  1 root root 1504 10月 19 11:42 known_hosts
-rw-------.  1 root root  760 10月 19 11:42 known_hosts.old

authorized_keys
- 说明：该文件存储了允许访问该用户账户的公钥列表。当用户尝试通过 SSH 连接到服务器时，系统会检查他们提供的私钥是否与此文件中列出的公钥相匹配。
- 权限：通常设置为 600（即 rw-------），表示只有文件所有者可以读写。
id_rsa
- 说明：这是用户的私钥文件。私钥用于身份验证，应该严格保密，任何人都不应能访问此文件。
- 权限：设置为 600，确保只有文件所有者可以读写。
id_rsa.pub
- 说明：这是用户的公钥文件。它可以被分享给任何人，并且通常会添加到其他系统的 authorized_keys 文件中，以便允许使用相应私钥的用户访问。
- 权限：一般设置为 644（即 rw-r--r--），允许所有人读取，但只有所有者可以写入。
known_hosts
- 说明：该文件保存了已知的 SSH 服务器的公钥信息。每当用户首次连接到新的 SSH 服务器时，系统会询问用户是否信任该服务器并保存其公钥，以防止中间人攻击。以后的连接会通过此文件中的公钥验证服务器身份。
- 权限：通常设置为 600，确保只有文件所有者可以读写。
known_hosts.old
- 说明：这是 known_hosts 文件的备份副本。SSH 客户端在更新 known_hosts 时，可能会将旧的条目保存到此文件中，以便恢复。
- 权限：通常也设置为 600。