altlinux 4.0 sv медленный sshd [решено]

[shraibikus]

Не могу более корректно придумать название темы.

В общем суть такая - на сервере вращается sshd. Так вот почему-то он у меня на нем делает это как-то чрезчур не растаропно. На столько, что при подключении к нему запрос логина появляется лишь с интервалом через секунд 30 после попытки удаленного подключения, а запрос пароля может и вовсе не появится так как произошел таймаут подключения. Проверяю при этом локально статус демона - говорит что работает. И действительно на следующий раз может появиться окошко запроса пароля (видимо успевает "проскочить" еще ДО таймаута) и если все ок, то логинюсь и дальше работает нормально.

Каковы могут быть причины такого явления. Куда ориентировочно начинать копать?
Ведь на других серверах я такого не наблюдаю даже рядом - везде логин/пароль запрашивает чуть-ли не моментально.

В общем СУБЖ  :(

[lx001]

Надо смотреть, где задержка:

ssh -v user@host

[rotkart]

Такая же проблема и у меня. Везде Школьный Мастер 5.0.1.

Код: [Выделить]

[teacher@teacher Для учеников]$ ssh -v 192.168.101.101
OpenSSH_5.3p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/openssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.101.101 [192.168.101.101] port 22.
debug1: Connection established.
debug1: identity file /home/teacher/.ssh/id_rsa type 1
debug1: identity file /home/teacher/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes256-ctr hmac-md5 none
debug1: kex: client->server aes256-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.101.101' is known and matches the RSA host key.
debug1: Found key in /home/teacher/.ssh/known_hosts:7
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/teacher/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/teacher/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ru_RU.UTF-8
debug1: Sending env LANGUAGE =
Last login: Mon Sep 27 12:33:10 2010 from teacher.local
[teacher@SEAT01 ~]$После сообщения debug1: SSH2_MSG_SERVICE_ACCEPT received соединение висит секунд 20, не меньше, потом соединяется.
Такая машина не одна - все 12 ученических машин отвечают на соединение по ssh с такой задержкой.

[shraibikus]

Локально под рукой только putty. Потому решил зайти удаленно со внешнего.
Получается вот что:

Код: [Выделить]

[shraibikus@wpad ~]$ ssh -v shraibikus@XX.XX.XX.XX
OpenSSH_5.0p1, OpenSSL 0.9.8d 28 Sep 2006
debug1: Reading configuration data /etc/openssh/ssh_config
debug1: Applying options for *
debug1: Connecting to XX.XX.XX.XX [XX.XX.XX.XX] port 22.
debug1: Connection established.
debug1: identity file /home/shraibikus/.ssh/id_rsa type -1
debug1: identity file /home/shraibikus/.ssh/id_dsa type -1
И все. Тишина.
 :(
Т.е. отваливаемся по таймауту. Но с наружки еще и пинг не веселый до хоста, так-что оно и понятно (хотя тоже малоприятного).
Локально попробую позже, если раскурю как использовать клиент OpenSSH под Windows  :D

[speccyfan]

Проверьте корректно ли настроен на сервере резолвинг.

[shraibikus]

Проверьте корректно ли настроен на сервере резолвинг.

/etc/resolv.conf
у меня содержит только одну вменяемую строчку:
nameserver 192.168.1.1

где 192.168.1.1 это модем ADSL, в режиме шлюза.

Или я что-то не то понял?

[bormant]

Откуда бы Вашему ADSL модему знать имена/ip-адреса компьютеров Вашей локальной сети? А ведь именно у него их и спрашивают. А задержка -- как раз таймаут...

[shraibikus]

Откуда бы Вашему ADSL модему знать имена/ip-адреса компьютеров Вашей локальной сети? А ведь именно у него их и спрашивают. А задержка -- как раз таймаут...

Так. Не понял, а зачем мне знать имена компьютеров в локальной сети?
Случай уникальный, компьютеров не много, но в сети требуется поддержка архаичного протокола NETBEUI (есть некоторое ПО, которое изначально настроено под него). В итоге вся сеть работает для общих ресурсов по NETBEUI (в том числе и файловая 1с, досталось в наследство), т.е. там TCP/IP используется только для доступа в Интернет, через этот шлюз с разграничением прав доступа по имени и паролю, а так-же с фильтром некоторых сайтов.
Все это работает.
А вот с ssh такая трабла, озвученная в СУБЖе.

Т.е. теперь мне необходимо поднимать локальный DNS?

[bormant]

ssh ходит по TCP/IP.
Либо поднимать DNS, либо использовать опции, отключающие общение с DNS, либо мириться с задержками.
Выбирать Вам.

Для ориентира читать "man sshd_config", "man ssh_config", "man ssh" в той части, где есть упоминание DNS.

[shraibikus]

ssh ходит по TCP/IP.
Либо поднимать DNS, либо использовать опции, отключающие общение с DNS, либо мириться с задержками.
Выбирать Вам.

Для ориентира читать "man sshd_config", "man ssh_config", "man ssh" в той части, где есть упоминание DNS.

Хорошо. Спасибо, это (UseDNS No) сделаю но очевидно уже только при локальном подходе. Когда буду на точке.
Однако, теперь мне не ясна логика почему-же ssh "тупит" при подключении снаружи? Ведь снаружи мы можем опросить наше имя, как-бы.
ADSL модем смотрит в мир и резолвит. Я прихожу по нему через его port-map на ssh и получаю точно ту-же ситуацию - sshd ну очень долго думает.
Но, как я понимаю тут-то он должен получить имя ДНС-же? Или проблема не в этом?

[bormant]

Сколь виноват DNS определить можете только Вы, например, при помощи tcpdump.

Если не установлен, ставим
# apt-get install tcpdump

Смотрим, что происходит на сервере ssh:
# tcpdump -i eth0 -nn
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

В этом примере в другом терминале подключаюсь сам к себе по ssh, на сервере ssh наблюдаем:
18:26:52.402320 IP 10.0.2.15.1024 > 192.168.1.1.53: 9985+ PTR? 15.2.0.10.in-addr.arpa. (40)
18:26:52.404971 IP 192.168.1.1.53 > 10.0.2.15.1024: 9985 NXDomain* 0/1/0 (90)

- обратный (PTR) DNS-запрос от 10.0.2.15 на сервер DNS 192.168.1.1 порт 53
- следом мгновенный ответ DNS-сервера (запрос в 18:26:52.402320, ответ в 18:26:52.404971)

Если у Вас в этом случае будет пауза -- ответ очевиден.
Если не будет, будете искать другую причину...

[shraibikus]

Всем спасибо.
UseDNS No
действительно помог.

P.S. хотя я по прежнему не понимаю, почему-же тогда доступ к серверу с наружи проходил с задержкой (наружу DNS работает. Проверял уже и так и эдак, чисто исходя из спортивного интереса).