У меня возникли некоторые проблемы с SSH на моем Linux-сервере под управлением CentOS. Я могу подключиться к своему серверу нормально, используя PuTTY или ssh из windows cmd. То же самое касается использования безопасного FTP. Я могу подключиться к серверу, получить список файлов, и все в порядке. Проблема возникает, когда я пытаюсь отправить любое количество данных по сети.
Всякий раз, когда я пытаюсь передать что-либо за пределы определенного порогового значения, соединение не устанавливается, и я вижу сообщение «Сброс соединения по одноранговой сети». У меня есть файл sql, который составляет около 3 МБ в моем домашнем каталоге. Если я попытаюсь передать его по FTP, он начнет передачу и умрет после того, как будет передано около 48 КБ. Затем он установит новое соединение и передаст еще 48k. Если я использую PuTTY и открываю сеанс, я могу подключиться и войти в систему нормально. Если я попытаюсь cat file.sqlснова, соединение будет прервано, и я получу сообщение «Сброс соединения по пиру». Переход с моей локальной рабочей станции на сервер - та же самая ситуация. У меня есть довольно много исходного кода, который мне нужно зафиксировать в моем хранилище svn, размещенном на сервере, но появляется то же самое сообщение «Сброс соединения по одноранговому узлу»
Я знаю, что проблема на моей локальной рабочей станции, потому что я могу без проблем использовать macbook и ssh моей жены на сервере. Я могу подключиться по ssh в ящик linux друга (используя ту же установку putty) и sftp на свой сервер от него и загрузить файл, открыть другой сеанс ssh из его ящика на мой сервер и отследить файл. Итак, что-то происходит, но я не уверен, что. У кого-нибудь есть идеи?
Обновить
Я пытался выяснить это еще немного, и кажется, что существует жесткое ограничение на объем данных, которые я могу передать за один сеанс SSH. Я сразу же нажимаю на него, cat file.sqlно я также могу продолжать вводить ls -lопределенное количество раз, а также получаю сообщение «Сброс соединения по одноранговой сети». Я пробовал:
- создание новых ключей SSH
- перезапустить мой роутер
- перезагрузка моего компьютера
- перезапуск удаленного сервера
Я написал tcpdump на удаленном сервере, но я не понимаю TCP на таком детальном уровне, что это имеет для меня большой смысл. Я включил отладку в ssh, и вот часть журнала, ведущая к сбросу соединения:
Jul 24 23:10:56 server sshd[4507]: debug1: permanently_set_uid: 500/503
Jul 24 23:10:56 server sshd[4507]: debug1: Entering interactive session for SSH2.
Jul 24 23:10:56 server sshd[4507]: debug1: server_init_dispatch_20
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jul 24 23:10:56 server sshd[4507]: debug1: input_session_request
Jul 24 23:10:56 server sshd[4507]: debug1: channel 0: new [server-session]
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: session 0: link with channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: confirm session
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req pty-req
Jul 24 23:10:56 server sshd[4507]: debug1: Allocating pty.
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_pty_req: session 0 alloc /dev/pts/2
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req shell
Jul 24 23:10:56 server sshd[4508]: debug1: Setting controlling tty using TIOCSCTTY.
Jul 24 23:10:59 server sshd[4507]: Read error from remote host <my-ip>: Connection reset by peer
Jul 24 23:10:59 server sshd[4507]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: deleting credentials
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: closing session
Jul 24 23:10:59 server sshd[4505]: pam_unix(sshd:session): session closed for user <me>
Jul 24 23:10:59 server sshd[4505]: debug1: session_pty_cleanup: session 0 release /dev/pts/2
ОБНОВЛЕНИЕ 2:
Около недели назад я изменил настройки ssh на своем сервере, используя этот пост вики: http://wiki.centos.org/HowTos/Network/SecuringSSH
Поскольку мне иногда требуется доступ к моему серверу с работы, и поскольку на нашем брандмауэре открыт порт 21, я изменил порт ssh на 21. Для дальнейшей диагностики этой проблемы я попытался отменить настройки ssh и изменил порт ssh на 22 Низкий и вот, я не сталкиваюсь с ошибкой, когда я использую порт 22. Измените его обратно на 21, и как по маслу, когда я нажму 48k переданных данных - Соединение сброшено узлом.
Учитывая, что я могу получить исходное соединение и что в прошлом у меня не было проблем с установкой ftp-соединений на порт 21, похоже, что проблема не в конфигурации моего брандмауэра.
По крайней мере, в этот момент проблема сузилась до порта ssh на моем сервере. Переверните его до 21 и получите мгновенные проблемы, измените его на 22, никаких проблем ...
Кто-нибудь может подумать, почему порт прослушивания будет иметь значение? Опять же, это только на моем Windows XP, это вызывает проблемы. Дайте мне знать, если у кого-нибудь есть мысли о том, что может вызвать это.
Обновление 2:
Просто сузил проблему, и я исправился - это проблема брандмауэра, но проблема брандмауэра Windows, а не на моем маршрутизаторе. Если я использую порт 21 и отключаю брандмауэр Windows, я не вижу сообщения «Сброс соединения по одноранговой сети». Чтобы ответить на очевидный вопрос, да, порт 21 открыт на брандмауэре Windows.
Поскольку этот компьютер находится за брандмауэром на моем маршрутизаторе, я могу пока просто отключить его, но мне было бы интересно выяснить, что здесь происходит.