解决OpenSSH“Error:Connectionclosedbyserverwithexitcode128”错误(ZT)

昨晚&＃xff0c;使用 FileZilla 的 SFTP 连接 Ubuntu Server 10.10 时碰到一个诡异错误&＃xff1a;

Filezilla client 日志信息 代码

1. 状态: 正在连接 10.1.13.69... 
2. 响应: fzSftp started 
3. 命令: keyfile "E:\key\Bert_id_rsa.ppk"
4. 命令: open "tdhadoop&＃64;10.1.13.69" 22
5. 状态: Connected to 10.1.13.69
6. 错误: Connection closed by server with exitcode 128
7. 错误: 无法连接到服务器 

而使用 Putty 连接就没有问题&＃xff0c;使用相同的 key 文件。这说明问题不是出现公钥密码及主机验证上&＃xff0c;即 SSH 连接没有问题。

根据错误提示&＃xff1a;Connection closed by server with exitcode 128 。其中 128 表示传入了无效参数&＃xff0c;参考自 ”Exit Codes With Special Meanings “。在 OpenSSH FAQ 上没有找到答案&＃xff0c;然后在其 FileZilla Forums 上找到一篇相关文章 ”Connection closed by server with exitcode 128 “。该文章提示使用”调试“模式运行&＃xff0c;以便输出更多有价值错误信息。于是根据 “Logging in FileZilla ” 提示设置 Filezilla Client&＃xff0c;日志输出如下&＃xff1a;

Filezilla client 日志信息 代码

1. 状态: 正在连接 10.1.13.69... 
2. 追踪: Going to execute "F:\FileZilla FTP Client\fzsftp.exe"
3. 响应: fzSftp started 
4. 追踪: CSftpControlSocket::ConnectParseResponse(fzSftp started) 
5. 追踪: CSftpControlSocket::SendNextCommand() 
6. 追踪: CSftpControlSocket::ConnectSend() 
7. 命令: keyfile "E:\key\Bert_id_rsa.ppk"
8. 追踪: CSftpControlSocket::ConnectParseResponse() 
9. 追踪: CSftpControlSocket::SendNextCommand() 
10. 追踪: CSftpControlSocket::ConnectSend() 
11. 命令: open "tdhadoop&＃64;10.1.13.69" 22
12. 追踪: Looking up host "10.1.13.69"
13. 追踪: Connecting to 10.1.13.69 port 22
14. 追踪: Server version: SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu4 
15. 追踪: Using SSH protocol version 2
16. 追踪: We claim version: SSH-2.0-PuTTY_Local:_May_22_2011_19:21:03
17. 追踪: Doing Diffie-Hellman group exchange 
18. 追踪: Doing Diffie-Hellman key exchange with hash SHA-256
19. 追踪: Host key fingerprint is: 
20. 追踪: ssh-rsa 2048 6c:df:ef:0b:98:1b:7f:cb:77:23:3d:c0:ac:29:9d:fd 
21. 追踪: Initialised AES-256 SDCTR client->server encryption 
22. 追踪: Initialised HMAC-SHA1 client->server MAC algorithm 
23. 追踪: Initialised AES-256 SDCTR server->client encryption 
24. 追踪: Initialised HMAC-SHA1 server->client MAC algorithm 
25. 追踪: Pageant is running. Requesting keys. 
26. 追踪: Pageant has 1 SSH-2 keys 
27. 追踪: Successfully loaded 1 key pair from file 
28. 追踪: Trying Pageant key #0
29. 追踪: Key matched loaded keyfile, remove duplicate 
30. 追踪: Sending Pageant&＃39;s response 
31. 追踪: Access granted 
32. 追踪: Opened channel for session 
33. 追踪: Started a shell/command 
34. 状态: Connected to 10.1.13.69
35. 追踪: Server exited on signal "PIPE"
36. 错误: Connection closed by server with exitcode 128
37. 追踪: CControlSocket::DoClose(64) 
38. 追踪: CSftpControlSocket::ResetOperation(66) 
39. 追踪: CControlSocket::ResetOperation(66) 
40. 错误: 无法连接到服务器 

上面日志信息的关键部分&＃xff1a;

Log代码

1. 追踪:    Server exited on signal "PIPE"
2. 错误:    Connection closed by server with exitcode 128

遗憾的是&＃xff0c;由于自己对 Linux 系统不太熟悉&＃xff0c;还是没有解决问题。只能接着该文继续顺藤摸瓜了。

