一次SSH公钥免密码登录实现的实践

笔者前面有一篇博文。标题应该是《了不起的SSH》,比较深入的探讨了SSH这个伟大的远程连接技术。但由于SSH涉及的内容实在是太过广泛,还有水平和篇幅的限制,在某些细节方面,在当时并没有深入细致的探讨。

最近笔者正好有机会使用一个远程的VPS系统,平台默认情况下,只提供了密钥登录的方式,同时虚拟机的默认配置,也支持公钥登录。所以在使用过程中,笔者有机会实践了自定义的公钥登录的过程,觉得又有新的理解和体验,有一些新鲜的东西,这里就著文记录和分享给读者。

基本过程

那个VPS系统的基本情况是这样的。在创建VPS的时候,不再需要设置用户名和密码,而是提供一个默认的非root账号,和生成密钥对的选项。生成密钥对后,平台系统会将这个账号的公钥,写入VPS系统,并且同时用户可以将对应的私钥PEM文件,下载到当前操作的管理计算机本地。然后,用户就可以使用这个私钥PEM文件,使用任意兼容的SSH客户端软件,建立SSH连接,但使用私钥登录的方式。

这个流程,和我们一般使用私钥登录的过程就不一样了。在那个过程中,我们一般会在本地,使用ssh-keygen命令,在本地生成一个密钥对,然后使用ssh-copyid命令,将其中的公钥,复制到远程系统,并进行相关的设置,后续的操作,就可以使用私钥直接进行登录了。

这两种方式,其实本质上是没有区别的,也各有各的优缺点。我们假设本地生成密钥对的场景为L,远程为R,它们的优缺点如下,其实就是安全和方便的差异:

  • L在理论上更安全一点,因为密钥生成过程在本地的用户环境中,在任何情况下都没有在其他系统或者网络中存储或者传输
  • L的操作更复杂,需要生成密钥对,并传输公钥到远程系统
  • L虽然在密钥角度更安全,但初始传输公钥,仍然需要使用密码进行登录,这是一个安全隐患或者不便的地方
  • R在使用的角度更方便,因为直接在远程系统已经自动配置好了用户的公钥,用户只需要下载和配置SSH连接的私钥就可以了
  • R可以方便在平台集的集中管理
  • 无论L或者R,它们的最终状态都是一样的

需求和问题

在了解了SSH私钥免密登录的一般过程之后,再来谈谈笔者遇到的问题。

除了在注册和管理VPS的系统(管理机和管理账号)之外,笔者另有一台开发用的计算机系统(开发机),需要连接到这个VPS(服务器)上进行工作和相关的操作。另外基于安全和业务方便的考虑,笔者还想要使用另外一个系统账号(开发账号)。这个时候就遇到了一些不便的地方。

当然,笔者可以使用管理机登录服务器,来创建这个开发账号。然后问题就来了,常规操作就是使用开发账号,在开发机上,生成密钥对,然后使用ssh-copyid和SSH登录服务器,将公钥复制到服务器上开发账号的用户环境中。但问题是服务器没有开放SSH密码登录,所以必须要设置SSH服务可以使用密码登录,然后才能进行登录操作,操作完成后,还需要关闭密码登录,这个操作还可能需要重启SSH服务,非常繁琐。

有没有更简单一点的方式? 答案是肯定的,笔者会在下面提供操作流程,但重点其实还是基于对SSH登录过程的原理性了解。我们先讨论操作,然后分析原理。

操作过程

基于对SSH登录过程的原理的理解,笔者针对这一需求,具体的解决方式和操作过程如下:

  • 在开发机上,在当前账号环境中,使用ssh-keygen命令,生成密钥对
