說明：文章看着很粗糙，並且不夠細緻。主要是爲大家提供解決問題的思路和排錯的思想；
情景再現：公司的機器都是統一用jumpserver管理，某一天發現連接其中一臺web機器特別慢，13秒左右，並且sudo切換 root用戶時候也特別慢。
問題分析：
1.先判斷會不會是sudo的問題，大多數做法就是 輸入hostname 命令 得到我們的主機名 ，然後編輯/etc/hosts 添加 本機與主機名的映射 從而達到 sudo 速度提升的效果。但是針對我今天說的問題是沒用的。
2.ssh是慢的第一個關卡，並且影響ssh 慢的原因有很多，那麼問題的定位就是ssh相關了。
網上的做法有很多，比如禁止ssh 啓動dns反向解析UseDNS no；GSSAPIAuthentication=no ；
這倆個參數的設置對於優化ssh 是無可厚非的，但是首先要分析ssh整個連接過程中暴露的問題點，用的是 debug 調試模式。
ssh -v -p 端口號 用戶名@主機ip
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 #第一階段,雙方確認協議版本號和ssh版本號
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for
debug1: Connecting to 192.168.1.155 [192.168.1.155] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent #第二階段,雙方確認/支持使用的數據加密算法,消息摘要算法,主機公鑰等信息.
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host '192.168.1.155 (192.168.1.155)' can't be established.
RSA key fingerprint is d4:58:f1:dc:d7:d4:fd:e0:2a:c3:dd:fd:79:51:2e:91.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.155' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Next authentication method: publickey //先嚐試公鑰
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Next authentication method: password #第三階段,進入身份驗證的過程
#第四階段,驗證成功後等到一個新的session,及設置環境變量等,最後得到一個shell.
那麼我們如何分析調試信息？
1.找錯誤
比如：debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
解決：vi /etc/ssh/ssh_config
GSSAPIAuthentication no
分析：GSSAPI ( Generic Security Services Application Programming Interface) 是一套類似Kerberos 5的通用網絡安全系統接口，該接口是對各種不同的客戶端服務器安全機制的封裝，以消除安全接口的不同，降低編程難度，但該接口在目標機器無域名解析時會有問題,使用strace查看後發現，ssh在驗證完key之後，進行authentication gssapi-with-mic，此時先去連接DNS服務器，在這之後會進行其他操作。所以通常關閉；
2.看調試信息卡在哪裏？
因爲我們連接ssh時候會因爲卡住某個環節而連接不上，而我們僅僅只知道他卡了，但是具體卡在哪個環節我們不清楚，通過ssh的調試模式，我們可以定位卡在哪裏，然後複製卡的調試信息 ，谷歌搜索。你懂得。。。。
比如：
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY （一直卡在這個位置）
解決：大多數是考慮到MTU 值 ，可以在網卡配置文件中設置 MTU=1200
分析：https://www.jianshu.com/p/3181b53053dd
------------------------------------------我是快樂的分割線--------------------------------------------------------------------------------------
然而！ 問題並不是這些
還需要結合systemctl status 查看 發現了一個錯誤 :Failed to abandon session scope: Transport endpoint is not connecte,搜索後在github上看到 是因爲 我們的dbus服務中的 systemd-logind 宕掉了，而間接讓ssh 和sudo 特變慢 ， 精確定位到 systemd-logind 後通過 systemctl status systemd-logind 查看 發現因爲錯誤沒有啓動，kill掉所有進程再啓動 重新ssh解決了問題。
我們也可以通過結合wireshark 在ssh連接過程中抓包來定位問題
我會陸續在下面的文章介紹
https://www.cnblogs.com/MYSQLZOUQI/p/4883519.html （附上一個比較全的ssh 概念 加密過程。問題處理的鏈接）
by__________ 阿威