僅在埠 22 (SFTP) 中出現目錄列表 (ls) 錯誤

使用SFTP我突然得到這個結果：

Status: Connecting to 64.207.146.82...
Response:   fzSftp started
Command:    open "root@64.207.146.82" 22
Command:    Pass: *********
Status: Connected to 64.207.146.82
Status: Retrieving directory listing...
Command:    pwd
Response:   Current directory is: "/root"
Command:    ls
Status: Listing directory /root
Error:  Connection timed out
Error:  Failed to retrieve directory listing

我在Cyber​​duck、FileZila和Terminal進行了測試，結果相同。我可以登錄，但一旦我到達以下時間點：目錄列表凍結（沒有答案）。

我可以使用 FTP（埠 21）與不同的使用者訪問，問題是我無法更新任何文件（我一直以 root 身份工作）。

在 3 台電腦上測試，在我的辦公室也有同樣的結果。但是，我在家裡進行了測試並且它可以工作（所以我猜這不是託管服務提供商的問題）。

從 ssh 進行一些調試：

ssh -vv root@domain.com
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to domain.com [64.207.146.82] port 22.
debug1: Connection established.
debug1: identity file /Users/Admin/.ssh/id_rsa type -1
debug1: identity file /Users/Admin/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Admin/.ssh/id_dsa type -1
debug1: identity file /Users/Admin/.ssh/id_dsa-cert 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.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 128/256
debug2: bits set: 543/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'domain.com' is known and matches the RSA host key.
debug1: Found key in /Users/Admin/.ssh/known_hosts:2
debug2: bits set: 508/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/Admin/.ssh/id_rsa (0x0)
debug2: key: /Users/Admin/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/Admin/.ssh/id_rsa
debug1: Trying private key: /Users/Admin/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
root@domain.com's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to domain.com ([64.207.146.82]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Fri Dec 21 19:55:45 2012 from ip5-222-15-186.ct.co.cr
############################################################
                    (mt) shortcuts
############################################################

To see your Plesk password, type: p

To rebuild your Apache/Web Server configuration, type: web

To rebuild your Qmail/Mail Server configuration, type: mchk

To see your Qmail/Mail Server queue, type: q

To completely restart your Qmail/Mail server, type: r

To connect to your MySQL server as admin, type: my

To apply the latest Plesk microupdates, type: up

To get rid of these messages/aliases, edit your /root/.bash_profile

[root@domain ~]#

解決方案：

使用 SSH 登錄/連接伺服器後：

p link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue 
   link/void 
[root@domian ~]# ip link set eth0 mtu 1400
SIOCSIFMTU: No such device
[root@domian ~]# ip link set venet0 mtu 1400
[root@domian ~]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue 
   link/void 
[root@domian ~]#

您的網路是否支持 PPPoE 連接？如果您嘗試使用 scp 下載大（超過一千字節）文件，您是否也遇到此問題？

如果是這樣，那麼看起來您可能遇到了 MTU 大小問題。DSL 網路的常見問題，如果你用Google搜尋“pppoe mtu”，你會發現很多點擊。例如，思科有一個很好的解釋。

簡短的簡化版本是，當客戶端和伺服器協商最大 MTU 大小時，它們會根據自己的直接連接（通常是 LAN）協商它，並且當它們之間存在具有較小最大允許 MTU 大小的連結時（即PPPoE 鏈路），較大的數據包開始失去。

通常可以通過以下方式解決：

iptables -t mangle -A POSTROUTING -o ppp+ \
   -p tcp -m tcp --tcp-flags SYN,RST SYN \
   -j TCPMSS --clamp-mss-to-pmtu

更新：由於似乎在途中沒有任何 PPP 連接，您可以嘗試降低伺服器上的介面 MTU 作為測試，這樣您就知道這是否是問題所在。例如，您可以使用以下命令檢查目前值：

ip link show

在輸出中查找“MTU”。並暫時降低它（假設eth0是你的界面），試試

ip link set eth0 mtu 1400

引用自：https://serverfault.com/questions/460082