云服务器 ECS Linux SSH 无法远程登录问题排查指引与 SSH 原理概述

  • A+
所属分类:Linux
高性能企业级服务器首台5折

本文先说明云服务器 ECS Linux 服务器 SSH 无法远程登录问题的排查思路,然后 SSH 服务的相关背景知识进行说明。

注意:本文相关配置及说明已在 CentOS 6.5 64 位操作系统中进行过测试。其它类型及版本操作系统配置可能有所差异,具体情况请参阅相应操作系统官方文档。

SSH 无法远程登录问题排查指引

对于云服务器 ECS Linux,SSH 客户端是主要的运维途径。而 管理终端 可以用于临时运维,或者在客户端登录出现异常时,用于问题排查分析。本文就 SSH 无法登录的可能原因及排查方法进行说明。

SSH 登录关联因素示意图

SSH 无法登录常见现象及处理办法

针对前述不同因素,常见的问题现象及处理办法说明如下:

客户端问题

客户端无法正常登录时,建议先使用不同的 SSH 客户端基于相同账户信息进行登录测试。如果能正常登录,则判断是客户端配置问题,则需要对客户端配置或软件运行情况做排查分析。

ECS Linux 服务器的登录过程说明,可以参阅产品文档:登录实例

中间网络问题

客户端无法正常通过 SSH 连接服务器时,先通过如下方式进行 telnet 端口测试,判断是否是中间网络异常所致:

  1. telnet <服务器 IP> <SSH 服务端口>比如:telnet 192.168.0.1 22

正常情况下,如下图所示,会返回服务端 SSH 软件版本号:

如果端口测试失败,则可以参阅如下文档针对客户端到服务器之间的网络做进一步排查分析:

  • ping 丢包或不通时链路测试说明
  • 能 ping 通但端口不通时端口可用性探测说明
  • 网络异常时抓包操作说明

PAM 安全框架相关问题

Linux 系统的 PAM 安全框架,可以加载相关安全模块,对服务器的账户策略、登录策略等进行访问控制。如果相关配置存在异常,或触发了相关策略,就可能会导致 SSH 登录失败。与PAM 安全框架相关的常见案例如下:

Linux 系统环境配置问题

Linux 内的系统环境(比如中毒、账户配置、环境变量配置等)如果出现异常,也可能会导致 SSH 登录失败。与 Linux 系统环境相关的常见案例如下:

SSH 服务及参数配置问题

SSH 服务的默认配置文件为 /etc/ssh/sshd_config。配置文件中的相关参数配置异常,或启用了相关特性或策略,也可能会导致 SSH 登录失败。与 SSH 服务及参数配置相关的常见案例如下:

SSH 服务关联目录或文件配置问题

SSH 服务基于安全性考虑,在运行时,会对相关目录或文件的权限配置、属组等进行检查。过高或过低的权限配置,都可能会引发服务运行异常,进而导致客户端登录失败。与 SSH 服务关联目录或文件配置相关的常见案例如下:

SSH 服务密钥配置问题

SSH 服务采用非对称加密技术,对所传输的数据进行加密。客户端及服务端会交换和校验相关密钥信息的有效性。与 SSH 服务密钥配置相关的常见案例如下:

SSH 无法登录问题排查思路

