SSH远程管理工具
一、概述
ssh服务，一种远程管理连接工具，在CentOS7系统中默认安装并开机自启的。
SSH（Secure Shell）是一种安全通道协议，主要用来实现字符界面的远程登录，远程复制等功能。
监听tcp的22号端口。软件包名称：openssh
配置文件目录：/etc/ssh，sshd_config 服务端配置文件；ssh_config 客户端配置文件。
客户端提供：ssh、scp、sftp命令
服务端提供：sftp服务、ssh服务
二、 配置文件
服务端配置文件： sshd_config
Port 22 #监听端口
AddressFamily any #ip地址版本
ListenAddress 0.0.0.0 #监听地址，ipv4
ListenAddress :: #监听地址，ipv6
PermitRootLogin yes #是否允许root用户登录
MaxAuthTries 6 #重新连接最大次数
MaxSessions 10 #建立不同用户的会话的最大个数
PubkeyAuthentication yes #是否启用公钥对验证登录
AuthorizedKeysFile .ssh/authorized_keys #存储客户端公钥信息的文件
PasswordAuthentication yes #是否启用密码验证登录
PermitEmptyPasswords no #是否允许空密码登录
UsePAM yes #启用系统用户及密码进行验证登录
UseDNS no #是否启用ssh内部的解析，会影响连接速度客户端配置文件： ssh_config，设置ssh命令连接的关键配置
Port 22 #设置ssh命令连接的默认端口三、命令解析
###远程登录命令###
###语法:####
ssh [选项] [username@]ssh服务器的监听IP地址或者主机名(使用主机名时，保证客户端能够解析主机名)
####选项：######
-p port 指定连接服务器的监听端口
###远程拷贝命令####
###语法:####
##将本机的文件拷贝到远程主机##
scp 本机的文件路径 [username@]ssh服务器的监听IP地址或者主机名:/远程主机存储路径
##将远程主机的文件拷贝到本机##
scp [username@]ssh服务器的监听IP地址或者主机名:/远程主机存储路径 本机的文件路径
###sftp服务登录命令###
sftp [选项] [username@]ssh服务器的监听IP地址或者主机名(使用主机名时，保证客户端能够解析主机名)四、登录方式配置
1、用户名密码登录
默认方式，直接可以使用
2、公钥验证登录
密码学基础：
| 概念 | 解析 |
|---|---|
| 对称加密 | 双方采用相同的秘钥，安全性较低 |
| 非对称加密 | 双方采用不同的秘钥，安全性较高 |
| 公钥 | 大家都可以知道的秘钥。 |
| 私钥 | 只有自己知道的秘钥。能够证明自己的身份信息 |
<p style="color: red"> 注意：公钥和私钥不能相互推导！！！</p>
公钥与私钥之间能够相互解密！！！
数据加密：
使用对端的公钥加密，接收端收到数据后，使用自己的私钥解密。作用是保证数据完整性。
数字签名：
私用自己的私钥加密，接收端收到数据后，使用发送端的公钥解密。作用是保证发送者的身份唯一性。
ssh客户端生成密钥对
###生成密钥对的命令###
ssh-keygen ，默认是交互式
###常用选项：####
-t ： 指定秘钥算法
-N ： 指定秘钥短语
-f ： 指定秘钥存储路径
[root@s1 .ssh]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
###非交互生成密钥对####
[zhx1@s1 ~]$ ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa
###默认保存到当前执行该命令的用户家目录中的.ssh目录#####
[root@s1 .ssh]# ls
id_rsa id_rsa.pub
###id_rsa: 私钥；id_rsa.pub： 公钥###
###拷贝公钥命令###
ssh-copy-id
###ssh命令的特殊用法：远程执行ssh服务器的指令####
[root@s1 .ssh]# ssh 192.168.115.128 ip a
##注意：不能执行ssh-copy-id命令####五、实操
客户端使用user1用户，并且以服务端的用户user2的身份登录，使用公钥对验证登录。
一、核心原理：公钥密码体系的 “身份绑定”
非对称加密有一对互补的密钥：
私钥（Private Key）：仅归用户本人所有（如 user2 的私钥仅存于 user2 信任的设备 / 安全存储中），绝对保密，用于 “签名”（证明 “我是我”）。
公钥（Public Key）：可公开分发（如 user2 的公钥提前存储在服务端，或通过可信渠道提供给客户端），用于 “验证签名”（确认签名来自私钥持有者）。
登录验证的本质是：客户端用 user2 的私钥对 “身份信息” 签名，服务端用 user2 的公钥验证签名 —— 若验证通过，证明客户端签名 —— 若验证通过，证明客户端确实拥有 user2 的私钥，即合法的 user2 身份（客户端自身以 user1 操作，不影响服务端对 “登录身份 = user2” 的验证）。
二、完整登录流程（7 步闭环）
假设前提：服务端已提前存储 user2 的公钥（Pub2）（可通过 “用户注册时上传公钥”“服务端生成密钥对后下发公钥” 两种方式预先配置），客户端已安全持有 user2 的私钥（Pri2）（需通过安全渠道获取，如 user2 授权导出、硬件密钥存储等）。
流程步骤如下：
客户端发起登录请求（user1 操作）
客户端以 user1 身份发起 “登录服务端 user2 账户” 的请求，向服务端发送基础身份标识：{登录用户名: user2, 客户端标识: user1}（告知服务端 “要登录哪个账户，由哪个客户端操作”）。服务端生成 “随机挑战值”（防重放攻击）
服务端为防止 “攻击者截取历史登录信息重复使用”，生成一个随机、唯一、时效性的挑战值（Challenge）（如 32 位随机字符串），并将其返回给客户端，同时记录 “挑战值 - 用户 user2 - 请求时间” 的关联关系（设置过期时间，如 30 秒）。客户端用 user2 的私钥签名 “身份 + 挑战值”
客户端将 “固定身份信息（user2 用户名）+ 服务端返回的挑战值” 拼接成 “待签名数据”（如user2_202409181530_abc123def），然后使用user2 的私钥（Pri2） 对该数据进行 “数字签名”，生成签名结果（Signature）。此时客户端向服务端发送 “验证数据包”：
{登录用户名: user2, 客户端标识: user1, 待签名数据: [user2+挑战值], 数字签名: Signature}服务端提取 user2 的公钥并验证签名
服务端收到数据包后，执行 3 个关键校验：校验 “挑战值有效性”：确认该挑战值是服务端刚才发给该客户端的、且未过期（防止重放）；
提取公钥：从服务端存储中取出 user2 对应的公钥（Pub2）；
验证签名：用 Pub2 对 “待签名数据” 进行 “签名验证”—— 若公钥能成功解密签名、且解密结果与 “待签名数据” 完全一致，则签名有效。
服务端判断登录结果并返回
若签名验证通过 + 挑战值有效：判定 “客户端拥有 user2 的合法私钥”，允许以 user2 身份登录，返回 “登录成功” 及后续会话凭证（如 Session ID、JWT Token）；
若验证失败（签名不匹配 / 挑战值过期）：返回 “登录失败”，拒绝登录（不告知具体失败原因，防止攻击者试探）。
客户端（user1）使用 user2 的会话访问服务端
登录成功后，客户端后续向服务端发起的请求（如查询 user2 的数据、执行 user2 的权限操作），需携带服务端返回的会话凭证；服务端通过凭证识别 “当前会话属于 user2”，按 user2 的权限处理请求（客户端操作主体仍是 user1，但服务端授权基于 user2）。会话过期 / 销毁（安全收尾）
会话凭证设置过期时间（如 2 小时），超时后客户端需重新执行上述公钥验证流程；若 user1 主动退出登录，客户端销毁本地会话凭证，服务端标记该凭证失效。
三、关键技术细节与安全注意事项
1. 密钥的安全存储（核心风险点）
私钥（Pri2）不能明文存储：客户端需将 Pri2 存储在安全介质中，如：
移动端：系统安全区域（iOS 的 Keychain、Android 的 Keystore）；
桌面端：硬件加密模块（HSM）、USB 密钥（如 U 盾、YubiKey）；
绝对禁止：明文写在代码、配置文件或普通本地文件中（防止被窃取）。
公钥（Pub2）的可信分发：服务端存储的 Pub2 需确保是 user2 本人提供的（如注册时通过 HTTPS 上传，或线下通过可信渠道录入），避免 “公钥被篡改” 导致验证失效。
2. 防攻击设计
防重放攻击：必须加入 “挑战值（Challenge）” 或 “时间戳（Timestamp）”—— 攻击者即使截取到 “签名数据”，因挑战值已过期或时间戳不匹配，无法重复使用。
防篡改攻击：待签名数据必须包含 “用户身份 + 唯一标识（挑战值 / 时间戳）”，确保攻击者无法修改 “待签名数据”（如把 “user2” 改成 “user3”）—— 修改后签名验证会失败。
签名算法选择：推荐使用椭圆曲线加密（ECC，如 secp256r1） 或RSA（2048 位以上），前者密钥长度短、性能高，后者兼容性强；避免使用弱算法（如 SHA-1 签名）。
3. “客户端 user1” 与 “登录身份 user2” 的权限隔离
服务端需明确：“客户端操作主体（user1）” 和 “登录账户权限（user2）” 是两个维度 —— 客户端的操作行为（如发起请求的 IP、设备）可记录用于审计，但服务端仅根据 user2 的权限判断 “是否允许该操作”（如 user2 有 “查看订单” 权限，即使 user1 操作，服务端也允许）。
建议增加 “操作审计日志”：记录 “user1（客户端标识）以 user2 身份执行了 XX 操作”，便于后续溯源（如出现安全问题时定位责任）。
四、典型应用场景
该模式常见于 “代操作 + 高安全认证” 场景，例如：
企业员工（user1）使用老板（user2）的账户登录财务系统审批文件，需老板提前将私钥授权给员工的安全设备；
家庭共享场景中，子女（user1）用父母（user2）的账户登录会员平台，通过父母的公钥验证确保身份合法性。