SSH常见问题及其解决方法

SSH是Linux中的基础服务，作为IT从业者，基本上每天都要SSH连接到服务器中，从事各种各样的工作。作为这样基础的不能再基础的服务，一旦出现问题，影响也是巨大的，连不上就无法对服务器进行配置和更改，所有的事情也就无从谈起。

在这篇文章中，我们会对SSH服务进行介绍，并对一些常见的问题进行分析，进而提供相应的解决方法。话不多说，我们进入主题。

一、SSH服务简介

SSH采用的是C/S架构，SSH server端一般运行在服务器中，这里的服务器可以是物理服务器，而现在随着云计算的推广，更大的可能性是云主机，比如AWS的EC2实例，阿里云的ECS实例等。SSH client端则千差万别，Linux中是ssh命令，一般是OpenSSH软件包的一部分；Windows中比较常见的是SecureCRT，X-Shell，Moba-Xterm等。

接下来，我们以Linux Mint作为SSH client端，以AWS EC2为SSH server端进行演示和分析。

我们首先来分析一个正常的SSH连接是如何进行的，在这里我们通过ssh命令的-vvv选项，来看一下SSH连接背后发生了什么。这里为了减少不必要的影响，略去了测试用的对端IP地址，Linux Mint的ssh配置文件默认指定了连接用户为ec2-user，指定了本地的私钥文件位置为/home/user/.ssh/user.pem。

################################################

[email protected]:~$ ssh IP -vvv

OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017

#本机的ssh客户端版本信息

.....

.....

debug1: Connecting to IP [IP] port 22.

debug1: Connection established.

#与对端TCP 22端口完成建联过程

debug1: key_load_public: No such file or directory

debug1: identity file /home/user/.ssh/user.pem type -1

#本地的key文件

.....

.....

debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4

debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000

#对端ssh服务器版本信息

debug2: fd 3 setting O_NONBLOCK

debug1: Authenticating to IP:22 as 'ec2-user'

#本地配置文件中指定的用户信息

.....

.....

debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c

debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],ssh-rsa-ce[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

#ssh客户端与服务器端交换支持的加密算法

.....

.....

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /home/user/.ssh/user.pem

#使用本地的private key进行密钥认证

debug3: sign_and_send_pubkey: RSA SHA256:imct6EHZzIK24fZ+H3bFzHAYpDLufFVELss7un64aZA

debug3: send packet: type 50

debug2: we sent a publickey packet, wait for reply

#本地的ssh客户端发送了publickey报文，等待ssh服务器端反馈

debug3: receive packet: type 52

#本地的ssh客户端收到来自ssh服务器端的反馈

debug1: Authentication succeeded (publickey).

#提示认证成功

Authenticated to IP ([IP]:22).

debug1: channel 0: new [client-session]

debug3: ssh_session2_open: channel_new: 0

debug2: channel 0: send open

#认证通过后，ssh服务器端打开一个channel，用于处理ssh请求

.....

.....

debug2: channel_input_open_confirmation: channel 0: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug3: receive packet: type 99

debug2: channel_input_status_confirm: type 99 id 0

debug2: PTY allocation request accepted on channel 0

debug2: channel 0: rcvd adjust 2097152

debug3: receive packet: type 99

debug2: channel_input_status_confirm: type 99 id 0

debug2: shell request accepted on channel 0

#channel 0的shell申请被接受，ssh连接已经建立

Last login: Sat Nov  2 05:04:03 2019 from IP

       __|  __|_  )

       _|  (     /   Amazon Linux 2 AMI

      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

[[email protected] ~]$

#######################################

综合来看，SSH连接的第一阶段为TCP建联，也就是通常的TCP三次握手机制，服务器端一般为TCP 22端口，也不排除自定义配置，这里不再赘述。

当TCP 22建联完毕后，ssh客户端和ssh服务器端开始进行通信，交换一系列信息，例如双方支持的加密算法等。进而ssh客户端将本地密钥发送到ssh服务器端进行认证，认证完毕后，ssh服务器端会将认证结果反馈给ssh客户端。如果认证成功的话，ssh服务器端会开启一个channel，用于处理来自ssh客户端的业务请求，该channel会与PTY进行关联，并申请一个shell终端。如果认证、权限等一切正常，channel打开，ssh客户端和ssh服务器端的ssh连接可用。

以上为一个正常的SSH连接所经历的环节。接下来，我们看一下各个环节中可能会遇到的问题。

二、网络部分问题

通过上述分析，我们知道SSH连接首先要进行TCP 22端口的建联，如果这个时候网络部分出现问题，SSH连接肯定无法正常工作。这个时候，我们可以使用telnet命令来测试下到特定IP地址的TCP 22端口是否通畅。

以下为一个通畅的telnet测试，这里为了减少不必要的影响，略去了测试用的对端IP地址。

###################

[email protected]:~$ telnet IP 22

Trying IP...

Connected to IP.

Escape character is '^]'.

SSH-2.0-OpenSSH_7.4

###################

除此之外，还有两种比较常见的情况，分列如下：

1、Connection timed out报错

##################

[email protected]:~$ telnet IP 22

Trying IP...

telnet: Unable to connect to remote host: Connection timed out

##################

此时的wireshark抓包显示如下：

可以看到本地客户端向服务器端发起了TCP的SYN包，但是服务器端一直没有响应，进而出发了TCP Retransmission，多次重传后，导致超时，也就是此处看到的Connection timed out.

2、Connection refused报错

####################

[email protected]:~$ telnet IP 22

Trying IP...

telnet: Unable to connect to remote host: Connection refused

####################

此时的wireshark抓包显示如下：

可以看到本地客户端向服务器端发起了TCP的SYN包，同时服务器端回了一个RST，ACK，将对应的TCP连接进行了重置。

将二者对比，我们可以发现，同样是无法进行TCP建联，二者有着不同的含义。

对于公有云实例来说，Connection timeout代表着流量还未到达实例，在中间的某个环节已经被阻断。最常见的场景是实例的安全组、网络ACL部分存在阻断，例如没有放行对应的端口到本地客户端所在的共有IP地址等问题。排查的时候，可以先检查下实例所在的安全组，并查看本地客户端的公有IP地址，进而确保安全组中放行了对应的端口给该公有IP地址。

而Connection refused这种情况，从抓包已经看到TCP报文已经到了服务器，但是服务器由于某些原因并未接收对应的TCP报文。这种场景通常对应着实例内部，也就是操作系统层面的某些设置，例如SSH服务器端进程没起来，或者监听在不同的端口上；也有可能实例上运行了防火墙(iptables、firewalld等)，不允许来自客户端的公有IP与SSH服务器端建立连接。这种场景下的排障稍微复杂一些，尤其是AWS EC2实例，由于此时已经无法ssh登陆，通常需要关停实例，卸载根卷，挂在到其它的实例中，分析配置文件、日志等，确定可能存在的问题，进而做相应的修改后，再挂载回原来的实例中，重新启动实例，尝试看是否可以解决问题。而对于阿里云的ECS实例，相应的排查则要简单的多，因为阿里云ECS实例提供了VNC功能，可以直接在console端连接到实例内部，虽然会卡一些，但毕竟可以登录进去，有点类似于物理机的管理接口，例如惠普的ILO接口、戴尔的iDrac接口、VMware的管理控制台等。这里先挖个坑，后续我们会开设AWS EC2专栏，讲解如何对EC2的EBS卷做离线分析。

三、鉴权相关问题

如果前边的TCP建联已经通过，那么接下来的问题则多数集中在鉴权等相关问题上。这里最常见的就是Permission denied报错。

以下为我们的一个讲解案例，还是通过ssh开启verbose日志的方式(-vvv选项)，我们来看一下这个过程中发生了什么：

##############

debug1: Next authentication method: publickey

debug1: Trying private key: /home/user/.ssh/user.pem

#调用本地的密钥文件

.....

.....

debug2: we sent a publickey packet, wait for reply

#本地客户端将publickey认证内容发送给服务器端

debug3: receive packet: type 51

#服务器端认证失败，返回相应的结果

.....

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic

debug2: we did not send a packet, disable method

debug1: No more authentication methods to try.

#此时已经没有其它可继续认证的方法

centos@IP: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

#使用centos用户进行认证，返回Permission denied报错，认证失败

#################

从上述日志，我们能得到的有用信息主要包括以下几点：

首先，客户端和服务器端使用的是密钥认证方式；其次，客户端的密钥文件为 /home/user/.ssh/user.pem；第三，客户端使用的登录用户名为centos。

这个时候，客户端能做的排查包括以下几点：

第一，客户端尝试使用的认证方式是否正确，比如服务器端其实使用的是用户名和密码，而发送的命令格式为密钥认证

第二，确认密钥文件对应的登录用户名，也就是说此处的 /home/user/.ssh/user.pem是否为centos用户的密钥文件

第三，确认centos用户是不是正确的登录用户

而在服务器端，我们能看到的信息会更多一些，也更贴近报错本身的含义。一般来说，SSH登录相关的报错与安全息息相关，相应的日志一般记录在/var/log/secure文件中(比如Amazon Linux，CentOS，RHEL等操作系统)。

查看日志有一个小技巧，日志一般条目众多，此处我们可以根据发生的时间点有针对性的查看，极大的减少排查范围。以当前报错为例，查看到的日志内容如下：

#############

Nov  2 06:56:03 ip-xx-xx-xx-xx sshd[4495]: Invalid user centos from IP port 54632

Nov  2 06:56:03 ip-xx-xx-xx-xx sshd[4495]: input_userauth_request: invalid user centos [preauth]

#############

我们可以看到，这里的报错信息非常直观，invalid user centos，也就是说我们使用的登录用户名centos是无效的。

考虑到测试用的是AWS EC2实例，使用的是Amazon Linux操作系统，那么当前的问题的解法应该是将centos用户替换为ec2-user，即可顺利登录。

常言道，幸福的家庭千篇一律，不幸的家庭各部相同。对于SSH排障来说，这个说法也是很适用的。我们需要根据具体的报错内容，做进一步的分析，以确定可能存在的问题。

四、尾声

SSH作为一个基础服务，其涵盖的内容相当广泛，我们在这里分析的只是最最基础的一些，一些更为高级的话题，例如ssh集成ldap认证，PAM模块的应用及配置等内容，篇幅限制暂不详细展开，感兴趣的朋友们可以尝试一下。

希望上述内容能对你有所帮助。