如果根据前述问题场景进行排查和处理后,还是无法正常登录。则建议按照如下步骤进行逐一排查分析:

  1. 多客户端对比测试:
    使用不同的 SSH 客户端及 管理终端 做对比访问测试,以判断是否是个别客户端自身配置或软件运行问题所致。如果管理终端登录正常,也可以通过管理终端进入系统做进一步排查分析。
  2. 网络测试:
    参阅前文中间网络问题小节相关说明,测试网络连通性。
  3. 服务端日志获取:
    通过 管理终端 进入服务器。然后在客户端重新访问测试时,通过如下指令同步获取服务端相关日志信息:
  1. tailf /var/log/secure
  • 客户端日志获取:
    如果客户端是 Linux 环境,则可以通过如下指令,获取详细的 SSH 登录交互日志:

    1. ssh -vvv <服务器 IP>
      比如:
      [root@centos~]# ssh -vvv 192.168.0.1
      OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
      debug1: Reading configuration data /etc/ssh/ssh_config
      debug1: Applying options for *
      debug2: ssh_connect: needpriv 0
      debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22.
      debug1: connect to address 192.168.0.1 port 22: Connection timed out
      ssh: connect to host 192.168.0.1 port 22: Connection timed out
  • SSH 服务运行状态检查:
    通过 管理终端 登录服务器,然后通过如下方式检查 SSH 服务运行状态:

    • 检查服务运行状态:
      通过如下指令检查服务运行状态。正常情况下会返回运行状态及相应进程 PID:

      1. [root@centos ~]# service sshd status
        openssh-daemon (pid 31350) is running…
        [root@centos ~]# service sshd restart
        Stopping sshd: [ OK ]
        Starting sshd: [ OK ]
    • 检查服务监听状态:
      通过如下指令检查服务监听状态。正常情况下会返回相应端口监听信息:

      1. netstat -ano | grep 0.0.0.0:22
        tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN off (0.00/0/0)
    • 127.0.0.1 登录测试:
      通过 管理终端 登录服务器,然后 ssh 127.0.0.1。如果能正常登录,则推断是系统防火墙或外部安全组策略等配置异常,导致客户端登录失败。

SSH 连接交互过程简介

注意:本文相关配置及说明已在 CentOS 6.5 64 位操作系统中进行过测试。其它类型及版本操作系统配置可能有所差异,具体情况请参阅相应操作系统官方文档。

SSH 服务在进行数据传输前,会先进行密钥交换和协商确认。完成后再对后续数据进行加密传输,以提高安全性。本文先对SSH 服务所采用的非对称加密技术进行简要介绍,然后对 SSH 连接过程中的相关交互,及关联文件进行说明。

非对称加密技术

SSH 服务基于非对称加密public-key cryptography,也称公开密钥加密)技术实现数据加密传输。该技术会生成一对数学相关的密钥,其中一个用于对数据进行加密,而且只能用于加密,而另一个只能用于解密。使用加密密钥加密后的数据,只能用对应的解密密钥才能解密。而且,只知道其中一个密钥,无法计算出另一个。因此,如果公开了一对密钥中的一个,并不会危害到另一个的秘密性质。通常把公开的密钥称为公钥(public key),而不公开的密钥称为私钥(private key)。

如果公开的是解密密钥,该场景用于客户端验证持有私钥一方发布的数据或文件的完整性、准确性,以防止数据篡改。相应的密钥称为数字签名(数字证书)。如果公开的是加密密钥,该场景用于客户给私钥所有者上传数据,称为公开密钥加密。SSH 服务基于该场景实现。

对称密钥加密相比,非对称加密的优点在于不存在共享的通用密钥。由于解密用的私钥无需发送给任何用户,所以可以避免密钥被劫持或篡改。而加密用的公钥即便被劫持或篡改,如果没有与其匹配的私钥,也无法解密数据。所以,截获的公钥是没有任何用处的。

当前,SSH主要采用 RSA 算法(协议 V2 默认算法)和 DSA 算法(协议 V1 仅支持该算法)来实现非对称加密技术。

连接交互过程

SSH 服务建立连接时的相关交互过程,如下SSH 服务连接交互示意图 所示:

连接过程中的相关交互步骤,详细说明如下。

服务端准备阶段

服务端在每次启动 SSH 服务时,都会自动检查 /etc/ssh/ 目录下相关密钥文件的有效性。如果相关文件检查发现异常,则会导致服务启动失败,并抛出相应错误信息。 如果文件相关不存在,则会自动重新创建。

