1. 前言

在最近的项目联调过程中，发现在连接上游侧 SFTP 时总是需要等待大约10s+的时间才会出现密码输入界面，这种长时间的等待直接导致的调用文件接口时连接 sftp*超时* 问题。于是决定自己针对该问题进行一下排查，查询了相关资料，并逐个试验了一下网上提供的解决方案，然后在文章中详细记录问题的排查及分析过程，并将收集到的一些常见的 SFTP 的超时原因及解决方案进行了整理如下。

2. 问题排查过程

• 首先使用ssh -v命令（调试模式）进行远程登录调试：

ssh -v -oPort=端口号 root@ip地址

• 在调试模式观察调试信息，确定主要的耗时卡点所在位置

• 根据耗时卡点信息确认问题所属服务端还是客户端；

◦ 假如调试信息卡在debug1: SSH2_MSG_SERVICE_ACCEPT received 位置，则表示主要的耗时卡点在服务端，需要修改服务端的配置文件（）；

◦ 假如调试信息卡在debug1: Next authentication method: gssapi-with-mic 位置，则表示主要的耗时卡点在客户端，需要修改服务端的配置文件（）；

◦ 假如两个阶段停留时间均较长，则需要同时修改服务端和客户端的配置文件；

• 经排查发现此次 SFTP 连接超时的调试信息在 debug1: SSH2_MSG_SERVICE_ACCEPT received 位置停留时间较长，故而需要修改服务端的配置文件，需要调整文件如下：

◦ 关闭 DNS 反向解析：在 Linux 中，默认是开启了 SSH 的反向 DNS 解析，服务器会先根据客户端的 IP 地址进行 DNS PTR 反向查询出客户端的主机名，然后根据查询出的客户端主机名进行 DNS 正向 A 记录查询，并验证是否与原始 IP 地址一致，通过此种措施来防止客户端欺骗（说到底还是反向查询的问题）。这个会消耗大量时间，是连接慢的主要卡点，因此可以通过关闭该选项；

配置文件位置：

/etc/ssh/sshd_config

需要修改选项

UseDNS no

◦ 关闭 GSSAPI 认证：服务器端启用了 GSSAPI。登陆的时候客户端需要对服务器端的 IP 地址进行反解析，如果服务器的 IP 地址没有配置 PTR 记录，那么就容易在这里卡住了。

配置文件位置同DNS 选项文件，具体修改内容：

GSSAPIAuthentication  no

◦ 【未尝试该方案】nsswitch；修改配置文件nsswitch中hosts选项；修改 “hosts” 选项，hosts： files dns 表示是对于访问的主机进行域名解析的顺序，是先访问 file，也就是/etc/hosts文件，如果 hosts 中没有记录域名，则访问 dns进行域名解析。如果 dns 也无法访问，就会等待访问超时后返回，因此等待时间比较长。注意：如果 SERVER 需要通过域名访问其他服务器，则需要保留此行。

nsswitch 文件位置：

/etc/nsswitch.conf

具体修改内容为：（注意：如果 SERVER 需要通过域名访问其他服务器，则需要保留此行。ps：二次强调）

hosts:          files 

◦【未尝试该方案】目标主机 hosts：修改目标主机的/etc/hosts文件，将本地主机的IP和Hostname添加进去；

◦ 修改IgnoreRhosts 选项：IgnoreRhosts参数可以忽略以前登录过主机的记录，设置为yes后可以极大的提高连接速度；

文件位置：

/etc/ssh/sshd_configIgnoreRhosts

具体修改为：

sshd_configIgnoreRhosts yes

• 最后执行/etc/init.d/sshd restart 重启 sshd 进程使上述配置生效即可，通过关闭配置文件中DNS 反向解析和GSS 认证确实可以有效提升SFTP*连接* 速度；那么问题来了？

◦ 为什么需要修改这两个选项呢？

◦ 修改这两个选项会带来什么样的风险么？

◦ 带着这几个问题我们对DNS 反向解析和GSS认证继续进行调研=======

3. 知识扩展

3.1. 什么是 DNS 反向解析？

DNS 的用途通常是将 域名解析 为 IP 地址。这被称为正向解析，我们每次访问互联网上的站点时都会执行此操作。顾名思义，反向 DNS（或 rDNS）是一种将 IP 地址解析为域名的方法。

3.2. 反向 DNS 的查找过程？

在 Windows 中使用nslookup或者ping -a命令，在 Linux 中手动执行 rDNS 查找命令为：

dig -x ip地址

3.3. 什么是 GSS 认证？

GSSAPI – Generic Security Services Application Program Interface，它是另一个身份认证框架，基于这个框架也有多种认证机制的实现，如 Kerberos，NTLM，SPNEGO 等，但最为人所熟知还是 Kerberos5 的实现，所以会有很多人把 “GSSAPI” 等同于 “Kerberos 认证”。GSSAPI 的程序库是 cyrus-sasl-gssapi，它需要依赖 SASL 的共享程序库 cyrus-sasl-lib。

举个栗子==>

客户端连接到服务器说：“Hi，我要登录，我支持 SASL，请问我要如何证明自己的身份？”

服务器收到连接并作出响应：“收到，我也支持 SASL，具体来说支持如下几种 SASL 认证实现：PLAIN，CRAM-MD5，GSSAPI，…”

客户端回答：“我想使用其中的 GSSAPI。”

服务器响应: “收到。你知道 GSSAPI 也是一个认证框架，在 GSSAPI 方式下，具体来说我又支持：Kerberos5，SPNEGO，…”

客户端回复：“让我们使用 Kerberos5 吧，给你我的加密票据…”

◦ 在什么是 GSS 认证的例子中引入了一个新的名词（SASL），那么什么是 SASL？

SASL – Simple Authentication and Security Layer，中文译作：“简单认证与安全层”，它是一个在网络协议中用来认证和数据加密的构架。SASL 的官方定义非常抽象，很难让人直接明白它是做什么的。实际上，我们可以把 SASL 理解为一个用于身份认证（Athentication）的编程框架或者是一组接口定义，不同的认证机制可以基于这个框架编写各自的实现，从而允许客户端和服务器之间通过协商选出一种共同支持的认证机制完成身份认证。引入 SASL 后，应用系统不必再针对某一种认证机制去硬编码，而是具备了认证机制的可插拔能力；对于应用系统的开发者而言，使用 SASL 可以避免从一种认证机制的最底层 API 开始编写实现方案，将精力集中在与 SASL 框架的集成上即可，因为与各种认证机制对接的细节都已由相应的 SASL 插件实现了。作为 SASL 最主流的实现 Cyrus SASL，其官方文档列出了大量开箱即用的插件： https://www.cyrusimap.org/sasl/#features 。SASL 由共享程序库 cyrus-sasl-lib 和若干面向特定认证机制的实现库，如：cyrus-sasl-plain，cyrus-sasl-gssapi 等组成。

emm，已经开始逐渐复杂啦，总结就是 GSSAPI 认证只是一种安全框架和接口标准，具体更深入的相关知识后续学习下再另起一篇文章进行总结哈！

4. 总结

跟着网上给出的解决方法逐个进行验证倒是没有什么难度，比较烧脑的是其中所涉及到的各种修改的原因以及如何根据现有问题定位到去修改该配置。文中涉及到的GSSAPI认证在今天之前完全是一个陌生的概念，现在通过查询资料也只是有了一个浅层的概念认知，后续还需要对文中所引入的相关知识及问题再深入学习！ok，以上就是对今天的 SFTP 连接超时问题进行了排查分析，是一次总结也是一次分享。

作者：京东科技 宋慧超

来源：京东云开发者社区 转载请注明来源