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/ 。SASL由共用程式庫cyrus-sasl-lib和若干面向特定認證機制的實現庫，如：cyrus-sasl-plain，cyrus-sasl-gssapi等組成。

emm，已經開始逐漸複雜啦，總結就是GSSAPI認證只是一種安全框架和介面標準，具體更深入的相關知識後續學習下再另起一篇文章進行總結哈！

4. 總結

跟著網上給出的解決方法逐個進行驗證倒是沒有什麼難度，比較燒腦的是其中所涉及到的各種修改的原因以及如何根據現有問題定位到去修改該設定。文中涉及到的GSSAPI認證在今天之前完全是一個陌生的概念，現在通過查詢資料也只是有了一個淺層的概念認知，後續還需要對文中所引入的相關知識及問題再深入學習！ok，以上就是對今天的SFTP連線超時問題進行了排查分析，是一次總結也是一次分享。

作者：京東科技宋慧超

來源：京東雲開發者社群轉載請註明來源