默认创建的相关文件及用途说明如下:

  1. ll /etc/ssh/
    bash
  2. -rw-------. 1 root root 125811 Aug 13 2015 moduli → 用于 DH-GEX 算法<br>
  3. -rw-r--r--. 1 root root 2047 Aug 13 2015 ssh_config → SSH 客户端配置文件<br>
  4. -rw-------. 1 root root 3879 Aug 13 2015 sshd_config → SSH 服务配置文件<br>
  5. -rw-------. 1 root root 672 May 20 14:22 ssh_host_dsa_key → DSA 算法私钥<br>
  6. -rw-r--r--. 1 root root 590 May 20 14:22 ssh_host_dsa_key.pub → DSA 算法公钥<br>
  7. -rw-------. 1 root root 963 May 20 14:22 ssh_host_key → SSH V1 版RSA 算法私钥<br>
  8. -rw-r--r--. 1 root root 627 May 20 14:22 ssh_host_key.pub → SSH V1 版 RSA 算法公钥<br>
  9. -rw-------. 1 root root 1675 May 20 14:22 ssh_host_rsa_key → SSH V2 版 RSA 算法私钥<br>
  10. -rw-r--r--. 1 root root 382 May 20 14:22 ssh_host_rsa_key.pub → SSH V2 版 RSA 算法公钥

非对称加密协商

服务端 SSH 服务正常运行后,客户端连接时,进行如下交互:

  1. 客户端向服务端发送连接请求。
    客户端通过 SSH 工具连接服务端。相关信息通过明文发送。
  2. 服务端返回公钥信息:
    根据客户端所使用的服务协议版本及算法设置,返回相应公钥信息。比如,默认情况下,客户端通过 SSH V2 版协议,基于 RSA 算法建立连接,则服务端将 ssh_host_rsa_key.pub文件中的内容返回客户端。相关信息通过明文发送。
  3. 客户端对服务端公钥信息进行比对和确认:
    客户端接收到服务端公钥信息后,会进行如下比对,并让用户对相关信息进行确认。
  • 如果是首次连接服务端,客户端会收到类似如下信息,让用户确认公钥指纹的有效性:
    1. bash
    2. The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established.
    3. RSA key fingerprint is c2:49:d9:43:74:d5:ed:bc:28:9b:d2:7b:63:94:cf:bc.
    4. Are you sure you want to continue connecting (yes/no)?
    1. 如果用户输入 no ,则连接中断并报错(Host key verification failed)。
    • 如果用户输入 yes,则会将相应的公钥信息,保存到当前用户家目录下 .ssh 目录内的 known_hosts 文件中。 比如:
      1. bash
      2. cat ~/.ssh/known_hosts
      3. IP 明文显示:
      4. 192.168.0.1 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3sdlboGEgY9buZpkPuygPw0NxAvmxYd0mc3fo2MgP+JqgFC9/9ZXOgDXKJrjE2HKBieJZSPKGncIh+zLxTvmykeJQBXv7i1GiUjW+H3VY69Ge3AdGfCd+XF+Cvi1e+j18zhHnjSzvIBoNpT5cBWWNbw7mNHCwTb0sHAVUkWR4Ck/LM5/rQ09A+m6BLfZJL8CRNGxKTbyINi6o812S+Cy64WqDs1nTpIXp2Bkcpjclb36bFSs9Z/tWNuJl7A//7HNtxMgFGBnE07Ykvvy8s06DUmkyFy8GcXGBpnfdg9utLodfQLFQnKflCQZ110BpQaCWlWPjU9dc4w3XLJ/XQOP4w==
      5. IP 做了加密处理:
      6. |1|3efXAZ4sNHcUcHamBy4gDriblc8=|8idBhLq9aLl2sfh4KswMsk4sPFI= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwS4DE3hok8RCkxYlTxsexNrNa62e05UGSkoP7ie26DDWjG1Aoc74cCsE4is9p7lEfFUYYlAzeYhPqE/yGf5YxRZUOU2IeFI4cEqo8YZr7edVYpgAq2f2J0zMwk1syenD12lmUPkYA4mMB6it3jxXR5k+H0HZh9YA7mRXkiTjlkAMWirBcnUvtKYRv9LRIr3ikUiPy2gfZO291Ae9zuTsWwEtHQxIpiBgk3vwF2gCUFlX9y//IsMjdQq5prk7x3BjXhUorqgJO1gt1VHW8Xxx9Oe50YF1hi9DuE6VXwyh4xfHTmauRQybwsYafdA3HxrA2od6x9l19D9EH7xHAjDa5w==
  • 如果服务端因重装系统等因素导致公钥指纹出现变化,则会直接导致连接失败(报错Host key verification failed),则需要删除已保存的条目后再重新连接。 相关操作可以参阅 云服务器 ECS Linux 客户端 SSH 公钥指纹不匹配导致 SSH 登录失败
  • 如果之前已经成功连接,而且公钥指纹对比一致,则会继续下一步操作。

  • 客户端生成临时密钥对:
    服务端公钥校验及确认后,客户端会生成一对临时密钥用于客户端加密。该密钥对不会存储到文件,而是记录在内存中。每次连接都会重新生成临时密钥对。
  • 客户端发送公钥信息:
    客户端向服务端,发送前述生成的临时密钥对中的公钥信息。相关信息通过明文发送。

 

