SSH原理与实践(一)
主页
- 个人微信公众号:密码应用技术实战
- 个人博客园首页:https://www.cnblogs.com/informatics/
引言
在日常开发和运维中,我们时常需要通过SSH登录远程主机,进行一些运维管理操作。SSH可以在提供了一种在不安全网络
安全访问
远程计算机的方式。
由于本人在日常办公中也经常用到SSH, 出于对SSH工作原理的好奇,查看了大量的中英文资料,发现大多数中文资料对SSH原理介绍不够清楚且存在诸多错误。
写作本文主要出于两个目的:
- 对自己查看的英文资料的汇总
- 希望给大家带来ssh工作原理相关的更准确的介绍
本文内容组织如下:
- 什么是SSH
- SSH口令认证
- SSH公钥认证
什么是SSH
SSH,也称为Secure Shell或Secure Socket Shell,是一种网络协议
,为用户(特别是系统管理员)提供了在不安全网络上安全访问
计算机的方式。SSH提供了密码身份验证、公钥身份验证等多种方式,并广泛用于网络管理员远程管理系统和应用程序,使他们能够通过网络登录到另一台计算机,执行命令并在计算机之间传输文件。
SSH采用客户端-服务器
模型,包含一个SSH客户端(用于显示会话的一端)和一个SSH服务端(用于运行会话的一端)。默认情况下,SSH服务器监听端口22。
SSH口令认证
我们在使用SSH客户端Client
访问远程SSH服务Sever
时,服务器需要对客户端进行身份认证(客户端认证
),其中最常见的就是口令认证模式
, 我们以登录远程服务器
为例,口令认证模式流程如下:
建立安全通道
用户在客户端使用ssh root@host
登录服务器时,ssh首先会建立安全通道
, 建立安全通道主要有两个目的:
- 客户端对服务端进行认证(
服务端认证
) - 客户端与服务器协商会话密钥,用于后续通信加密,保证通信安全性
在客户端对服务端进行初次认证
时,客户端通常会进行提示,需要由用户去人工确认访问的服务器fingerprint是否可信:
➜ ~ ssh root@my-ssh-server
The authenticity of host 'my-ssh-server (192.168.1.11)' can't be established.
ED25519 key fingerprint is SHA256:M37JXY37sYNyoE9KujJlTxXs3NO8D7pzEMQirwD6if0.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:9: 192.168.1.11
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'my-ssh-server' (ED25519) to the list of known hosts.
Welcome to OS 3 64bit
Version 3.1 20221031
用户选择YES
后,服务端身份会被保存到客户端~/.ssh/known_hosts
文件中,下次再登录时,需要在文件中进行匹配,无需用户在客户端再次进行确认。保存格式如下:
192.168.1.11 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGwnWKZECb3nZINMvaYiFLhmlu9wnEtomHb1U7SDQOZ7
- 服务端ip地址
- 服务端公钥对应的密码算法
- 服务端公钥
口令认证流程
在客户端和服务端建立安全通道后,客户端会将用户口令
发送给服务端, 服务端对用户口令进行验证,具体的验证流程与具体的操作系统有关,在linux
系统中一种常见的验证流程如下:
- 从
/etc/shadow
读取用户密码(这里的密码一般都经过加密处理,通常是哈希加盐
的方式) - 将从客户端收到的
用户明文密码
进行哈希加盐处理,并与上步骤得到的进行比对,如果相同,则验证通过
SSH公钥认证
口令认证方式有以下几个缺点:
- 安全性较差,在服务器被攻击的情况下,用户口令将会被获取
- 每次访问服务器,需要用户输入口令,不便利
而ssh公钥认证
很好的解决了以上两个问题,在公钥认证模式下:
- 用户口令不需要发送到服务器,因此即使服务器被攻击,也不会泄露敏感信息
- 客户端认证借助了密码技术,通过数字签名-验证技术自动完成,不再需要用户频繁输入口令
由于用户登录不再使用口令,因此使用公钥认证
方式进行远程服务器的登录,我们称之为免密登录
。公钥认证模式流程如下:
准备阶段
公钥认证模式需要有个准备阶段(初始化阶段),该阶段主要是将客户端ssh公钥
保存到服务器上,作为客户端身份
的一部分, 用于:
- 客户端身份检查
- 用于后面流程中,对challenge进行加密(这样仅用于对应私钥的客户端可以解密得到明文的challenge)
ssh提供了ssh-copy-id
命令来方便用户将客户端公钥部署到服务端:
➜ ~ ssh-copy-id root@192.168.1.11
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/hxy/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@82.157.36.61's password:
值得注意的是,该命令需要输入口令进行认证,通过后服务端会自动将客户端ssh公钥
保存到~/.ssh/authorized_keys
文件中。保存格式如下:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDlc...省略...aM= hxy@HXY-MB1
其中,三个字段的含义:
- 客户端公钥对应的密码算法
- 客户端公钥
- 客户端对应的用户名和主机名
建立安全通道
与口令认证中的流程相同,不再赘述
公钥认证流程
在公钥认证流程中,主要包含以下几个步骤:
- 客户端发送自己的ssh公钥
- 服务端收到后与
准备阶段
事先保存的进行匹配。如果成功则生成随机字符串, 并使用客户端公钥加密发送给客户端(该随机字符串一般称为challenge-挑战码
) - 客户端解密得到challenge,并计算哈希值(这里参与计算哈希值的还有其他信息,如会话ID等,为了方便,这里统一省略)
- 服务端计算challenge哈希值,并与从客户端收到的进行比对。如果验证通过,则表示认证成功。
需要注意的是,在第三步骤中,由于客户端收到的challenge是经过公钥加密的,通过密码学非对称加密的性质,只有对应的私钥能够解密。这里进一步保证了通信的安全性。
结论
本文详细介绍了SSH客户端认证的两种模式、以及相应的工作原理,通过本文希望读着对ssh工作原理有个简单的认识,并在工作中遇到相关问题知道如何去拍错和修复。
本文未详细介绍建立安全通道
流程,主要是因为SSH协议有两个大的版本SSH1和SSH2,这两个版本在该流程处理上存在较大的差异,因此本文对该流程进行了共性描述。
后续会单独通过一篇博文介绍这部分的详细流程以及不同版本的差异。