В дерево исходных текстов OpenBSD интегрирован (http://permalink.gmane.org/gmane.os.openbsd.cvs/118371) код нового демона identd с реализацией протокола IDENT (http://ru.wikipedia.org/wiki/Ident) (RFC 1413 (http://tools.ietf.org/html/rfc1413)), предназначенного для организации идентификации пользователя, устанавливающего TCP-соединение. Новый identd разработан в недрах проекта OpenBSD в качестве безопасной и высокопроизводительной замены штатного (http://www.openbsd.org/cgi-bin/man.cgi?query=identd) BSD identd, вызываемого через inetd.
Новая реализация сама обрабатывает соединения и запускается в форме фонового процесса, при этом соединения обрабатываются в неблокирующем режиме с использованием libevent. За счёт грамотной организации обработки сетевых соединений и ухода от дополнительной нагрузки, связанной с запуском нового процесса на каждый запрос при использовании inetd, новая реализация позволяет кардинально увеличить производительность работы сервиса IDENT. Кроме того, в новом identd обеспечена возможность параллельной обработки клиентских соединений.
Для обеспечения безопасности в новом identd поддерживаются такие дополнительные механизмы, как разделение и аннулирование привилегий. Обработка запроса производится после перехода в изолированное chroot-окружение и сброса привилегий. Для проверки наличия пользователя используется непривилегированный процесс, при этом выполнение проверки не блокирует обработку других запросов.
Из пока не реализованных возможностей старого identd отмечается отсутствие поддержки загрузки информации об идентификаторе пользователя из размещённых в домашней директории файлов ".ident". Кроме того пока недостаточно полно обрабатываются ошибки. В настоящее время новый identd доступен только для использования в OpenBSD, но можно рассчитывать на скорое появление переносимых версий, поддерживаемых для других популярных проектов OpenBSD, таких как OpenSSH (http://www.openssh.org/), пакетный фильтр PF (http://www.openbsd.org/faq/pf/index.html), демоны маршрутизации OpenBGPD и OpenOSPFD (http://www.openbgpd.org/), NTP-сервер OpenNTPD (http://www.openntpd.org/), почтовый сервер OpenSMTPD (http://www.opensmtpd.org/), мультиплексор текстового терминала (аналог GNU screen) tmux (http://tmux.sourceforge.net/), BSDL-альтернатива пакету GNU groff - mandoc (http://mdocml.bsd.lv/), протокол для организации отказоустойчивых систем CARP (Common Address Redundancy Protocol).URL: http://permalink.gmane.org/gmane.os.openbsd.cvs/118371
Новость: http://www.opennet.ru/opennews/art.shtml?num=36442
ident кроме как в роле некоей необязательности на IRC ещё где-то используется?
Мало ли, какой-нибудь корпорастический софт, бегающий в доверяемой среде в интранете, где бухши и манагеры работают на огороженных персоналках с опёнком. Сложно представить, какие преимущества могут быть у такого решения, но мало ли у кого какие обстоятельства.
> бухши и манагеры работают на огороженных персоналках с опёнком. Сложнооднажды осенью, обходя окрестности офиса, одмин Онуфрий обнаружил OpenBSD
"Однако, откуда окаянная операционка оказалась?" - ошеломлённо озадачился одмин Онуфрий
:)
"Опенсорсный оазис!" - остолбенел Онуфрий. "Окончательно обнаглели, охальники!"
"Однако, отключать опасно," - осёкся осторожный одмин, - "обрабатывает огромные объёмы оцифровки. Отказ обслуживания обозлит общественность."
Обойдется общественность! Осведомленные особи огромные объемы обрабатывают Ораклом!
Может штатно использоваться postgresql для идентификации конектящихся пользователей.
Главное вовремя.
Ждем собственной имплементации gopher, причем обязательно разработанной _В НЕДРАХ_
> Главное вовремя.
> Ждем собственной имплементации gopher, причем обязательно разработанной _В НЕДРАХ_И, кстати, я где-то слышал, что telnet: не безопасен.
openBSD и так для тебя уже написали OpenSSH, больше тебе нет необходимости пользоваться телнетом.
> [...] OpenSSH, больше тебе нет необходимости пользоваться телнетом.Надеюсь, помните, что openssh не на пустом месте вырос?
И что это меняет?
небезопасен
Гоняйте внутри ESP, если не доверяете :)
А если с керберосом?
> И, кстати, я где-то слышал, что telnet: не безопасен.Вот тебе, митрофаныч, задача.
Есть у нас некий "кластер на проводах", состоящий, скажем, из
десятка хостов с UNIX-like системой, скажем, Linux.Есть у нас десятки тысячи задач, которые нужно равномерным слоем
размазать по этому кластеру. Да, кстати, кластер внутри
небольшого езернет фрагмента большой "корпорастии",
так что за безопасность трафика можно не беспокоиться.Решаем мы ее так:
paexec -x -n 'host1 ... host10' -c remote_command -t transport < taskspaexec -- это моя поделка, но сути ведь это меняет, правда?
remote_command принимает задачу (одну) в качестве своего
единственного аргумента. В качестве транспорта мы можем
использовать любую ssh-like утилиту, скажем, ssh или rsh.Проблема вот в чем. В случае транспорта ssh, если мы жмем C-c или C-\,
локальные ssh-ы прибиваются, а вот remote_command-ы на хостах -- нет.
В случае rsh -- прибивается все, включая удаленные процессы,
т.е. remote_command-ы получают
свои SIGINT/SIGQUIT и честно умирают, и именно это
поведение мне кажется единственно верным.
Болтающиеся часами не понятно зачем процессы никому не нужны,
как мне представляется.В man-е NetBSD (пардон) на rsh сказано следующее:
Interrupt, quit and terminate
signals are propagated to the remote commandВ мане на rsh в Debian-е ничего подобного нет, но работает он
так же, т.е. с моей точки зрения правильно.Итого, варианты наших действий:
1) читаем код ssh/sshd и выясняем, в чем причина такого поведения, пишем патч,
отсылаем его апстриму;
2) пинаем апстрим (OpenBSD-шников) на предмет, фича это или баг, и в чем причина
такого поведения, далее запрашиваем фичу в случае, если бага;
3) быстро решаем проблему, заменяя привчный ssh на "устаревший" rsh
и откладываем пункты 1 и 2 "на потом", когда появится время.Что будем делать, митрофаныч?
>> И, кстати, я где-то слышал, что telnet: не безопасен....
> Что будем делать, митрофаныч?А, забыл сказать.
paexec -t 'ssh -t' ...не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.
>>> И, кстати, я где-то слышал, что telnet: не безопасен.
> ...
>> Что будем делать, митрофаныч?
> А, забыл сказать.
>
> paexec -t 'ssh -t' ...
>
> не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать ход выполнения - еще проще, особенно, если знать про расширенные возможности expect, типа interact.
>[оверквотинг удален]
>> ...
>>> Что будем делать, митрофаныч?
>> А, забыл сказать.
>>
>> paexec -t 'ssh -t' ...
>>
>> не пойдет, во-первых, stdin занят, во-вторых, 'ssh -t' -- это overkill.
> Я обычно такие вещи пишу на tcl + expect. Писать просто, контроллировать
> ход выполнения - еще проще, особенно, если знать про расширенные возможности
> expect, типа interact.В моем случае есть специальная строка-терминатор, которую "клиент"
должен напечатать и сбросить буфер stdout. Эта строка -- признак того,
что обработка задачи завершена и можно приступать к следующей.
expect можно использовать, если утила сбрасывать буфер не умеет, т.е.
использовать в качестве "обертки".Но сути вопроса это не меняет.
Древний небезопасный rsh работает, ssh -- увы.
>> И, кстати, я где-то слышал, что telnet: не безопасен.
> Вот тебе, митрофаныч, задача.
> Что будем делать, митрофаныч?Приятно проводить досуг.
Но зачем, Ватсон?..Идея распределенного файрвола, когда пользовательские машины сообщают на центральный пункт сведения о том, кто какие соединения открыл, уже однажды была реализована (клиентская кроссплатформенна, серверная под линукс). В протокол ident, однако, эта задача не укладывается.
В общем, картинка про троллейбус из буханки. Другие проекты хоть какую-то полезность имели.