至此,服务端及客户端都拥有对方的公钥和自身的私钥,所以称为非对称加密。

后续数据交互过程

后续登录校验及正常的数据传输,都会通过双向加密方式进行。相关交互说明如下:

  • 如果服务端需要发送数据给客户端:
    • 服务端使用所持有的客户端公钥,对需要传输的数据进行加密,再发送给客户端。
    • 客户端收到信息后,使用所持有的自身私钥解密后获取数据。
  • 反之,如果客户端需要发送数据给服务端,也是类似的流程:
    • 客户端使用所持有的服务端公钥,对需要传输的数据进行加密,再发送给服务端。
    • 服务端收到信息后,使用所持有的自身私钥解密后获取数据。

SSH 基于密钥交换的自动登录原理简介及配置说明

注意:本文相关配置及说明已在 CentOS 6.5 64 位操作系统中进行过测试。其它类型及版本操作系统配置可能有所差异,具体情况请参阅相应操作系统官方文档。

SSH 服务可以对所有传输的数据进行加密,提供比传统 telnet 服务更高的安全性(更多关于SSH 服务的连接交互过程,可以参阅 云服务器 ECS Linux SSH 连接交互过程简介)。而基于密钥认证的 SSH 自动化登录,在保障安全性的同时,可以简化登录过程,降低运维成本。本文先简要介绍基于密钥交换的 SSH 自动登录的原理,然后对配置方法进行说明。

原理简介

SSH证书认证登录的基础是一对唯一匹配密钥: 私钥(private key)和公钥(public key)。公钥用于对数据进行加密,而且只能用于加密。而私钥只能对使用所匹配的公钥,所加密过的数据进行解密。私钥需要用户单独妥善保管。SSH 客户端使用私钥向服务器证明自已的身份。而公钥是公开的,可以按需将其配置到目标服务器上自己的相应帐号中。

在进行 SSH 登录认证时,进行私钥和公钥协商。如果匹配,则身份得以证明,认证成功,允许登录。否则,将会继续使用密码验证等其它方式进行登录校验。SSH 证书验证登录配置及登录协商过程,如下证书校验交互登录流程示意图所示:

各步骤补充说明如下:

生成证书

  1. 客户端生成密钥对。
  2. 将公钥信息写入目标服务器、目标账户的配置文件。该操作隐含表示了客户端拥有对目标服务器的控制权。

协商交互过程

  1.  客户端向目标服务器发送登录请求。在SSH 服务启用了证书验证登录方式后,会优先通过证书验证方式进行登录验证。
  2. 目标服务器根据 SSH 服务配置,在用户对应目录及文件中读取到有效的公钥信息。
  3. 目标服务器生成一串随机数,然后使用相应的公钥对其加密。
  4. 目标服务器将加密后的密文发回客户端。
  5. 客户端使用默认目录或 -i 参数指定的私钥尝试解密。
  6. 如果解密失败,则会继续尝试密码验证等其它方式进行登录校验。如果解密成功,则将解密后的原文信息重新发送给目标服务器。意思类似于: “看,这是这段话的原文。我能读懂发过来的密文,我拥有服务器的控制权,请让我登录。”
  7. 目标服务器对客户端返回的信息进行比对。如果比对成功,则表示认证成功,客户端可以登录。如果对比失败,则表示认证失败,则会继续尝试密码验证等其它方式进行登录校验。

