У меня проблемы с SSH на моем Linux-сервере под управлением CentOS. Я могу нормально подключиться к своему серверу, используя PuTTY или ssh из Windows cmd. То же самое и с использованием безопасного FTP. Я могу подключиться к серверу, получить список файлов и все в порядке. Проблема возникает, когда я пытаюсь отправить любое количество данных по сети.
Каждый раз, когда я пытаюсь передать что-либо сверх определенного порогового значения, соединение не устанавливается, и я вижу сообщение «Сброс соединения одноранговым узлом». У меня есть файл sql размером около 3 МБ в моем домашнем каталоге. Если я попытаюсь выполнить его по FTP, он начнет передачу и умрет после передачи примерно 48 КБ. Затем он инициирует новое соединение и передаст еще 48k. Если я использую PuTTY и открываю сеанс, я могу подключиться и войти в систему. Если я попытаюсь cat file.sql снова соединение разрывается, и я получаю сообщение «Соединение сброшено одноранговым узлом». При переходе с моей локальной рабочей станции на сервер ситуация такая же. У меня есть довольно много исходного кода, который мне нужно зафиксировать в моем репозитории svn, размещенном на сервере, но появляется то же сообщение «Сброс соединения одноранговым узлом».
Я знаю, что проблема в моей локальной рабочей станции, потому что я могу без проблем использовать macbook моей жены и ssh для подключения к серверу. Я могу использовать ssh в Linux-боксе друга (используя ту же установку шпатлевки) и sftp на мой сервер с их и загрузить файл, открыть другой сеанс ssh из его коробки на мой сервер и перехватить файл. Итак, что-то происходит, но я не знаю, что именно. У кого-нибудь есть идеи?
Обновить
Я пытался понять это еще немного, и кажется, что существует жесткий предел количества данных, которые я могу передать за один сеанс ssh. Я сразу бью, если сделаю cat file.sql но я также могу продолжать печатать ls -l постоянное количество раз, а также получите сообщение «Соединение сброшено одноранговым узлом». Я пробовал:
Я написал 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, и как часы, когда я набираю 48 КБ переданных данных - сброс соединения одноранговым узлом.
Учитывая, что я могу получить начальное соединение и что в прошлом у меня не было проблем с установкой ftp-соединений на порт 21, не похоже, что проблема в конфигурации моего брандмауэра.
По крайней мере, на данный момент у меня проблема сузилась до порта ssh на моем сервере. Переверните его на 21 и мгновенные проблемы, измените его обратно на 22, вообще никаких проблем ...
Может ли кто-нибудь подумать, почему порт прослушивания имеет значение? Опять же, это вызывает проблемы только на моем компьютере с Windows XP. Дайте мне знать, если у кого-нибудь есть мысли о том, что может вызвать это.
Обновление 2:
Просто сузил проблему, и я исправился - это проблема брандмауэра, но проблема брандмауэра Windows, а не на моем маршрутизаторе. Если я использую порт 21 и отключаю брандмауэр Windows, я не получаю сообщения «Сброс подключения одноранговым узлом». Чтобы ответить на очевидный вопрос, да, порт 21 открыт на брандмауэре Windows.
Поскольку этот компьютер находится за брандмауэром моего маршрутизатора, я могу пока просто отключить его, но мне было бы интересно выяснить, что здесь происходит.
Вы можете решить эту проблему с помощью командной строки с помощью этой команды (введите это как администратор):
netsh advfirewall set global statefulftp disable
Это может быть связано с тем, что ваш маршрутизатор пытается автоматически обрабатывать отслеживание соединения FTP NAT. Это произойдет только на 21-м порту, а не на 22. http://www.faqs.org/docs/iptables/complexprotocols.html