LINUX.ORG.RU
ФорумAdmin

сеанс SSH не закрывается при завершении работы ОС

 , ,


0

4

Подключаюсь к удалённой машине(sshd) Debian 8 по SSH, даю удалённой машине из консоли команду reboot, машина перегружается за считанные секунды, но клиент остаётся висеть очень долго как будто сессия ещё жива. Проблема явно в systemd, так как в предыдущих версиях debian 6 такого не было, выскакивало сообщение: connection closed, что и должно быть в нормальном случае. При поиске наткнулся на это http://forum.russianfedora.pro/viewtopic.php?f=16&t=5779&sid=9b3193eb...

Может быть сущестуют еще какие-то варианты решения?

★★★

Может быть сущестуют еще какие-то варианты решения?

sudo reboot && exit
novitchok ★★★★★ ()
Ответ на: комментарий от intelfx

Зачем что-то использовать, если это дыра? Я не понимаю как можно восстановить четырехплет соединения TCP после ребута: Леннарт и ядро уже начал патчить?

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

Зачем что-то использовать, если это дыра?

Где дыра?

Я не понимаю как можно восстановить четырехплет соединения TCP после ребута

После какого ребута? При чём здесь ребут? Ты по ссылке ходил вообще?

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Где дыра?

Нигде. Ошибься, бывает.

После какого ребута? При чём здесь ребут?

ТС перезагружает машину.

Ты по ссылке ходил вообще?

По ссылке сходил. И перечитав пост ТС все понял. Я уж опасался худшего: восстановление TCP сессий, дабы все было гладко, как будто машина и не перегружалась. Это и было бы дырой. Атакующий в момент перезагрузки мог заменить хост целевой машины (клиент) и получить соединение (детали того, что еще нужно сделать и как этим воспользоваться вне этого вопроса).

По теме, процесс sshd должен корректно завершаться, чтобы успеть отправить FIN/RST. Если этого не сделать, клиентское соединение останется висеть в состоянии ESTABLISHED до 5 часов (в линуксе), если клиент не передает никаких пакетов (а он их передает только при нажатие клавиш).

gh0stwizard ★★★★★ ()
Ответ на: комментарий от vel

Джва чая. Системд не в том порядке тушит всё. Поцтеринг маладец.

redixin ★★★★ ()
Ответ на: комментарий от gh0stwizard

Ага. В systemd опять недосыпали зависимостей: главный процесс sshd корректно завершается до отрубания сети, а дочерние, которые запускаются на каждый логин, уходят каждый в свою цгруппу и никаких таких зависимостей не получают.

intelfx ★★★★★ ()
Ответ на: комментарий от gh0stwizard

В systemd всё гасится параллельно, если не указано иное. Для главного процесса sshd явно указано «запускать после сети, гасить до сети». Для дочерних, которые создаются динамически — нет (поскольку они представляют собой отдельные пользовательские сессии, они помещаются в отдельные юниты и настройки из sshd.service не наследуют). Такой вот факап.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Вот нашел:

Before installing libpam-systemd, on reboot, the terminal would hang for some time, then display:
Write failed: Broken pipe
After which the terminal would return to the local prompt.
After installing libpam-systemd and rebooting, on the next reboot, the >>terminal immediately displays:
Connection to N.N.N.N closed by remote host.
Connection to N.N.N.N closed.
After which the terminal immediately returns to the local prompt.

И действительно

# apt-get install libpam-systemd решает эту проблему.

vlb ★★★ ()
Ответ на: комментарий от vlb

o_0

А как без него вообще что-то работает?..

У тебя его установка решает проблему вне зависимости от тех фиксов, которые я предлагал?

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

У тебя его установка решает проблему вне зависимости от тех фиксов, которые я предлагал?

Да, только что попробовал.

vlb ★★★ ()
Ответ на: комментарий от vlb

Да, только что попробовал.

Интересу ради, а система скольки разрядная?

PS: у меня это было первое найденное решение, libpam-systemd - и оно совершенно не помогло

PPS: |

Количество косяков в последнем стабильном дэбиане, которое я схватил в последний месяц рушит мои юношеские идеалы.

И даже особо не могу придумать, где может быть зарыта собака. Почему, грубо говоря, в двух идентичных установках что-то может работать на одной, и не работать на другой?

iu0v1 ()
Ответ на: комментарий от vlb

Может быть у тебя изменен /etc/ssh/sshd_config ?

Где-то да, где-то дэфолт. Но замечание очень справедливое. Проверю ближайшее время.

iu0v1 ()
Ответ на: комментарий от iu0v1

libpam-systemd - и оно совершенно не помогло

libpam-systemd + кастомная зависимость от network.target на systemd-user-sessions.service — так работает?

intelfx ★★★★★ ()
Ответ на: комментарий от iu0v1

Почему, грубо говоря, в двух идентичных установках что-то может работать на одной, и не работать на другой?

Обратись к системному администратору.

anonymous ()
Ответ на: комментарий от vlb

Странно.

Есть предположение, что проблема не решается, а переходит из класса «детерминистичный фейл» (когда дочерние процессы sshd просто никем не прибиваются) в класс «состояние гонки» (когда они прибиваются, но раньше или позже сети — сказать нельзя).

Залогинься по ssh и сделай

systemctl list-dependencies --after session-${XDG_SESSION_ID}.scope
systemctl list-dependencies --after systemd-user-sessions.service

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от iu0v1

А у меня сотни 64рок. Интересно.

Попробовал только что на 64. Все нормально.

vlb ★★★ ()
Ответ на: комментарий от intelfx

root@support:/home/vlb# systemctl list-dependencies --after session-${XDG_SESSION_ID}.scope

session-.scope

root@support:/home/vlb# systemctl list-dependencies --after systemd-user-sessions.service

systemd-user-sessions.service

● ├─system.slice

● ├─systemd-journal-flush.service

● ├─systemd-journald.socket

● ├─basic.target

● │ ├─paths.target

● │ │ ├─acpid.path

● │ │ ├─systemd-ask-password-console.path

● │ │ └─systemd-ask-password-wall.path

● │ ├─slices.target

● │ │ ├─-.slice

● │ │ ├─system.slice

● │ │ └─user.slice

● │ ├─sockets.target

● │ │ ├─acpid.socket

● │ │ ├─clamav-daemon.socket

● │ │ ├─dbus.socket

● │ │ ├─syslog.socket

● │ │ ├─systemd-initctl.socket

● │ │ ├─systemd-journald-dev-log.socket

● │ │ ├─systemd-journald.socket

● │ │ ├─systemd-shutdownd.socket

● │ │ ├─systemd-udevd-control.socket

vlb ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.