自动登录配置

生成密钥对

SSH 协议 V1只使用 RSA 算法,而 SSH 协议V2 对 RSA 算法和 DSA 算法都支持。目前所有OpenSSH 版本都应该对两种算法都支持。两种算法的密钥的生成指令和使用方法相同,本文仅以 RSA 算法为例进行相关说明。

生成密钥对的时候,可以按需决定是否设置密码。但需要注意的是,如果设置了密码,还需结合 ssh-agent 代理和 ssh-add 配置才能实现自动登录。同时,相关配置只对 ssh-agent 启动的相应 shell 生效,用户退出后重新登录时还需重新配置。所以,为简便起见,本文以常见的、不配置密码的情况进行说明。

可以在任意支持环境下生成密钥对。Windows 和 Linux 环境下,配置分别说明如下。

Windows 环境下生成密钥对

在 Windows 环境下,通常借助各种应用软件来创建和管理密钥对。以常见的 PuTTYgen 为例,请执行如下步骤创建密钥对:

  1. 启动 PuTTYgen。本示例中的 PuTTYgen 版本为 0.68。
  2. 在 Parameters > Type of key to generate 中,选中 RSANumber of bits in a generated key 的值不需要设置,软件会根据导入的私钥信息自动更新。ECS _ SSH Key Pair _ 导入私钥参数
  3. 单击 Load。PuTTYgen 默认仅显示扩展名为 .ppk 的文件。要找到您的 .pem 文件,请选择显示所有类型的文件。ECS _ SSH Key Pair _ 打开待导入的私钥文件
  4. 选择您从阿里云下载的“.pem”格式的私钥文件,然后单击 打开ECS _ SSH Key Pair _ 载入pem文件
  5. 单击 OK(确定)关闭确认对话框。
  6. 单击 Save private key。PuTTYgen 会显示一条关于在没有口令的情况下保存密钥的警告,单击 是(Y)ECS _ SSH Key Pair _ 保存私钥
  7. 指定与密钥对相同的私钥名称,保存。PuTTY 会自动为文件添加 .ppk 扩展名。

 

Linux 环境下生成密钥对

在 Linux 环境下,通常使用系统自带的 ssh-keygen 软件来创建和管理密钥对。请执行如下步骤创建密钥对:

  1. 以任意具有 ssh-keygen 执行权限的用户登录服务器。
  2. 使用如下指令,基于 rsa 算法创建密钥对:
    1. ssh-keygen -t rsa
    2. Generating public/private rsa key pair.
    3. Enter file in which to save the key (/root/.ssh/id_rsa): → 默认保存路径和文件名,可以按需修改。
    4. Enter passphrase (empty for no passphrase): → 如前面所述,不设置密码,回车确认即可。
    5. Enter same passphrase again: → 不设置密码,回车确认即可。
    6. Your identification has been saved in /root/.ssh/id_rsa. → 创建的私钥文件。
    7. Your public key has been saved in /root/.ssh/id_rsa.pub. → 创建的公钥文件。
    8. The key fingerprint is:
    9. 17:b8:0e:76:cb:57:21:3b:f2:bb:8b:a2:42:2b:54:be root@iZ233gr74jvZ
    10. The key's randomart image is:
    11. +--[ RSA 2048]----+
    12. | |
    13. | . |
    14. | . o . |
    15. | . . + . |
    16. | o o S + . |
    17. | ... . = = o |
    18. |.. .. + o |
    19. |. oE . o . |
    20. | . ... .. +o |
    21. +-----------------+

    说明:

  • 如果 .ssh 目录不存在,程序会自动创建。
  • 生成的密钥对默认保存在当前用户家目录下的 .ssh 文件夹中,文件名默认为 id_rsa(私钥) 和 id_rsa.pub(公钥)。用户可以按需设置保存路径和文件名。

