每当我在办公室时，我都无法通过 SSH 连接到服务器。我只能被提示输入密码，然后就是漫长的等待，最后总是以
Write failed: Broken pipe
这仅适用于通过 SSH 连接。我使用 svn 将文件提交到托管在同一服务器上的存储库，没有任何问题。
此外，这种情况只发生在我们的办公室。当我去大学或在家或在咖啡店时，我能够无缝连接。我们的办公室没有防火墙。它只是一个连接到调制解调器设置的基本无线路由器。它和我在家里的设置相同，我想咖啡店的设置也相同。
管道破裂的原因是什么？为什么这种现象只在我尝试通过 SSH 连接时发生，而不是在同一台服务器上使用 svn 时发生？
更新：认证后的一些调试日志：
debug3: packet_send2: adding 48 (len 64 padlen 16 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
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.
debug3: Ignored env ORBIT_SOCKETDIR
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env WINDOWID
debug3: Ignored env GNOME_KEYRING_CONTROL
debug3: Ignored env GTK_MODULES
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env LIBGL_DRIVERS_PATH
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env USERNAME
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env LIBGL_ALWAYS_INDIRECT
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env GDM_KEYBOARD_LAYOUT
debug1: Sending env LANG = en_PH.utf8
debug2: channel 0: request env confirm 0
debug3: Ignored env GNOME_KEYRING_PID
debug3: Ignored env MANDATORY_PATH
debug3: Ignored env GDM_LANG
debug3: Ignored env GDMSESSION
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env LOGNAME
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env LESSOPEN
debug3: Ignored env WINDOWPATH
debug3: Ignored env DISPLAY
debug3: Ignored env LESSCLOSE
debug3: Ignored env XAUTHORITY
debug3: Ignored env COLORTERM
debug3: Ignored env OLDPWD
debug3: Ignored env _
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
更新2011-14-07：我现在可以通过 SSH 连接到服务器。我什么也没做，但那是因为办公室里除了我之外没有其他人！话虽如此，这是否可能与 SSH 服务器可以处理的会话数有关？
更新2011-14-07：我尝试在另一台运行 Windows 的机器上通过 Putty 通过 SSH 登录，同时使用我在 Ubuntu 中的当前 SSH 会话，现在似乎我在 Ubuntu 中的 SSH 会话已被断开。我无法在终端中输入。现在 Putty 是罪魁祸首吗？
答案1
这看起来好像是无线路由器出了什么问题。来自不同机器的两个 SSH 会话似乎相互干扰，这很可能与此有关。
众所周知，wifi 路由器会执行一些可能影响 SSH 连接的操作，包括 MTU/窗口（这会导致连接挂起）和 TCP keepalive 丢弃（这可能会导致“管道破裂”错误）。
因此我尝试从 SSH 禁用 TCP keepalive 选项：
ssh -C -o TCPKeepAlive=no yourserver
看看这是否会有什么变化。如果可能的话，我还会尝试使用电缆将计算机连接到路由器，或者暂时使用其他路由器。
注意类似的问题这里Ipwaqas 指出，
这对我来说是一个非常老的问题；每次我重新安装系统时，我都必须将下面的行添加到我的 /etc/ssh/ssh_config 中以避免“写入失败：管道损坏”问题。
ServerAliveInterval 120 OR ClientAliveInterval 15
WiFi 路由器中有一些处理客户端程序的有趣选项，但它们通常是游戏之类的；我不希望有任何涉及 SSH 的东西。但以防万一，也检查一下。
答案2
根据附加信息，我建议采取以下诊断步骤：
当我尝试这个（成功）时，下一个条目之一是 PTY 分配。我建议尝试使用 -t 和 -T 的相同 ssh 命令，看看这是否会影响它是否有效。
其他需要检查的事项包括：* 查看问题出在客户端还是服务器上。* 查看是否可以运行远程命令（例如 ssh some.host echo "connected"）* 查看是否可以使用 scp。
即使不能解决问题，这些也应该有助于缩小问题范围。