SSH

sh-keygen命令

用于为“ssh”生成、管理和转换认证密钥，它支持RSA和DSA两种认证密钥。

选项 说明
-b 指定密钥的位大小，例如2048或4096位
-t 指定密钥的类型，常见的有rsa、dsa、ecdsa或ed25519
-C 为密钥添加一个注释信息
-f 指定生成密钥文件的文件名
-N 提供一个新密钥的密码短语
-p 更改私钥的密码短语
-q 安静模式，不输出任何信息
-m 指定私钥导出格式
-l 显示公钥文件的指纹数据

ssh非对称加密

对称加密：

加密和解密使用一样的算法，只要解密时提供与加密时一致的密码就可以完成解密。例如QQ登录密码，银行卡密码，只要保证密码正确就可以。

非对称加密：

通过公钥(public key)和私钥(private key)来加密、解密。公钥加密的内容可以使用私钥解密，私钥加密的内容可以使用公钥解密。一般使用公钥加密，私钥解密，但并非绝对如此，例如CA签署证书时就是使用自己的私钥加密。在接下来介绍的SSH服务中，虽然一直建议分发公钥，但也可以分发私钥。

所以，如果A生成了(私钥A，公钥A)，B生成了(私钥B，公钥B)，那么A和B之间的非对称加密会话情形包括：

(1).A将自己的公钥A分发给B，B拿着公钥A将数据进行加密，并将加密的数据发送给A，A将使用自己的私钥A解密数据。

(2).A将自己的公钥A分发给B，并使用自己的私钥A加密数据，然后B使用公钥A解密数据。

(3).B将自己的公钥B分发给A，A拿着公钥B将数据进行加密，并将加密的数据发送给B，B将使用自己的私钥B解密数据。

(4).B将自己的公钥B分发给A，并使用自己的私钥B加密数据，然后A使用公钥B解密数据。

虽然理论上支持4种情形，但在SSH的身份验证阶段，SSH只支持服务端保留公钥，客户端保留私钥的方式，所以方式只有两种：客户端生成密钥对，将公钥分发给服务端；服务端生成密钥对，将私钥分发给客户端。只不过出于安全性和便利性，一般都是客户端生成密钥对并分发公钥。

ssh服务

所有ssh客户端工具，包括ssh命令，scp，sftp，ssh-copy-id等命令都是借助于ssh连接来完成任务的。也就是说它们都连接服务端的22端口，只不过连接上之后将待执行的相关命令转换传送到远程主机上，由远程主机执行。

ssh涉及到两个验证：主机验证和用户身份验证。通过主机验证，再通过该主机上的用户验证，就能唯一确定该用户的身份。一个主机上可以有很多用户，所以每台主机的验证只需一次，但主机上每个用户都需要单独进行用户验证。

ssh支持多种身份验证，最常用的是密码验证机制和公钥认证机制，其中公钥认证机制在某些场景实现双机互信时几乎是必须的。虽然常用上述两种认证机制，但认证时的顺序默认是gssapi-with-mic,hostbased,publickey,keyboard-interactive,password。

ssh服务端配置文件为/etc/ssh/sshd_config，注意和客户端的全局配置文件/etc/ssh/ssh_config区分开来。

ssh认证过程

假如从客户端A(172.16.10.5)连接到服务端B(172.16.10.6)上，将包括主机验证和用户身份验证两个过程，以RSA非对称加密算法为例。

[root@xuexi ~]# ssh 172.16.10.6

服务端B上首先启动了sshd服务程序，即开启了ssh服务，打开了22端口(默认)。

主机验证过程

当客户端A要连接B时，首先将进行主机验证过程，即判断主机B是否是否曾经连接过。

判断的方法是读取~/.ssh/known_hosts文件和/etc/ssh/known_hosts文件，搜索是否有172.16.10.6的主机信息(主机信息称为host key，表示主机身份标识)。如果没有搜索到对应该地址的host key，则询问是否保存主机B发送过来的host key，如果搜索到了该地址的host key，则将此host key和主机B发送过来的host key做比对，如果完全相同，则表示主机A曾经保存过主机B的host key，无需再保存，直接进入下一个过程——身份验证，如果不完全相同，则提示是否保存主机B当前使用的host key。

询问是否保存host key的过程如下所示：

[root@xuexi ~]# ssh 172.16.10.6 
The authenticity of host '172.16.10.6 (172.16.10.6)' can't be established.
RSA key fingerprint is f3:f8:e2:33:b4:b1:92:0d:5b:95:3b:97:d9:3a:f0:cf.
Are you sure you want to continue connecting (yes/no)? yes

known_hosts文件的格式。

[root@xuexi ~]# cat ~/.ssh/known_hosts
172.16.10.6 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC675dv1w+GDYViXxqlTspUHsQjargFPSnR9nEqCyUgm5/32jXAA3XTJ4LUGcDHBuQ3p3spW/eO5hAP9eeTv5HQzTSlykwsu9He9w3ee+TV0JjBFulfBR0weLE4ut0PurPMbthE7jIn7FVDoLqc6o64WvN8LXssPDr8WcwvARmwE7pYudmhnBIMPV/q8iLMKfquREbhdtGLzJRL9DrnO9NNKB/EeEC56GY2t76p9ThOB6ES6e/87co2HjswLGTWmPpiqY8K/LA0LbVvqRrQ05+vNoNIdEfk4MXRn/IhwAh6j46oGelMxeTaXYC+r2kVELV0EvYV/wMa8QHbFPSM6nLz

该文件中，每行一个host key，行首是主机名，它是搜索host key时的索引，主机名后的内容即是host key部分。以此文件为例，它表示客户端A曾经试图连接过172.16.10.6这个主机B，并保存了主机B的host key，下次连接主机B时，将搜索主机B的host key，并与172.16.10.6传送过来的host key做比较，如果能匹配上，则表示该host key确实是172.16.10.6当前使用的host key，如果不能匹配上，则表示172.16.10.6修改过host key，或者此文件中的host key被修改过。

那么主机B当前使用的host key保存在哪呢？在/etc/ssh/ssh_host*文件中，这些文件是服务端(此处即主机B)的sshd服务程序启动时重建的。以rsa算法为例，则保存在/etc/ssh/ssh_host_rsa_key和/etc/ssh/ssh_host_rsa_key.pub中，其中公钥文件/etc/ssh/ssh_host_rsa_key.pub中保存的就是host key。

[root@xuexi ~]# cat /etc/ssh/ssh_host_rsa_key.pub   # 在主机B上查看
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC675dv1w+GDYViXxqlTspUHsQjargFPSnR9nEqCyUgm5/32jXAA3XTJ4LUGcDHBuQ3p3spW/eO5hAP9eeTv5HQzTSlykwsu9He9w3ee+TV0JjBFulfBR0weLE4ut0PurPMbthE7jIn7FVDoLqc6o64WvN8LXssPDr8WcwvARmwE7pYudmhnBIMPV/q8iLMKfquREbhdtGLzJRL9DrnO9NNKB/EeEC56GY2t76p9ThOB6ES6e/87co2HjswLGTWmPpiqY8K/LA0LbVvqRrQ05+vNoNIdEfk4MXRn/IhwAh6j46oGelMxeTaXYC+r2kVELV0EvYV/wMa8QHbFPSM6nLz

发现/etc/ssh/ssh_host_rsa_key.pub文件内容和~/.ssh/known_hosts中该主机的host key部分完全一致，只不过~/.ssh/known_hosts中除了host key部分还多了一个主机名，这正是搜索主机时的索引。

综上所述，在主机验证阶段，服务端持有的是私钥，客户端保存的是来自于服务端的公钥。注意，这和身份验证阶段密钥的持有方是相反的。

实际上，ssh并非直接比对host key，因为host key太长了，比对效率较低。所以ssh将host key转换成host key指纹，然后比对两边的host key指纹即可。指纹格式如下：

[root@xuexi ~]# ssh 172.16.10.6 
The authenticity of host '172.16.10.6 (172.16.10.6)' can't be established.
RSA key fingerprint is f3:f8:e2:33:b4:b1:92:0d:5b:95:3b:97:d9:3a:f0:cf.
Are you sure you want to continue connecting (yes/no)? yes

host key的指纹可由ssh-kegen计算得出。例如，下面分别是主机A(172.16.10.5)保存的host key指纹，和主机B(172.16.10.6)当前使用的host key的指纹。可见它们是完全一样的。

[root@xuexi ~]# ssh-keygen -l -f ~/.ssh/known_hosts
2048 f3:f8:e2:33:b4:b1:92:0d:5b:95:3b:97:d9:3a:f0:cf 172.16.10.6 (RSA)

[root@xuexi ~]# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
2048 f3:f8:e2:33:b4:b1:92:0d:5b:95:3b:97:d9:3a:f0:cf   (RSA)

身份验证过程

主机验证通过后，将进入身份验证阶段。SSH支持多种身份验证机制，它们的验证顺序如下：gssapi-with-mic,hostbased,publickey,keyboard-interactive,password，但常见的是密码认证机制(password)和公钥认证机制(public key)。当公钥认证机制未通过时，再进行密码认证机制的验证。这些认证顺序可以通过ssh配置文件(注意，不是sshd的配置文件)中的指令PreferredAuthentications改变。

如果使用公钥认证机制，客户端A需要将自己生成的公钥(/.ssh/id_rsa.pub)发送到服务端B的/.ssh/authorized_keys文件中。当进行公钥认证时，客户端将告诉服务端要使用哪个密钥对，并告诉服务端它已经访问过密钥对的私钥部分~/.ssh/id_rsa(客户端从自己的私钥中推导，或者从私钥同目录下读取公钥，计算公钥指纹后发送给服务端。所以有些版本的ssh不要求存在公钥文件，有些版本的ssh则要求私钥和公钥同时存在且在同目录下)，然后服务端将检测密钥对的公钥部分，判断该客户端是否允许通过认证。如果认证不通过，则进入下一个认证机制，以密码认证机制为例。

当使用密码认证时，将提示输入要连接的远程用户的密码，输入正确则验证通过。

验证通过

当主机验证和身份验证都通过后，分两种情况：直接登录或执行ssh命令行中给定某个命令。如：

[root@xuexi ~]# ssh 172.16.10.6 
[root@xuexi ~]# ssh 172.16.10.6  'echo "haha"'

(1).前者ssh命令行不带任何命令参数，表示使用远程主机上的某个用户(此处为root用户)登录到远程主机172.16.10.6上，所以远程主机会为ssh分配一个伪终端，并进入bash环境。

(2).后者ssh命令行带有命令参数，表示在远程主机上执行给定的命令【echo "haha"】。ssh命令行上的远程命令是通过fork ssh-agent得到的子进程来执行的，当命令执行完毕，子进程消逝，ssh也将退出，建立的会话和连接也都将关闭。(之所以要在这里明确说明远程命令的执行过程，是为了说明后文将介绍的ssh实现端口转发时的注意事项)

实际上，在ssh连接成功，登录或执行命令行中命令之前，可以指定要在远程执行的命令，这些命令放在~/.ssh/rc或/etc/ssh/rc文件中，也就是说，ssh连接建立之后做的第一件事是在远程主机上执行这两个文件中的命令。

服务端分发私钥

对于基于公钥认证的身份验证机制，除了上面客户端分发公钥到服务端的方法，还可以通过分发服务端私钥到客户端来实现。

先理清下公钥认证的原理：客户端要连接服务端，并告诉服务端要使用那对密钥对，然后客户端访问自己的私钥，服务端检测对应的公钥来决定该公钥所对应的客户端是否允许连接。所以对于基于公钥认证的身份验证，无论是客户端分发公钥，还是服务端分发私钥，最终客户端保存的一定是私钥，服务端保存的一定是公钥。

那么服务端分发私钥实现公钥认证是如何实现的呢？步骤如下：假如客户端为172.16.10.5，服务端为172.16.10.6。

(1).在服务端使用ssh-keygen生成密钥对。

[root@xuexi ~]# ssh-keygen -f ~/.ssh/id_rsa -P ''

(2).将上面生成的公钥追加到自己的authorized_keys文件中。

[root@xuexi ~]# ssh-copy-id 172.16.10.6

(3).将私钥拷贝到客户端，且路径和文件名为~/.ssh/id_rsa。

[root@xuexi ~]# scp -p ~/.ssh/id_rsa* 172.16.10.5:/root/.ssh/

注意，第三步中也拷贝了公钥，原因是客户端连接服务端时会比较自己的公钥和私钥是否配对，如果不配对将直接忽略公钥认证机制，所以会要求输入密码。可以将客户端的公钥删除掉，或者将服务端生成的公钥覆盖到客户端的公钥上，都能完成公钥认证。

虽说，服务端分发私钥的方式很少用，但通过上面的步骤，想必对ssh基于公钥认证的身份验证过程有了更深入的理解。

ssh相关文件

以主机A连接主机B为例，主机A为SSH客户端，主机B为SSH服务端。

在服务端即主机B上：

  • /etc/ssh/sshd_config ：ssh服务程序sshd的配置文件。
  • /etc/ssh/ssh_host_* ：服务程序sshd启动时生成的服务端公钥和私钥文件。如ssh_host_rsa_key和ssh_host_rsa_key.pub。
    • 其中.pub文件是主机验证时的host key，将写入到客户端的~/.ssh/known_hosts文件中。
    • 其中私钥文件严格要求权限为600，若不是则sshd服务可能会拒绝启动。
  • ~/.ssh/authorized_keys：保存的是基于公钥认证机制时来自于客户端的公钥。在基于公钥认证机制认证时，服务端将读取该文件。

