目录列表(ls)错误只在端口22(SFTP)

使用SFTP我突然得到这个结果:

Status: Connecting to 64.207.146.82... Response: fzSftp started Command: open "[email protected]" 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​​duckFileZilaTerminal进行testing,结果相同。 我可以login,但一旦我到达的时候: 目录列表冻结(没有答案)。

我可以访问使用FTP( 端口21 )与不同的用户,问题是,我不能更新任何文件(我一直在作为根工作)。

testing了3台电脑,结果在我的办公室。 然而,我在家里testing,它的工作原理(所以我想这不是主机提供商的问题)。

ssh进行一些debugging:

 ssh -vv [email protected] 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: [email protected],[email protected],[email protected],[email protected],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,[email protected] 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,[email protected] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected],zlib debug2: kex_parse_kexinit: none,[email protected],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,[email protected],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,[email protected],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[email protected] debug2: kex_parse_kexinit: none,[email protected] 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 [email protected]'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 ~]# 

scheme

一旦您使用SSHlogin/连接服务器:

 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 ~]# 

您的networking是否在PPPoE连接之后? 如果您尝试使用scp下载大型(多于一千字节)的文件,是否也有这个问题?

如果是这样,那么看起来你可能有MTU大小的问题。 DSLnetworking的常见问题,如果你谷歌的“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