SSH обрубается

0

0

Помогите!

Никак не могу понять, из-за чего обрубается SSH. Ровно через 10 минут после запуска сервера все удалённые клиенты отключаются и подключиться обратно уже не получается. Остальные службы (http, mysql,..) продолжают работать.

Логи /var/log/auth.log почему-то перестали вестись после 21:56. o_o

Ссылка

←	[ССЗБ] Чем проверить вирусы в вайне?

[странное][звуки]что происходит?

→

места достаточно?

drakmail ★★★★
(24.01.10 11:45:47 MSK)

Ответ на: комментарий от drakmail 24.01.10 11:45:47 MSK

Вроде да. 10 гб точно есть.

papasha
(24.01.10 12:20:54 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 12:20:54 MSK

Что говорит df -h?

Ситуация имела место только один раз или регулярно повторяется?

nnz ★★★★
(24.01.10 15:54:22 MSK)

Ответ на: комментарий от nnz 24.01.10 15:54:22 MSK

Повторяется регулярно.

# df -h
/dev/sda3 7.3G 941M 6.0G 14%
none 1013M 148K 1012M 1%
shm 1013M 0 1013M 0%
/dev/sda1 99M 12M 83M 12%
/dev/sda4 30G 173M 28G 1%

papasha
(24.01.10 16:04:55 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 16:04:55 MSK

Тогда еще вывод mount покажи.

nnz ★★★★
(24.01.10 16:17:14 MSK)

Ответ на: комментарий от papasha 24.01.10 16:04:55 MSK

И cat /etc/ssh/sshd_config (для нормального форматирования — режим LORCODE, теги [code]...[/code]).

nnz ★★★★
(24.01.10 16:21:14 MSK)

Ответ на: комментарий от nnz 24.01.10 16:17:14 MSK

# mount
/dev/sda3 on / type ext3 (rw)
none on /dev type tmpfs (rw, realtime, mode=755)
none on /proc type proc (rw, realtime)
none on /sys type sysfs (rw, realtime)
devpts on /dev/pts type devpts (rw)
shm on /dev/shm type tmpfs (rw, nosuid, nodev)
/dev/sda1 on /boot type ext2 (rw)
/dev/sda4 on /home type ext3 (rw)

papasha
(24.01.10 16:25:26 MSK) автор топика

Ссылка

Ответ на: комментарий от nnz 24.01.10 16:21:14 MSK

/etc/ssh/sshd_config

Port 22
AddressFamily any
ListenAddress 0.0.0.0
Protocol 2
Hostkey ..(rsa)..
Hostkey ..(dsa)..
UsePAM yes
Subsystem   sftp   /usr/lib/ssh/sftp-server

papasha
(24.01.10 16:30:00 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 16:30:00 MSK

А что говорит iptables-save?

Повторяется ли ситуация, если перевесить sshd на другой порт?

nnz ★★★★
(24.01.10 16:40:56 MSK)

Ответ на: комментарий от nnz 24.01.10 16:40:56 MSK

iptables пока не устанавливал.

Перевешивание на другой порт не спасает.

Хочу акцентировать внимание на том, что такое случается ровно через 10 минут пользования ssh.

papasha
(24.01.10 16:44:46 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 16:44:46 MSK

/etc/ssh/ssh_conf

ConnectTimeout 0

?

yltsrc ★
(24.01.10 16:58:45 MSK)

Ответ на: комментарий от yltsrc 24.01.10 16:58:45 MSK

Там всё по дефолту. :)

papasha
(24.01.10 17:04:26 MSK) автор топика

Ссылка

Подними LogLevel для sshd, может что и напишет.

vga ★★
(24.01.10 17:07:53 MSK)

Ответ на: комментарий от papasha 24.01.10 16:44:46 MSK

Где стоит сервер? В той же локалке, что и тот комп, с которого производится доступ? Или в датацентре?

Проблемы наблюдаются при доступе с разных компов? Или с одного и того же?

nnz ★★★★
(24.01.10 17:10:49 MSK)

Ответ на: комментарий от vga 24.01.10 17:07:53 MSK

LogLevel INFO

done.

papasha
(24.01.10 17:13:13 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 17:13:13 MSK

это дефолтный, подыми до DEBUG хотя-бы. Если все-так же ничего не будет, можно и до DEBUG3.

vga ★★
(24.01.10 17:14:39 MSK)

Ответ на: комментарий от nnz 24.01.10 17:10:49 MSK

Пока я постигаю азы администрирования unix-подобных систем, сервер стоит в той же локалке. :) ИП получается по DHCP. 80 и 22 порт трассируется на IP-адрес сервера.

Проблемы наблюдаются как при подключении по внутреннему адресу, так и при подключении по внешнему. С любого компьютера.

Кстати, заодно, hosts.deny - пустой, hosts.allow [code]sshd: ALL: ALLOW httpd: ALL: ALLOW[/code]

papasha
(24.01.10 17:18:33 MSK) автор топика

Ссылка

Ответ на: комментарий от vga 24.01.10 17:14:39 MSK

Ок, попробую.

papasha
(24.01.10 17:20:10 MSK) автор топика

Ссылка

Ммм... всё ещё актуально...

+свежий лог /var/log/auth.log

Jan 24 17:40:25 localhost sshd[1359]: Accepted password for root from 192.168.1.254 port 54073 ssh2
Jan 24 17:40:21 localhost sshd[1359]: debug1: PAM: setting PAM_RHOST to "192.168.1.254"
Jan 24 17:40:21 localhost sshd[1359]: debug1: PAM: setting PAM_TTY to "ssh"
Jan 24 17:40:21 localhost sshd[1359]: Failed none for root from 192.168.1.254 port 54073 ssh2
Jan 24 17:40:25 localhost sshd[1359]: debug1: PAM: password authentication accepted for root
Jan 24 17:40:25 localhost sshd[1359]: debug1: do_pam_account: called
Jan 24 17:40:25 localhost sshd[1359]: Accepted password for root from 192.168.1.254 port 54073 ssh2
Jan 24 17:40:25 localhost sshd[1359]: debug1: monitor_child_preauth: root has been authenticated by privileged process
Jan 24 17:40:25 localhost sshd[1359]: debug1: PAM: establishing credentials
Jan 24 17:40:25 localhost sshd[1359]: pam_unix_session(sshd:session): session opened for user root by (uid=0)
Jan 24 17:40:25 localhost sshd[1359]: debug1: Entering interactive session for SSH2.
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_init_dispatch_20
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jan 24 17:40:25 localhost sshd[1359]: debug1: input_session_request
Jan 24 17:40:25 localhost sshd[1359]: debug1: channel 0: new [server-session]
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_new: session 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_open: channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_open: session 0: link with channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_by_channel: session 0 channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_input_channel_req: session 0 req pty-req
Jan 24 17:40:25 localhost sshd[1359]: debug1: Allocating pty.
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_pty_req: session 0 alloc /dev/pts/0
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_by_channel: session 0 channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_input_channel_req: session 0 req shell
Jan 24 17:40:25 localhost sshd[1362]: debug1: Setting controlling tty using TIOCSCTTY.
Jan 24 17:40:25 localhost sshd[1362]: debug1: PAM: reinitializing credentials
Jan 24 17:40:25 localhost sshd[1362]: debug1: permanently_set_uid: 0/0
Jan 24 17:40:25 localhost sshd[1359]: debug1: monitor_child_preauth: root has been authenticated by privileged process
Jan 24 17:40:25 localhost sshd[1359]: debug1: PAM: establishing credentials
Jan 24 17:40:25 localhost sshd[1359]: pam_unix_session(sshd:session): session opened for user root by (uid=0)
Jan 24 17:40:25 localhost sshd[1359]: debug1: Entering interactive session for SSH2.
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_init_dispatch_20
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jan 24 17:40:25 localhost sshd[1359]: debug1: input_session_request
Jan 24 17:40:25 localhost sshd[1359]: debug1: channel 0: new [server-session]
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_new: session 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_open: channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_open: session 0: link with channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_input_channel_open: confirm session
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_by_channel: session 0 channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_input_channel_req: session 0 req pty-req
Jan 24 17:40:25 localhost sshd[1359]: debug1: Allocating pty.
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_pty_req: session 0 alloc /dev/pts/0
Jan 24 17:40:25 localhost sshd[1359]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_by_channel: session 0 channel 0
Jan 24 17:40:25 localhost sshd[1359]: debug1: session_input_channel_req: session 0 req shell
Jan 24 17:40:25 localhost sshd[1362]: debug1: Setting controlling tty using TIOCSCTTY.
Jan 24 17:40:25 localhost sshd[1362]: debug1: PAM: reinitializing credentials
Jan 24 17:40:25 localhost sshd[1362]: debug1: permanently_set_uid: 0/0

papasha
(24.01.10 18:44:40 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 18:44:40 MSK

А что было в 17:40:25? Успешно залогинился? Гораздо интереснее, что происходит в момент обрыва и после.

Попробуй поковыряться в других логах, в частности, в messages, dmesg, daemon, cron, логи из подкаталога kernel (если он есть).

nnz ★★★★
(24.01.10 21:57:22 MSK)

Ответ на: комментарий от nnz 24.01.10 21:57:22 MSK

Кстати, ещё один вопрос возник: можно ли программно заставить сетевую карту отключаться (средствами Арч Линукс) после n-ного времени простоя?

papasha
(24.01.10 22:03:46 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 22:03:46 MSK

Хм. Лично я таких средств не знаю. Попробуй поковырять mii-tool/ethtool на предмет таких опций. А зачем это нужно?

nnz ★★★★
(24.01.10 22:33:03 MSK)

Ответ на: комментарий от nnz 24.01.10 22:33:03 MSK

Интересно просто. :) Как раз-таки такое ни в коем случае не нужно.

papasha
(24.01.10 22:36:16 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 22:36:16 MSK

Кажется, понял ход твоих мыслей. Но ты же говорил, что другие сетевые службы продолжают работать?

Да, и что там с логами?

nnz ★★★★
(24.01.10 22:38:27 MSK)

Ответ на: комментарий от nnz 24.01.10 22:38:27 MSK

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

Сейчас, с минуты на минуту логи опубликую.

papasha
(24.01.10 22:47:50 MSK) автор топика

Ссылка

Ответ на: комментарий от nnz 24.01.10 22:38:27 MSK

Вот, всё что есть.

http://www.dod.lv/logs/auth.log
http://www.dod.lv/logs/daemon.log
http://www.dod.lv/logs/dmesg.log
http://www.dod.lv/logs/errors.log
http://www.dod.lv/logs/kernel.log
http://www.dod.lv/logs/messages.log
http://www.dod.lv/logs/syslog.log
http://www.dod.lv/logs/user.log

Да, Вы уж простите, я ещё не очень хорошо освоился.

papasha
(24.01.10 22:57:01 MSK) автор топика

Ответ на: комментарий от papasha 24.01.10 22:57:01 MSK

Логи выглядят вполне нормально, ничего криминального не заметил.
Можешь примерно назвать время, когда рвались сеансы?

nnz ★★★★
(24.01.10 23:22:07 MSK)

Ответ на: комментарий от nnz 24.01.10 23:22:07 MSK

Все падения запечатлены в файле auth.log, там где эта строчка. [code]Received signal 15; terminating.[/code]

Вот например: 01:05:35

papasha
(24.01.10 23:31:09 MSK) автор топика

А остальные службы точно работают? Не путаешь? Мне кажется, что дело в аппаратной части. Или может в ядре? В любом случае, если все логи чистые, то как вариант можно предложить загрузиться с лайв-сд, поднять sshd и посмотреть что будет.

~~buildworld~~
(25.01.10 04:28:42 MSK)