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?