在客户端即主机A上：

  • /etc/ssh/ssh_config ：客户端的全局配置文件。
  • ~/.ssh/config ：客户端的用户配置文件，生效优先级高于全局配置文件。一般该文件默认不存在。该文件对权限有严格要求只对所有者有读/写权限，对其他人完全拒绝写权限。
  • ~/.ssh/known_hosts ：保存主机验证时服务端主机host key的文件。文件内容来源于服务端的ssh_host_rsa_key.pub文件。
  • /etc/ssh/known_hosts：全局host key保存文件。作用等同于~/.ssh/known_hosts。
  • ~/.ssh/id_rsa ：客户端生成的私钥。由ssh-keygen生成。该文件严格要求权限，当其他用户对此文件有可读权限时，ssh将直接忽略该文件。
  • ~/.ssh/id_rsa.pub ：私钥id_rsa的配对公钥。对权限不敏感。当采用公钥认证机制时，该文件内容需要复制到服务端的 ~/.ssh/authorized_keys文件中。
  • ~/.ssh/rc ：保存的是命令列表，这些命令在ssh连接到远程主机成功时将第一时间执行，执行完这些命令之后才开始登陆或执行ssh命令行中的命令。
  • /etc/ssh/rc ：作用等同于~/.ssh/rc。

ssh配置文件

分为服务端配置文件/etc/ssh/sshd_config和客户端配置文件/etc/ssh/ssh_config(全局)或~/.ssh/config(用户)。

虽然服务端和客户端配置文件默认已配置项虽然非常少非常简单，但它们可配置项非常多。sshd_config完整配置项参考sshd_config中文手册，ssh_config也可以参考sshd_config的配置，它们大部分配置项所描述的内容是相同的。

[root@xuexi ~]# cat /etc/ssh/sshd_config
#Port 22                # 服务端SSH端口，可以指定多条表示监听在多个端口上
#ListenAddress 0.0.0.0  # 监听的IP地址。0.0.0.0表示监听所有IP
Protocol 2              # 使用SSH 2版本
#####################################
#          私钥保存位置               #
#####################################
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key      # SSH 1保存位置/etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key  # SSH 2保存RSA位置/etc/ssh/ssh_host_rsa _key
#HostKey /etc/ssh/ssh_host_dsa_key  # SSH 2保存DSA位置/etc/ssh/ssh_host_dsa _key
###################################
#           杂项配置               #
###################################
#PidFile /var/run/sshd.pid        # 服务程序sshd的PID的文件路径
#ServerKeyBits 1024               # 服务器生成的密钥长度
#SyslogFacility AUTH              # 使用哪个syslog设施记录ssh日志。日志路径默认为/var/log/secure
#LogLevel INFO                    # 记录SSH的日志级别为INFO
###################################
#   以下项影响认证速度               #
###################################
#UseDNS yes                       # 指定是否将客户端主机名解析为IP，以检查此主机名是否与其IP地址真实对应。默认yes。                                 # 由此可知该项影响的是主机验证阶段。建议在未配置DNS解析时，将其设置为no，否则主机验证阶段会很慢
###################################
#   以下是和安全有关的配置           #
###################################
#PermitRootLogin yes              # 是否允许root用户登录
#GSSAPIAuthentication no          # 是否开启GSSAPI身份认证机制，默认为yes
#PubkeyAuthentication yes         # 是否开启基于公钥认证机制
#AuthorizedKeysFile  .ssh/authorized_keys  # 基于公钥认证机制时，来自客户端的公钥的存放位置
PasswordAuthentication yes        # 是否使用密码验证，如果使用密钥对验证可以关了它
#PermitEmptyPasswords no          # 是否允许空密码，如果上面的那项是yes，这里最好设置no
#MaxSessions 10                   # 最大客户端连接数量
#LoginGraceTime 2m                # 身份验证阶段的超时时间，若在此超时期间内未完成身份验证将自动断开
#MaxAuthTries 6                   # 指定每个连接最大允许的认证次数。默认值是6。
                                  # 如果失败认证次数超过该值一半，将被强制断开，且生成额外日志消息。
