SSH и reboot

Есть нехорошее подозрение по части интерпретации alias'ов в данном случае (или прав пользователю которому разрешено запускать команду и тогда скорее вопрос правильности конфига).

Экспортировал sshd_config из убунты - ничего не вышло
Скрипт /etc/init.d/ssh на stop почти идентичен (добавил как на убунте опцию --oknodo - так же не то)

думаю скорее всего - при завершении работы он (/etc/init.d/ssh stop) и должен отсылать команду на закрытие всех сеансов, но ничего похожего на это там не увидел :

# ubuntu
  stop)
        log_daemon_msg "Stopping OpenBSD Secure Shell server" "sshd"
        if start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/sshd.pid; then
            log_end_msg 0
        else
            log_end_msg 1
        fi
        ;;

# gentoo
stop() {
        if [ "${RC_CMD}" = "restart" ] ; then
                checkconfig || return 1
        fi

        ebegin "Stopping ${SVCNAME}"
        start-stop-daemon --stop --exec "${SSHD_BINARY}" \
            --pidfile "${SSHD_PIDFILE}" --quiet
        eend $?
}

Да,
комп уходит в перезагрузку - а команда остается висеть в терминале

проверил оба совета на своем серваке - работает нормально
примерно на минуту подвисание (пока на сервере опустятся все сервисы) и потом соединение рвется спокойно
никаких специальных настроек ни там, ни тут не делал

проверьте reboot из чистой консоли.

если эффект будет тот же - покопайтесь в логах на сервере.

у меня на одной из тестовых машинок была ситуация - сначала долго опускался squid, потом неспешно завершался почтовик, после чего подвисал alsa на несколько минут - в итоге вся перезагрузка длилась минут 10-15

ssh "опускается" одним из последних - так что вполне возможно и подвисание терминала из-за этого.

может и у вас какой сервис не может завершиться?

Внезапно. Так и происходит. /etc/init.d/sshd stop не убивает все сессии, по причинам описанным ранее, а именно, чтобы вы случайно не умудрились отрезать себя от сервера на другой стороне планеты =). Поэтому сессия остается рабочей ровно до того момента, пока не будут положены сетевые интерфейсы. Как только хост вернеться из ребута, ожидающее соединение, постоянно пытающееся что-то получить от него, начнет радостно тыкаться в 22 порт с неизвестной сессией TCP, а именно какбы со статусом ESTABLISHED. А такого соединения в таблице установленных нету, и ядро, еще даже до ssh отпинывает запрос, что и приводит к данному сообщению.

Собственно я не вижу тут проблемы вообще. Как форсировать закрытие ssh сессии было уже сказано ранее.