1. 程式人生 > >centos的SSH遠端連線服務慢的解決方法

centos的SSH遠端連線服務慢的解決方法

連線慢的主要原因是DNS解析導致

解決方法:

1、在ssh服務端上更改/etc/ssh/sshd_config檔案中的配置為如下內容:
UseDNS no
# GSSAPI options
GSSAPIAuthentication no
然後,執行/etc/init.d/sshd restart重啟sshd程序使上述配置生效,在連線一般就不慢了。

如果還慢的話,檢查ssh服務端上/etc/hosts檔案中,127.0.0.1對應的主機名是否和
uname -n的結果一樣,或者把本機ip和hostname(uname -n結果)加入到/etc/hosts裡。

[[email protected] ~]# uname -n
C64
[
[email protected]
~]# cat /etc/hosts #modi by oldboy 11:12 2013/9/24 127.0.0.1 C64 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.0.0.18 C64 ################


利用ssh-v的除錯功能查詢慢的原因
其實可以用下面的命令除錯為什麼慢的細節(學習這個思路很重要)。

[[email protected] ~]# ssh -v [email protected]地址
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 10.0.0.19 [10.0.0.19] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
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 '10.0.0.19 (10.0.0.19)' can't be established.
RSA key fingerprint is ca:18:42:76:0e:5a:1c:7d:ef:fc:24:75:80:11:ad:f9.
Are you sure you want to continue connecting (yes/no)? yes
=======>這裡就是提示儲存金鑰的互動提示。
Warning: Permanently added '10.0.0.19' (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,password
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: Next authentication method: password
[email protected]
's password: =======>這裡就是提示輸入密碼的互動提示。 debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 Last login: Tue Sep 24 10:30:02 2013 from 10.0.0.18 在遠端連線時如果慢就可以確定卡在哪了。 [[email protected]_A ~]# ssh -v [email protected]地址 OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 10.0.0.17 [10.0.0.17] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type 2 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 debug1: Host '10.0.0.17' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:2 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
上述配置沒配就發現卡到gssapi這。就大概知道是gssapi的問題。

實際上在linux系統優化部分就應該優化SSH服務的此處。

相關推薦

centos的SSH遠端連線服務解決方法

連線慢的主要原因是DNS解析導致 解決方法: 1、在ssh服務端上更改/etc/ssh/sshd_config檔案中的配置為如下內容:UseDNS no# GSSAPI optionsGSSAPIAuthentication no然後,執行/etc/init.d/ss

linux配置mysql資料庫遠端連線失敗的解決方法

今天配置Linux下MySQL資料庫可以遠端訪問的問題,百度這方面的資料有很多,但是方法都一樣,都試過了卻未能解決,記錄一下 第一步:在/etc/mysql/my.cnf下找到bind-address = 127.0.0.1 在這行前加個”#”進行註釋,或

伺服器安裝寶塔面板無法遠端連線資料庫的解決方法

準備搭建一個自己的網站,趁著618優惠買了一臺騰訊雲的linux伺服器,配置一般價格合適。因為對伺服器瞭解不多,所以選擇了使用圖形介面面板來進行管理,因為之前通過阿里雲瞭解到寶塔面板,所以就在伺服器安裝了寶塔linux面板。 在寶塔中進行相關的環境配置之後,就安裝了網站程式,這裡在安裝程式的

mysql遠端連線解決辦法

     伺服器重新啟動了,不知道什麼原因訪問速度特別慢,因為是開啟資料庫操作多的頁面特別明顯,由於是區域網伺服器連線,覺得資料庫問題會比較多。    查詢資料得到結果,預設安裝的MYSQL開啟了DNS的反向解析。域名解析也可以導致網路程式慢,MySQL在處理新的執行緒連線

MySQL之——MySQL遠端連線丟失問題解決方法(Lost connection to MySQL server)

遠端連線mysql是總是提示: Lost connection to MySQL server at ‘reading initial communication packet', system error: 0很明顯這是連線初始化階段就丟失了連線的錯誤。 google

遠端連線速度解決

:如果是區域網內,應該不是網速原因導致的。你可以在兩臺電腦中,分別按Win+R鍵調出執行對話方塊,然後試著輸入並執行“netsh interface tcp set global autotuninglevel=disabled”命令,一般可以解決遠端桌面連線卡

遠端連線區域網內的sql server 無法連線 錯誤與解決方法

第一個錯誤"SQL Server 不存在或訪問被拒絕"通常是最複雜的,錯誤發生的原因比較多,需要檢查的方面也比較多 。一般說來,有以下幾種可能性:   1、SQL Server名稱或IP地址拼寫有誤;   2、伺服器端網路配置有誤;   3、客戶端網路配置有誤。   要解決這個問題,我們一般要遵循以

Navicat無法遠端連線與本地連線MySQL伺服器解決方法

方法一: 使用Navicat遠端連線MySQL伺服器時,提示如下圖情況: 根據查閱不同資料發現,這個問題是因為root使用者使用的加密方式不同,需將其加密方式改為mysql_native_password,即可實現遠端連線MySQL伺服器。 那麼,怎麼來修改root使用者的Auth

windows7 ORA-12514 TNS 監聽程式當前無法識別連線描述符中請求服務解決方法

用PL/SQL連線虛擬機器中的Oracle資料庫,發現又報了“ORA-12514 TNS 監聽程式當前無法識別連線描述符中請求服務”錯誤,幫其解決後,發現很多人遇到過這樣的問題,因此寫著這裡。 也許你沒有遇到過,原因如下: 你oracle安裝成功後,一直未停止資料庫(即資料庫是啟動的),客戶端配置成功後,

遠端桌面超出最大連線數的解決方法/實現多使用者遠端桌面

遠端桌面超出最大連線數的解決方法/2003 解決方法1】 1、找到一臺能連上網路的windows2003的機器 2、開始–執行–輸入“tsmmc.msc”,跳出一個遠端桌面控制檯 3、右鍵點選左邊的“遠端桌面”,選擇“新建遠端桌面”,按照要求填寫要連線的虛擬主機

遠端桌面連接出現"由於網路錯誤,連線被中斷,請重新連線遠端計算機"錯誤的解決方法

     這是因為Certificate子鍵負責終端服務通訊中資料資訊的認證和加密,它一旦被損壞,終端服務的協議元件就會檢測到錯誤,中斷客戶機與終端伺服器之間的通訊。      導致Certificate子鍵損壞的原因很多,如管理員安裝和解除安裝某些系統軟體、對終端服務引數

oracle中監聽程式當前無法識別連線描述符中請求服務解決方法

早上同事用PL/SQL連線虛擬機器中的Oracle資料庫,發現又報了“ORA-12514 TNS 監聽程式當前無法識別連線描述符中請求服務”錯誤,幫其解決後,發現很多人遇到過這樣的問題,因此寫著這裡。 也許你沒有遇到過,原因如下: 你oracle安裝成功後,一直未停止資料庫

不能開啟到主機的連線,在埠1521:連線失敗的解決方法(修改遠端桌面連線埠)

1、修改遠端桌面連線埠   遠端桌面終端服務預設埠為“3389”,為防止他人進行惡意連線,就需要對預設埠進行更改。對此可開啟登錄檔編輯器,依次展開“HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Control\Terminal S

遠端桌面超出最大連線數的解決方法

故 障詳情:用遠端桌面連結登入到終端伺服器時經常會遇到“終端伺服器超出最大允許連結數”。    諸如此類錯誤導致無法正常登入終端伺服器,引起該問題的 原因在於終端服務的預設連結數為2個連結,並且當登入遠端桌面後如果不是採用登出方式退出,而是直接關閉遠端桌面視窗,那麼實際上會話並沒有釋放掉,而是 繼續保留在

遠端桌面提示 “終端伺服器超出了最大允許連線數” 的解決方法

使用 windows 的遠端桌面連線 windows server 系統,有時候會出現 “終端伺服器超出了最大允許連線數” 的問題。 1 分析 因為 windows 終端服務的預設連結數為 2 個連結,而且當登入桌面後是直接關閉遠端桌面視窗,那麼實際上終

解決PLSQL連線oracle方法

原因: G:\app\Administrator\diag\tnslsnr\LS--20171012URU\listener\trace\listener.log 檔案過大(主要原因  監聽日誌) G:\app\Administrator\diag\tnslsnr\LS--2

linux中某個埠拒絕遠端主機連線原因及解決方法

問題描述:  比如在本機telent到192.168.8.170 主機的9000 埠,被拒絕。 [[email protected] log]$ telnet 192.168.8.170 9000 Trying 192.168.8.170...telnet: co

windows遠端桌面超出最大連線數的解決方法

點選--“開始”---“執行” 在裡面輸入: mstsc /console /v:伺服器IP:埠 如果你沒有更改過預設的3389埠號,那麼埠就可以不用寫。 例如:mstsc /console /v:伺服器IP 彈出登入介面後填寫使用者名稱和密碼登入即可。

遠端桌面超出了最大連線數的解決方法

網上找的,摘抄的幾個 mstsc /v:211.211.0.5 /console 需要03的機器來連線03的伺服器 先說增加連線數,目前的兩種方法,我明天去測試一下: (1)開始- 執行- gpedit.msc- 管理模板- Windows元件- 終端服務- 限制連線數

mysql導入解決方法

dump 導入 ket auto write mysql導入 cti uniq roo [mysqldump]max_allowed_packet = 512M [mysqld] interactive_timeout = 120 innodb_change_b