MaxStartups 10                    # 最大允许保持多少个未认证的连接。默认值10。
###################################
#   以下可以自行添加到配置文件        #
###################################
DenyGroups  hellogroup testgroup  # 表示hellogroup和testgroup组中的成员不允许使用sshd服务，即拒绝这些用户连接
DenyUsers   hello test            # 表示用户hello和test不能使用sshd服务，即拒绝这些用户连接
###################################
#   以下一项和远程端口转发有关        #
###################################
#GatewayPorts no                  # 设置为yes表示sshd允许被远程主机所设置的本地转发端口绑定在非环回地址上
                                  # 默认值为no，表示远程主机设置的本地转发端口只能绑定在环回地址上，见后文"远程端口转发"

AuthorizedKeysFile .ssh/authorized_keys 中使用的就是相对路径，它指向的正是尝试登录的哪个用户的家目录（home directory）下的 .ssh/authorized_keys 文件。

ssh跳板

使用ssh还可以实现主机跳转，即跳板功能。例如主机B能和A、C通信，但A、C之间不同通信，即A<-->B<-->C<-x->A的情形。如果要从A登陆到C，则可以借助B这个跳板登录到C。此处一个简单示例为：从172.16.10.5登录到172.16.10.6，再以此为基础登录到172.16.10.3上。

配置互信

(1).在客户端使用ssh-keygen生成密钥对，存放路径按照配置文件的指示，默认是在~/.ssh/目录下。

[root@xuexi ~]# ssh-keygen -t rsa    # -t参数指定算法，可以是rsa或dsa
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:            
Your identification has been saved in /root/.ssh/id_rsa. 
Your public key has been saved in /root/.ssh/id_rsa.pub.

如果不想被询问，则可以使用下面一条命令完成："-f"指定私钥文件，"-P"指定passphrase，或者"-N"也一样。

[root@xuexi ~]# ssh-keygen -t rsa -f ~/.ssh/id_rsa -P ''   # 指定加密私钥文件的密码为空密码，即不加密

[root@xuexi ~]# ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''   # 同上

查看~/.ssh/目录下私钥的权限。私钥文件有严格的权限要求，当私钥文件的非所有者有可读权限时，将直接忽略该私钥文件导致公钥认证失败。

[root@xuexi ~]# ls -l ~/.ssh
total 12
-rw------- 1 root root 1671 Jun 29 00:18 id_rsa      # 私钥权限必须600，属主为自己
-rw-r--r-- 1 root root  406 Jun 29 00:18 id_rsa.pub
-rw-r--r-- 1 root root  393 Jun 29 05:56 known_hosts

(2).将上面生成的公钥使用ssh-copy-id分发(即复制)到远程待信任主机上。

ssh-copy-id用法很简单，只需指定待信任主机及目标用户即可。如果生成的公钥文件，路径不是~/.ssh/id_rsa.pub，则使用"-i"选项指定要分发的公钥。

ssh-copy-id [-i [identity_file]] [user@]machine

例如，将公钥分发到172.16.10.6上的root用户家目录下：

[root@xuexi ~]# ssh-copy-id 172.16.10.6

ssh-copy-id唯一需要注意的是，如果ssh服务端的端口不是22，则需要给ssh-copy-id传递端口号，传递方式为 "-p port_num [user@]hostname" (注意加上双引号)，例如"-p 22222 root@172.16.10.6"。之所以要如此传递，见下面摘自ssh-copy-id中公钥分发的命令部分。

{ eval "$GET_ID" ; } | ssh $1 "umask 077; test -d ~/.ssh || mkdir ~/.ssh ; cat >> ~/.ssh/authorized_keys && (test -x /sbin/restorecon && /sbin/restorecon ~/.ssh ~/.ssh/authorized_keys >/dev/null 2>&1 || true)" || exit 1

其中"{ eval "$GET_ID" ; }"可理解为待分发的本地公钥内容，"(test -x /sbin/restorecon && /sbin/restorecon ~/.ssh ~/.ssh/authorized_keys >/dev/null 2>&1 || true)"和selinux有关，不用管，所以上述命令简化为：

cat ~/.ssh/id_rsa.pub | ssh $1 "umask 077; test -d ~/.ssh || mkdir ~/.ssh ; cat >> ~/.ssh/authorized_keys || exit 1

可见，ssh-copy-id的所有参数都是存储在位置变量$1中传递给ssh，所以应该将ssh的端口选项"-p port_num"和user@hostname放在一起传递。

通过分析上面的命令，也即知道了ssh-copy-id的作用：在目标主机的指定用户的家目录下，检测是否有/.ssh目录，如果没有，则以700权限创建该目录，然后将本地的公钥追加到目标主机指定用户家目录下的/.ssh/authorized_keys文件中。

posted @ 2025-08-26 16:23  pointarray  阅读(29)  评论(0)    收藏  举报