密钥配置

生成密钥对后,进行如下处理:

私钥的处理

私钥用于信息校验,请确保安全。可以将私钥上传到其它源服务器上,或者直接参阅前述说明创建新的密钥对。

公钥的处理

公钥信息需要写入目标服务器、目标用户的配置文件中,默认配置文件为对应用户家目录下 .ssh 文件夹中的authorized_keys,即:

  1. ~/.ssh/authorized_keys

可以复制公钥信息后,直接通过 vi 等编辑器将其写入上述文件。或者通过如下指令,在源服务器上配置写入:

  1. cat ~/.ssh/id_rsa.pub | ssh <用户名>@<目标服务器IP> ‘cat >> ~/.ssh/authorized_keys’;比如:cat ~/.ssh/id_rsa.pub | ssh root@120.26.38.248 ‘cat >> ~/.ssh/authorized_keys’;

注意:

  • 该操作由于需要登录目标服务器才能完成,所以隐含表示了客户端拥有对目标服务器的控制权。
  • 如果修改了默认的目录或文件名,则需要同步修改SSH 服务配置文件(默认为/etc/ssh/sshd_config)中的AuthorizedKeysFile 参数,否则会因找不到公钥信息而导致自动登录失败。

参数与权限检查确认

要顺利完成自动登录,还需对SSH 服务相关参数及关联文件、文件夹的权限进行确认或调整。

SSH 服务参数设置

SSH 服务默认开启了证书认证支持。编辑 SSH 服务配置文件(默认为/etc/ssh/sshd_config),确保如下参数没有显示的置为 no。否则,将参数值修改为 yes,或者整个删除或注释(在最开头添加 # 号)整行配置。比如:

  1. #RSAAuthentication yes#PubkeyAuthentication yes

同时,如前面所述,如果修改了默认的公钥路径或文件名,还需确保 AuthorizedKeysFile 参数值配置的信息与其一致。

注意:如果对相关参数做了修改,需要重启 SSH 服务生效。

相关权限设置

SSH 服务证书验证方式登录,对相关目录和文件的权限有要求。权限配置异常可能会导致登录失败。

  • .ssh 目录的权限配置
    使用如下指令,确保 $HOME/.ssh 目录只有所有者才有权写入:
  1. chmod 700 ~/.ssh

  • authorized_keys 文件的权限配置
    使用如下指令,确保其它用户对 authorized_keys 文件没有修改权限:?

 

  1. chmod 600 ~/.ssh/authorized_keys

  • 进一步安全配置
    进一步的安全设置可以将 authorized_keys 文件权限配置为 400(其他用户没有任何权限),并对其及 .ssh 目录添加immutable 位权限(防止文件被修改):

 

  1. chmod 400 ~/.ssh/authorized_keyschattr +i ~/.ssh/authorized_keyschattr +i ~/.ssh

自动登录配置

完成上述配置后,在客户端即可免密码直接登录。说明如下:

Windows 环境自动登录

您可以参阅文档 使用 SSH 密钥对连接 Linux 实例

Linux 环境自动登录

Linux 环境下,在客户端直接通过 ssh 软件免密码登录:

  1. ssh <用户名>@<目标服务器> # 比如:ssh root@192.168.0.1

如果修改了私钥路径或文件名,则需要通过 –i 参数进行指定:

  1. ssh –i <私钥路径及文件名> <用户名>@<目标服务器> #比如:ssh -i /bak/my_rsa user@192.168.0.1

更多信息

  • OpenSSH Manual Pages:OpenSSH 官方使用手册。
  • 公钥指纹
    由于公钥一般较长(采用RSA算法时长达 1024 位)。所以,为了简便起见,通过对其MD5计算,生成一个128位的字符串用于信息对比。此称为公钥指纹。
  • Secure Shell:Wikipedia 上关于 SSH 的介绍和讨论。
  • OpenSSH Manual Pages:OpenSSH 官方使用手册。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: