SSH сессия "замирает"
Kotikov Aleksey
Столкнулся с очень неприятной проблемой.
С одной из подконтрольных машин с Sarge 3.1r5 невозможно прямо
соединиться по ssh. При вводе любой корректной пары логин-пароль сессия
"замирает".
Метод, с помощью которого выхожу из положения:
ssh -TN -L 2222:127.0.0.1:22 some...@badhost.ru
и оставить соединение "висеть". Далее:
ssh -p 2222 some...@127.0.0.1
После этого получаем рабочую сессию на целевой машине badhost.ru
Есть еще около 70 машин аналогичной программной и аппаратной
конфигурации. Сверил с ними конфиги. Все, что лежит в /etc/ssh/ и
/etc/pam.d/ абсолютно идентично работающим машинам. /etc/pam.conf тоже.
В /var/log/auth.log про "повисшие" соединения написано следущее:
Dec 24 20:28:38 server saslauthd[1423]: server_exit : master exited:
1423
Dec xx 20:28:38 server sshd[1450]: Received signal 15; terminating.
Dec xx 20:30:22 server saslauthd[1427]: detach_tty : master pid is:
1427
Dec xx 20:30:22 server saslauthd[1427]: ipc_init : listening on
socket: /var/run/saslauthd/mux
Dec xx 20:30:24 server sshd[1454]: Server listening on 0.0.0.0 port 22.
Dec xx 20:30:59 server login[1493]: (pam_unix) session opened for user
someuser by LOGIN(uid=1006)
Если кто сталкивался с подобным или знает куда копать, поделитесь мыслями.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Yauhen Kharuzhy
Проверьте MTU/MRU и прохождение больших пакетов до нужного хоста. Хотя
симптомы не совсем похожи, но всё же...
--
Yauhen Kharuzhy jekhor _at_ gmail.com
JID: j...@xdsl.by
A: No
Q: Should I quote below my post?
Gmail.com
Kotikov Aleksey
debug3: packet_send2: adding 32 (len 26 padlen 6 extra_pad 64)
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive).
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 0
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug1: Sending environment.
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env LESSOPEN
debug3: Ignored env LESSCLOSE
debug3: Ignored env _
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
Kotikov Aleksey
>
> Вот то, что идет после ввода правильного пароля:
> debug3: packet_send2: adding 32 (len 26 padlen 6 extra_pad 64)
> debug2: channel 0: open confirm rwindow 0 rmax 32768
>
>
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)
debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote host badhost.ru: Connection timed out
Connection to badhost.ru closed.
debug1: Transferred: stdin 0, stdout 0, stderr 112 bytes in 973.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1
debug1: Exit status -1
Max Dmitrichenko
> On Tue, Jan 29, 2008 at 11:29:04PM +0300, Kotikov Aleksey wrote:
> > Если кто сталкивался с подобным или знает куда копать, поделитесь мыслями.
>
> Проверьте MTU/MRU и прохождение больших пакетов до нужного хоста. Хотя
> симптомы не совсем похожи, но всё же...
Угу, а за одно проверить не перекрыл ли какой-нить криворукий админ ICMP на
пути от одного хоста к другому.
--
Макс Дмитриченко
Mikolaj Golub
On Tue, 29 Jan 2008 23:29:04 +0300 Kotikov Aleksey wrote:
KA> Доброе время суток, сообщество.
KA> Столкнулся с очень неприятной проблемой.
KA> С одной из подконтрольных машин с Sarge 3.1r5 невозможно прямо
KA> соединиться по ssh. При вводе любой корректной пары логин-пароль
KA> сессия "замирает".
KA> Метод, с помощью которого выхожу из положения:
KA> ssh -TN -L 2222:127.0.0.1:22 some...@badhost.ru
KA> и оставить соединение "висеть". Далее:
KA> ssh -p 2222 some...@127.0.0.1
Т.е. получается, если сессия "исходит" от локального хоста (127.0.0.1) то все
ок, а если от чужого, то "подвисает".
KA> После этого получаем рабочую сессию на целевой машине badhost.ru
KA> Есть еще около 70 машин аналогичной программной и аппаратной
KA> конфигурации. Сверил с ними конфиги. Все, что лежит в /etc/ssh/ и
KA> /etc/pam.d/ абсолютно идентично работающим машинам. /etc/pam.conf
KA> тоже.
А эти смотрели?
/etc/pam.d/ssh
/etc/login.defs
/etc/passwd (на предмет shell)
/etc/profile
профайлы в домашних дирах (хотя это вряд ли, если не зависит от пользователя)
другие места, которые сходу не пришли в голову...
KA> В /var/log/auth.log про "повисшие" соединения написано следущее:
KA> Dec 24 20:28:38 server saslauthd[1423]: server_exit : master
KA> exited: 1423
KA> Dec xx 20:28:38 server sshd[1450]: Received signal 15; terminating.
KA> Dec xx 20:30:22 server saslauthd[1427]: detach_tty : master pid
KA> is: 1427
KA> Dec xx 20:30:22 server saslauthd[1427]: ipc_init : listening on
KA> socket: /var/run/saslauthd/mux
KA> Dec xx 20:30:24 server sshd[1454]: Server listening on 0.0.0.0 port 22.
KA> Dec xx 20:30:59 server login[1493]: (pam_unix) session opened for user
KA> someuser by LOGIN(uid=1006)
т.е. непосредственно к подвисшей сессии относится только последняя строчка?
Или все-таки все?
--
Mikolaj Golub
Kotikov Aleksey
1. ssh сессия прекрасно запускается только если обращаться к серверу
посредством туннеля (ssh -TN либо openvpn).
2. сервер считает, что к нему законектились, даже если с клиентской
стороны сессия "висит". То есть last показывает дату и продолжительность
соединения, а на серваке запускается bash.
Alexey Lobanov
> В процессе экспериментов обнаружилось еще несколько примечательных фактов:
> 1. ssh сессия прекрасно запускается только если обращаться к серверу
> посредством туннеля (ssh -TN либо openvpn).
> 2. сервер считает, что к нему законектились, даже если с клиентской
> стороны сессия "висит". То есть last показывает дату и продолжительность
> соединения, а на серваке запускается bash.
Что-то похожее я сейчас вижу на сервере, который стоит за LinkSys'овским
"типа файрволлом". Через 5 минут неактивности бдительный файрволл молча
перестаёт пропускать пакеты данного соединения со стороны Интернета. Но
первый же пакет со стороны сервера - например, убиение screen с выдачей
чего-то на терминал - полностью восстанавливает проводимость.
А.Л.