Почему я не могу зайти на сервер из моей офисной сети?

Question

У меня проблемы с подключением через 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: Я пытаюсь войти через SSH через Putty на другом компьютере с Windows вместе с моим текущим сеансом SSH в Ubuntu, и теперь кажется, что мой сеанс SSH в Ubuntu был прерван. Я не могу набрать в терминале. Является ли Putty виновником сейчас?

Answer 1

Это выглядит как-то странно в беспроводном маршрутизаторе. Тот факт, что два сеанса SSH на разных машинах, похоже, мешают друг другу, очень важен.

Среди вещей, которые, как известно, делают Wi-Fi-маршрутизатор и которые могут повлиять на соединение SSH, это MTU/ управление окнами (что должно привести к зависанию соединения) и сброс активности TCP-трафика (что может привести к ошибке "сломанный канал"). ).

Поэтому я бы попробовал отключить опцию TCP keepalive в SSH:

ssh -C -o TCPKeepAlive=no yourserver

и посмотрим, изменит ли это что-нибудь. Я бы также попытался, если это вообще возможно, подключить компьютер к маршрутизатору с помощью кабеля или временно использовать другой маршрутизатор.

Обратите внимание на аналогичную проблему здесь, где используют состояния Ipwaqas,

Это очень старая проблема для меня; Каждый раз, когда я переустанавливаю свою систему, мне нужно добавить следующую строку в мой /etc /ssh /ssh_config, чтобы избежать проблемы «Ошибка записи: сломанная труба».

ServerAliveInterval 120
OR
ClientAliveInterval 15

В роутерах WiFi есть несколько забавных опций, связанных с клиентскими программами, но обычно это игры и тому подобное; Я бы не ожидал, что что-то будет с SSH Но на всякий случай, проверьте это тоже.

Answer 2

Основываясь на дополнительной информации, я предлагаю следующие диагностические шаги:

Когда я пытаюсь это (успешно), одна из следующих записей - это распределение PTY. Я предлагаю попробовать ту же команду ssh с ключами -t и -T, чтобы посмотреть, влияет ли это на то, работает ли она или нет.

Другие вещи, на которые следует обратить внимание:* Видение, следует ли проблема клиенту или серверу. * Проверьте, можете ли вы запускать удаленные команды (например, ssh some.host echo "connected")* Проверьте, можете ли вы использовать scp.

Это должно помочь сузить проблему, даже если они не решат ее.

Answer 3

Вы смотрели на это ..

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