Why can't I ssh into a server from my office network?

Question

I have trouble connecting via SSH to a server whenever I am in the office. I get as far as being prompted for my password and then after that there's a long wait which always ends in a

Write failed: Broken pipe

This is only for connecting via SSH. I use svn to commit files to a repository hosted on the same server and there are no hitches.

Furthermore, this only happens in our office. When I go the university or whenever I am at home or at the coffee shop I am able to connect seamlessly. There are no firewalls in our office. It's just a basic wireless router connected to a modem setup. It's the same setup I have at home and I guess the same setup in the coffee shop.

What are the causes for a broken pipe and why does this phenomenon only happen when I try connect via SSH and not when I work with svn on the same server?

Updated: Some debug logs after authentication:

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

UPDATE 2011-14-07: I am able to connect to the server via SSH now. I didn't do anything but that's because there is no one in the office but me! Having said that, is it possible that it has something to do with the number of sessions an SSH server can handle?

UPDATE 2011-14-07: I try to login via SSH through Putty on another machine running windows together with my current SSH session in Ubuntu and now it seems my SSH session in Ubuntu has been dropped. I can't type into the terminal. Is Putty the culprit now?

Answer 1

This looks like something odd going on in the wireless router. The fact that two SSH sessions from different machines seem to interfere is very probably relevant.

Among the things that a wifi router is known to do, and that may impact a SSH connection, are MTU/windowing (which ought to get you a hung connection) and TCP keepalive dropping (which just might lead to a "broken pipe" error).

So I'd try disabling TCP keepalive option from SSH:

ssh -C -o TCPKeepAlive=no yourserver

and see whether this changes anything. I'd also try, if at all possible, connecting the computer to the router using a cable, or temporarily using a different router.

Note a similar problem here where use Ipwaqas states,

This is very old problem for me; Every time I reinstall my system I have to add the line below to my /etc/ssh/ssh_config to avoid “Write failed: Broken pipe” issue.

ServerAliveInterval 120
OR
ClientAliveInterval 15

There are some funny options in WiFi routers dealing with client programs, but they're normally games and suchlike; I wouldn't expect there being anything involving SSH. But just in case, check that out, too.

Answer 2

Based on the additional information, I suggest the following diagnostic steps:

When I try this (successfully), one of the next entries is a PTY allocation. I suggest trying the same ssh command with -t and -T, to see if that affects whether it works or not.

Other things to look at include: * Seeing whether the problem follows the client or the server. * See if you can run remote commands (e.g. ssh some.host echo "connected") * See if you can use scp.

These should help narrow down the problem, even if they don't solve it.

Answer 3

Have you looked into this..

https://bbs.archlinux.org/viewtopic.php?id=97003