powershell 复制代码
PS C:\Users\yanjh> ssh-keygen.exe -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (C:\Users\yanjh/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:\Users\yanjh/.ssh/id_ed25519.
Your public key has been saved in C:\Users\yanjh/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:B/grjkIz13PamFHy2cQJ14ALavib35LYYV69rQx0OFI yanjh@WK-YANJH-AMD
The key's randomart image is:
+--[ED25519 256]--+
|         ..o     |
|      ..o . .    |
|   . ...E= .     |
|  . o .ooo+      |
|   o ..+S=o      |
|  + o *o==o      |
| . + B.%o  o     |
|  . +oOo.o. .    |
|   ...o.. o.     |
+----[SHA256]-----+
PS C:\Users\yanjh> dir ~/.ssh
    Directory: C:\Users\yanjh\.ssh
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----          4/9/2024   4:49 PM            411 id_ed25519
-a----          4/9/2024   4:49 PM            101 id_ed25519.pub
-a----         2/18/2024   7:03 PM          10187 known_hosts
-a----         8/23/2022   1:36 PM           4726 known_hosts.old

这里这个密钥对,其实就是以id作为开头的两个文件,.pub就是公钥。生成密钥对是可以选择密钥类型的,默认是RSA,笔者这里使用ed25519椭圆曲线算法也是可以的。

  • 记录并复制公钥信息,简单而言,它是一段文本信息(base64)
powershell 复制代码
PS C:\Users\yanjh> cat C:\Users\yanjh\.ssh\id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDi/TpIw84Hi87E34tL9ePqgBm9tXOuKnMhey7wU0Pye yanjh@WK-YANJH-AMD

我们看到的这个格式就是三段,第一段是公钥类型,第二段是base64编码的内容,第三段是描述信息或者标识

  • 使用管理账号,在管理机上,使用私钥PEM文件和SSH远程登录服务器

  • 登录服务器后,创建开发账号,包括设置密码和主文件夹

  • 使用 su - 命令,切换到开发账号

  • 将开发账号公钥内容,注入到 ~/.ssh/authorized_keys

可以直接使用nano编辑文件,将公钥内容复制到最后。

  • 在开发机上,使用开发账号连接ssh

开发机上操作的本地账号名词和开发账号可以没有关系,因为在连接时,会指定连接用的账号,如:

ssh -v devuser@devserver

这里 -v 可以用于显示连接过程的调试信息,发现连接错误的位置和原因。如果一切正常的话,开发机就可以使用开发账号,直接登录服务器了。

基于这样一个操作过程,我们就可以简单的分析和理解SSH私钥免密登录的原理了。

免密连接过程和原理

为了更直观起见,这里的分析,主要来源于SSH连接过程的调试信息(稍微繁琐,但能看出其处理方式):

js 复制代码
 ssh 192.168.10.22 -v
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to 192.168.10.22 [192.168.10.22] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\yanjh/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_ed25519 type 3
debug1: identity file C:\\Users\\yanjh/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\yanjh/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.7
debug1: match: OpenSSH_9.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.10.22:22 as 'yanjh'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:thK7chc14GZeuCir7Auin4+mCR6P5mEWAz2DNrKvXT4
debug1: Host '192.168.10.22' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\yanjh/.ssh/known_hosts:50
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\yanjh/.ssh/id_rsa
debug1: Will attempt key: C:\\Users\\yanjh/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\yanjh/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\yanjh/.ssh/id_ed25519 ED25519 SHA256:B/grjkIz13PamFHy2cQJ14ALavib35LYYV69rQx0OFI
debug1: Will attempt key: C:\\Users\\yanjh/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com (unrecognised)
debug1: kex_input_ext_info: ping@openssh.com (unrecognised)
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\yanjh/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: C:\\Users\\yanjh/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\yanjh/.ssh/id_ecdsa
debug1: Offering public key: C:\\Users\\yanjh/.ssh/id_ed25519 ED25519 SHA256:B/grjkIz13PamFHy2cQJ14ALavib35LYYV69rQx0OFI
debug1: Server accepts key: C:\\Users\\yanjh/.ssh/id_ed25519 ED25519 SHA256:B/grjkIz13PamFHy2cQJ14ALavib35LYYV69rQx0OFI
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.10.22 ([192.168.10.22]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT is supported. Reading the VTSequence from console
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported. Console supports the ansi parsing
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/yanjh/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/yanjh/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Last login: Tue Apr  9 17:32:55 2024 from 192.168.10.209

这个过程大体可以分为下面几个阶段:

  • 连接准备和初始化

连接请求的命令中,包括了连接使用的账号和服务器地址。ssh客户端会连接服务器地址的ssh端口(默认为22),并建立TCP连接。

  • 建立安全通道

连接成功后,SSH服务器会向客户端提供服务器的公钥信息。如果客户端以前连接过服务器,它会和保存的服务器条目进行比较,如ip地址、主机名和公钥等信息;如果是全新的连接,客户端会在know_hosts中建立这个服务器的相关条目。所以如果在连接过程中,发生如"公钥变更"等错误信息,可以确定这个问题的话(如主机IP确实修改了),就可以从know_hosts文件中删除对应的条目,然后重新尝试连接。

公钥检查如果没有问题的话,客户端和服务器会使用非对称加密的方式,协商一个加密通道,后续的TCP数据,都可以进行加密传输了。

  • 密钥匹配

安全通道建立之后,服务器端会告知客户端可以使用的认证方式,如公钥,或者密码。如果确定使用公钥,服务端会检索登录用户主文件夹中的 .ssh/authorized_keys,找到用户公钥,并使用这个公钥加密一个随机信息,作为认证挑战发送给客户端。

客户端收到认证方式和挑战信息,看到需要使用公钥认证,则会在遍历当前用户的私钥文件,尝试使用它们对挑战信息进行解密,如果成功,则将解密结果返回给服务器。服务器检查解密结果,确认当前会话的用户确实持有用户公钥所对应的私钥,认证完成,SSH连接正式成功建立。

小结

理解了上述原理和过程,我们就可以很容易的理解前面的实践和操作过程,其实质就是利用了非对称加密的特性,在服务端保存公钥,在客户端保存对应的私钥。认证时,能够找到和使用对应的密钥对,来完成一个信息交互和验证的过程。当然,密钥保存的位置和方式,是事先约定好的,在客户端和服务端都有相应的设置和处理。了解了这些原理和细节,我们就可能可以不使用标准的流程(如不使用ssh-copyid命令),有些地方可以根据情况手动的进行处理,也可以达到相同的效果。

相关推荐
lldhsds几秒前
书生大模型实战营第四期-入门岛-1. Linux前置基础
linux
尚学教辅学习资料几秒前
基于SpringBoot的医药管理系统+LW示例参考
java·spring boot·后端·java毕业设计·医药管理
wowocpp23 分钟前
ubuntu 22.04 硬件配置 查看 显卡
linux·运维·ubuntu
山河君35 分钟前
ubuntu使用DeepSpeech进行语音识别(包含交叉编译)
linux·ubuntu·语音识别
鹏大师运维39 分钟前
【功能介绍】信创终端系统上各WPS版本的授权差异
linux·wps·授权·麒麟·国产操作系统·1024程序员节·统信uos
筱源源42 分钟前
Elasticsearch-linux环境部署
linux·elasticsearch
monkey_meng1 小时前
【Rust中的迭代器】
开发语言·后端·rust
余衫马1 小时前
Rust-Trait 特征编程
开发语言·后端·rust
monkey_meng1 小时前
【Rust中多线程同步机制】
开发语言·redis·后端·rust
pk_xz1234563 小时前
Shell 脚本中变量和字符串的入门介绍
linux·运维·服务器