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

Сообщение о выключении (комментарий)

tl;dr: используй сокет-активацию, т. е.

systemctl disable sshd.service
systemctl enable sshd.socket

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

sudo reboot && exit

типичный вариант, когда сеть отрубают раньше чем убивают все sshd.

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

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

Где дыра?

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

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

Где дыра?

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

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

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

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

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

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

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

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

А какой смысл гасить сеть до гашения сервисов? Чисто из любопытства.

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

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636

Вот нашел:

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 решает эту проблему.

o_0

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

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

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

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

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

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

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

PPS: |

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

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

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

32

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

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

А у меня сотни 64рок. Интересно. Постараюсь выделить время на тест 32й.

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

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

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

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

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

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

Странно.

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

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

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

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

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

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