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连接超时问题进行了排查分析，是一次总结也是一次分享。

作者：京东科技 宋慧超

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