接下来&＃xff0c;查看服务器那边的日志记录&＃xff0c;看能否找到些关键线索。通过在 Ubuntu Documentation 上搜索 OpenSSH Server log file 找到 "OpenSSH Configuring "&＃xff0c;知道其日志记录文件为 /var/log/auth.log 。该问题的相关日志信息如下&＃xff1a;

/var/log/auth.log 代码

1. Jul 24 10:39:22 tdmaster sshd[2096]: Accepted publickey for tdhadoop from 10.1.13.102 port 2740 ssh2 
2. Jul 24 10:39:22 tdmaster sshd[2096]: pam_unix(sshd:session): session opened for user tdhadoop by (uid&＃61;0) 
3. Jul 24 10:39:22 tdmaster sshd[2109]: subsystem request for sftp 
4. Jul 24 10:39:22 tdmaster sshd[2096]: pam_unix(sshd:session): session closed for user tdhadoop 

从 权限认证日志中&＃xff0c;发现 问题根源是由于子系统请求 sftp 请求导致 session 关闭。 同时&＃xff0c;上述日志信息也验证了先前的推断&＃xff1a;publickey 确实是正确的。再在 Google 通过上面的错误信息&＃xff1a;“ subsystem request for sftp session closed ” 搜索&＃xff0c;找到” Debian User Forums - OpenSSH SFTP cannot connect “&＃xff0c;同时通过查看 Ubuntu 的启动配置脚本文件 $HOME/.bashrc 也证明 Ubuntu Server 是基于 Debian 系统实现的。 这样&＃xff0c; 经过大约 2.5 个小时的奋斗终于把问题给解决了。 &＃xff08;解决问题的时间还是太长了&＃xff0c;不是很满意&＃xff0c;希望以后有更大的提高。该时间很大程度上取决于找资料的时间&＃xff1a;如果我能在最短时间内找到最有用的资料&＃xff0c;时间自然 而然地缩短了。 这也反映了我的搜索能力还差远了&＃xff0c;需要提高很多&＃xff09;解决方法如下&＃xff1a;

/etc/ssh/sshd_config 代码

1. # 注意&＃xff1a;SSH 还允许客户端传递系统 Locale 相关的环境变量给服务器 
2. # Allow client to pass locale environment variables 
3. AcceptEnv LANG LC_* 
5. # 将 
6. # Subsystem sftp /usr/lib/openssh/sftp-server 
7. # 替换为 
8. Subsystem sftp internal-sftp 

但我觉得这种解决方案不是很好&＃xff0c;修改该配置信息可能会导致系统服务器那边不能使用 sftp 传输功能&＃xff08;经验证&＃xff0c;修改前后的 sftp 功能都运行正常。参考自 sftp - OpenSSH Manual 、sftp manual &＃xff09;。况且&＃xff0c;其它服务器的同样设置都 OK。所以&＃xff0c;我断定根源不是由此引起的。通过观察发现&＃xff0c;每次登录这台服务器都会输出下面信息&＃xff0c;而其它服务器则不会&＃xff1a;

/dev/tty 代码

1. -bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) 

并且从 sshd_config 配置文件可知&＃xff0c;SSH 会接受 LC_* 环境变量&＃xff0c;见上文。这让我猜测问题的 真正 根源 可能是 LC_ALL 设置不正确而引起的 。通过在 Ubuntu Documentation 上搜索 locale LC_ALL 找到“Environment Variables - Locale setting variables ”、“Locale - Ubuntu Documentation ”。如果设置了 LC_ALL 环境变量&＃xff0c;它会覆盖所有 LC_* 的环境变量值。/etc/default/locale 文件内容如下&＃xff1a;

/etc/default/locale 代码

1. LANG&＃61;"en_US.UTF-8"
2. LC_ALL&＃61;"en_US.UTF-8"  # 引起该问题的根源 
3. LANGUAGE&＃61;"en_US:en"

而其它服务器的 locale 文件则没有设置 LC_ALL 。

接 下来就是去掉该行&＃xff0c;重启 ssh 服务。退出重新登录后&＃xff0c;上面的 -bash 警告信息也没了。 教训&＃xff1a;以后得注意了&＃xff0c;警告也可能引起一些很难解决的问题&＃xff0c;并且这些问题很难追踪。 再通过 FileZilla Client &＃xff0c;看能否访问该服务器&＃xff1f;Ok&＃xff0c;问题终于完美解决了。 这也验证了我上述的猜测。

重点参考资料

1. FileZilla Forums - Connection closed by server with exitcode 128
2. Debian User Forums - OpenSSH SFTP cannot connect
3. Wiki - SSH File Transfer Protocol